On Wed, Feb 11, 2004 at 07:00:46AM -0500, Hector Santos wrote:
Maybe a need for some
RBL listing virus/spam infected machines, I don't know.
This is actually a good idea it if can be done with a response code. Not
another RBL look up site :-)
I don't understand what you say here, the RBLs normally work as a lookup
in the DNS. Are you suggesting another way of distributing the list?
DNS has an advntage of rapid dissemination and no specific maintenance
at each client site.
No need for new protocols,................
Well, we need something to address the uncontrollable abuse of anonymous
access. (non-authenticated sessions). With the current SMTP protocol, we
use a suite of methods that offers a near 100% rejection:
1) Add an extended Greeting response. You will instantly stop 40% of your
dial-up spammers.
2) Add a machine domain literal spoof check at HELO/EHLO - 20% rejection
3) Internal IP/DIP filter tables (DIP = return path Domain + client IP).
This helps #5
4) RBL Lookup
I have by default 3 sites, selected for best response times, little down
time.
sbl.spamhaus.org
list.dsbl.org
bl.spamcop.net
A special lookup algorithm includes logic to temporarily excludes slow
response sites and prioritizes the sites by best performance.
5) LMAP based solutions, DMP and SPF implemented.
.....
Arent this what is considered good practice by many MTA administrators?
I don't see needs for protocol changes with much of this.
So in summary, my recommendation is to follow the suggestion in RFC 2821 to
validate the domain, IP and/or the return path AFTER you get a validated
RCPT address. If you do this, you will minimize your spam management
overhead and maximize the rejection rate.
I think checking the sender is a good thing upfront, and that receipient
validation should be done very *late* in the process. The latter is
actually my main point: check everything else first, including the
body for virus and spam, and then check the receipient. This to reduce
the error generation for invalid reciepient, or other problems such as
account closed or mailbox full.
In that way we can improve the signal/noise level on receipient errors,
which to me may be a very serious errors. I administer many email lists
and I find it a major problem if a reciepient does not get the mail.
I sometimes go to the extreme of doing telephone calls to fix the
problem. Also I occasionally misspell an email address - and then I
would really like to get a notice that this happened.
So my recommendation is a prioritzation of mail validation. First check
the mail for if it is bogus: wrong sender addresses, no PTR (host
unknown), unknown sender, virus in body etc. And then check for the real
errors.
Best regards
keld