----- Original Message -----
From: "Matthew Elvey" <matthew(_at_)elvey(_dot_)com>
To: <Asrg(_at_)ietf(_dot_)org>
Sent: Saturday, November 29, 2003 2:41 PM
Subject: Re: [Asrg] 0. General - anti-harvesting (was Inquiry about CallerID
Verification)
Yakov wrote:
There is a reason to their madness - it discourages spammers from
harvesting email addresses.
It's a poor excuse. There are ISPs that detect harvesting attacks and
when they do, deal with it - some then refuse even email to valid
addresses. They can refuse the email without stating or otherwise
giving away the information that the reason for refusal is email to a
nonexistent account.
Matthew,
I agree. sites such as Yahoo who allow all RCPT TO: are in my view, for all
intent open relay sites. It encourages and promotes the usages of obsfucated
email addresses across the board to all systems. In other words, it makes
the matter worst and adds overhead across the board to all systems.
There is another possible side to this, and that is to "collect" data to
perform anti-spam research. I know that is what I did for a short period
where we accepted all mail in order to collect data and research the
problem.
IMO, MAIL FROM: <> needs to be deprecated in favor
of refusal during SMTP. There is no compelling reason to delay the mail
validation process. It provides no benefit that cannot be met with
immediate validation, barring the super-secure bastion host scenario
Bill Cole mentions, which could be resolved with some work. (I should
admit - I don't do what I preach, as the provider I choose to have host
my domain does accept spam that I'd prefer it refuse during SMTP, but I
have pushed them to fix the problem, and they do refuse a good fraction
of the spam during SMTP.)
I forget whether SpamAssassin supports what we're currently calling
CallerID Verification. It has NO_DNS_FOR_FROM: Domain in From header
has no MX or A DNS records, but I think it doesn't have the full
CallerID Verification.
I would believe it does not. I am only saying this because an active 3rd
party anti-spam author who incorporates SpamAssasin in our beta team. His
only comment to me was that he was afraid we will taking away some of his
future business. :-) We don't try to step of the toes of 3rd party
developers writing for our package. We normally concentrate providing the
API and HOOKS functionality into our client/server system as illustrated
here:
http://www.winserver.com/public/antispam/AntiVirusSpam.htm
Our current release only offers the HOOK into the DATA state point. We
quickly learned that while this offered anti-spam (and other special
processing capabilities), from a anti-spam standpoint, it might have "help"
spammers because they have the most treasured state point, the "RCPT TO:"
stage to gain informaiton. So from a anti-spam standpoint, the DATA hook
helps, but it might makes matters worst by increasing the frequency of spam.
But as with everyone else, the spam problem because so pervasive especially
with SOBIG exploiting everything that is wrong about the legacy SMTP
protocol, we simply could not wait for anyone to solve the problem at more
detail levels. I have to admit I naively thought it was a waste of time as
eventually the issue would be solved using the new crime laws for spam.
After all, using your address for the MAIL FROM: is fraud.
In any case, in the new current anti-spam design, the design criteria is
based on SMTP technical compliance. Each SMTP command will a hook for
extended logic. We will inherently supply technical compliance logic with
the flexibility to allow future improvements by 3rd party vendors or an
official IETF method is established.
For now, I believe the Caller ID verification is the best method to prune
the majority of illegal entry into the system.
I have been saving our logs for the last 7 months. I finally finish a SMTP
LOG statistics reporter for our system. Check out some of these results:
http://www.winserver.com/public/antispam/wcsmtpstats.htm
See my next message on this where I provide some analysis and possible new
SMTP suggestions.
---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg