Date: Wed, 14 Mar 2007 11:07:25 -0700 From: Chuck Swiger <cswiger@mac.com> To: "Chad Leigh -- Shire.Net LLC" <chad@shire.net> Cc: Christopher Sean Hilton <chris@vindaloo.com>, User Questions <freebsd-questions@freebsd.org> Subject: Re: Tool for validating sender address as spam-fighting technique? Message-ID: <46E487EC-2AAF-4885-A19E-1D55034C2D4C@mac.com> In-Reply-To: <F04258F1-B263-4CF1-B3CD-0A58BE9A5C7A@shire.net> References: <20070311200829.31802.qmail@simone.iecc.com> <0AC225E6-E55D-4C20-9A00-2EDD95985848@shire.net> <20070311165028.S44863@simone.iecc.com> <45F57936.3030601@usm.cl> <1173830431.1588.34.camel@dagobah.vindaloo.com> <30DC016D-CA46-44D1-A12D-00BDD723A71D@shire.net> <45F76C4B.5070905@vindaloo.com> <F04258F1-B263-4CF1-B3CD-0A58BE9A5C7A@shire.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 13, 2007, at 8:37 PM, Chad Leigh -- Shire.Net LLC wrote: >>> Address verification callbacks take various forms, but the way >>> exim does it by default is to attempt to start a DSN delivery to >>> the address and if the RCPT TO is accepted it is affirmative. It >>> is not usually use VRFY. Most address verification is done by >>> attempting to start some sort of delivery to the address. >> >> I'm assuming that DSN is Delivery Service Notification > > yes > >> or return receipt. > > mp Most callback systems either try to do a DSN or they try to do a delivery (SMTP RCPT TO) and then quit before sending a message body via DATA; they do not depend on the SMTP VRFY command as that is commonly blocked or configured to return a generic "I don't know whether the address is valid". >> If it is or if it somehow relies on the ability to deliver a >> message via smtp to *@example.com then I don't see how it prevents >> spam. > > If the mail says it is from chris@vindaloo.com but I cannot send a > DSN to chris@vindaloo.com then the account is most likely bogus > sender and is refused. It works wonders for spam. > > DSN has a specific definition -- look in the RFCs as I don't > remember which RFC it is offhand. But you are supposed to always > accept a DSN from <> as part of the RFCs Supporting bounce messages from <> was part of the original RFC-821/822 specs. The fancier three-digit codes and canonical DSN format was specified somewhat later, but I believe that the updated SMTP RFCs, 2821/2822 include it. -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46E487EC-2AAF-4885-A19E-1D55034C2D4C>