On Mar 11, 2007, at 6:31 AM, Justin Mason wrote:
for what it's worth, I would suggest *not* adopting this
as an anti-spam technique.
Sender-address verification is _bad_ as an anti-spam technique, in my
opinion. Basically, there's one obvious response for spammers
looking to
evade it -- use "real" sender addresses. Where's an easy place to find
real addresses? On the list of target addresses they're spamming!
This is a red-herring. They already do that. They have been doing
that for a long time. And it has nothing to do with sender
verification.
Sender verification works and works well.
Hence, the spam recipients now get twice as much mail from each
spam run
-- spam aimed at them, *and* bounce blowback from hundreds of spams
aimed
at others, forged to appear to be from them. It's the obvious
response to
SAV, which is one reason why we never implemented something like
that in
SpamAssassin.
Sorry, but you conclusion does not follow. Sender verification has
been around for a while and this has not happened in my experience.
Ie, there is no greater use of real FROM addresses than there was
before.
Most MTAs have in-built routines to do this, with exim having a
particularly good facility for this. Technically, with exim's, you
are actually validating the sending server's adherence to the RFCs
about accept DSN replies back.
Chad
--j.
Kelly Jones writes:
To fight spam, I want to validate the address (not necessarily in
real-time) of the a given email sender. Is there a Unix tool that
does
this?
The basics are simple: to validate "[EMAIL PROTECTED]", I
connect to
the MX record of wnonline.net and go as far as "RCPT TO" as follows:
host -t mx wnonline.net
wnonline.net mail is handled by 5 wnspf.bayou.com.
telnet wnspf.bayou.com. 25
Trying 209.209.192.75...
Connected to wnspf.bayou.com..
Escape character is '^]'.
220 Welcome to Bayou mxfilter
HELO domaintester.com
250 mxfilter.bayou.com
MAIL FROM: <[EMAIL PROTECTED]>
250 Ok
RCPT TO: <[EMAIL PROTECTED]>
550 <[EMAIL PROTECTED]>: Recipient address rejected: 5.1.1
<[EMAIL PROTECTED]>... User unknown
QUIT
221 Bye
Connection closed by foreign host.
This tells me [EMAIL PROTECTED] is an invalid address and that mail
from that address is probably bogus.
A more sophisticated tool would cache results, handle temporary
failures (eg, inability to connect to the MX server), handle multiple
MX records, perhaps even publish results [carefully, to avoid giving
spammers a source of legit email addresses!], etc. Plus, I'd
prefer to
use a tested tool vs hacking something up myself.
I realize this technique is far from perfect:
Spammers spoof legit addresses
Bounces/Mailing lists/etc legitimately use "do not reply" addresses
It could be considered unfriendly to the target MX servers
Some mail servers incorrectly say "user unknown" when they see spam,
figuring it's more of a deterrent than saying "you're a spammer"
Some mail servers inefficiently accept mail for "[EMAIL PROTECTED]" (where
xxx.com is one of their domains), figure out if foo exists later, and
send a bounce back to the envelope sender, instead of rejecting email
at the SMTP level (a really good tool would create throwaway
addresses
to catch these cases too)
... but I still think it might help.
--
We're just a Bunch Of Regular Guys, a collective group that's trying
to understand and assimilate technology. We feel that resistance to
new ideas and technology is unwise and ultimately futile.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-
[EMAIL PROTECTED]"
---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
