----- Original Message -----
From: "Keld Jørn Simonsen" <keld(_at_)dkuug(_dot_)dk>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Wednesday, February 11, 2004 1:36 AM
Subject: Best practices to avoid virus and spam
I have got three pieces of advice:
1. Always check for virus/spam before checking for valid reciepient, or
whether the mailbox is full or some such.
This requires the DATA state to be reached. Adds additional bandwidth.
In my research, spammers LOVE systems that accept the RCTP whether its
validated or not or delayed until the DATA state is reached (i.e.,
YAHOO.COM).
I have emperical statistical information that shows an major increase in
spam when we turned off Local User Validation and added the logic to a DATA
mail filter. Message refused because the recipient was not validated. The
result, increase in spam attacks. The DATA stage mail filter was the
first thing we ever did to address the spam problem. It set the stage for
the additional work of a suite of anti-spam techniques that we finally
added. I talk about this suite of methods below.
So IMO best to reject it as soon as possible.
2. Generate a specific error message, maybe we should introduce a
standard error code for this, like 551 - mail rejected as virus or spam.
This is probably ok. But I always debated the idea of giving spammers more
data or information which can help them improve their spam engines. What we
do is (by default), is issue a:
55x Message not accepted by filter
Also, in my view, DATA interpretation is outside the scope of the SMTP
transport system. So if a data hook is provided to an outside non-smtp
process checking the DATA, you should allow the hook return the response
code or response.
3. If the mail is virus or spam, then do not send it back to the
sender - as this is most likely a forged address anyway. Discard it
instead. But if you must, then use the standard error mesaage as
described above.
Good point not to resenting bounces with virus attachments.
However, I think that if your system used instance rejection, then there is
no need for a bounce.
In my view, the SORBIG generation bounce/virus problem mostly begins with
delayed processing systems that accept all messages for delay validation and
processing. This will not be necessary if the system performed using
dynamic/instance rejection at the protocol level.
The segment of my customers who have the higher incident of this problem who
those who have turned off the "[X] Local User Validation" option which
delays the user validation at the gate, create a bounce message which is
usually enabled because your SMTP server accepted the message and by RFC
2821 requirements, once you do that you must provide a reason for the
non-delivery of the message.
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 :-)
There seem to be some effort or discussion in ASRG to standardize the
response codes (127.0.0.x) issued by the many DNSRBL sites.
I think with this scheme, we would have avoided alomost all of the
virus/spam and also annoying error traffic .
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.
These proposals are basically "DIP" checkers - validating the return path
domain with the client IP address (sender machine). At the moment, the more
complex to implement in SMTP SPF method seems to be the more popular for
easier administration and more flexibility. However, LMAP based solutions
suffer from external domain DNS TXT record lookup delays/overhead. So we
only use it for LOCAL domains validation only. It is very very good in this
area. It stops those spoofers from using your valid domain in HELO/HELO and
also the return path address in the MAIL FROM:
So for example, we allows only 208.247.131.* machines to use our local
domains, i.e., winserver.com. If someone tried to use this domain from
another client machine IP address, both DMP and SPF will catch this quite
nicely.
Related to this, for many systems that send mail to us, including this
mailing list, I will add a DIP filter in #3. For example:
accept if %DIP% = ietf.org[132.151.6.22]
accept if %DIP% = mail.imc.org[208.184.76.39]
accept if %DIP% = imc.org[208.184.76.39]
I find it ironic these IETF related site do not have DMP or SPF support yet
to help the communicate help support these ideas. <g>
6) If all the above fails, we do a CBV (Call Back Verifier) which makes an
attempt to see if your MAIL FROM: (return path) address is valid by
performing an SMTP-based call back. This blocks atleast 80% of the CBV
attempts with very little error.
7) Finally, if it gets to the DATA state, a sysop or 3rd party developed
hook is spawn to perform a mail/data filter check. The filter returns the
response code to be used.
Now, I should note that accept for #1 and #2, no method that requires
overhead of any kind is performed until the RCPT state and an recipient
address is provided that would be otherwise a deliverable address.
In other words, if RCPT is refused there is NO need to do any check of any
kind because you are not accepting the transaction.
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 know you have a high throughput rate, if possible, my recommendation is
to enable "Local user Validation" in the operation and you will instantly
remove your bounce problems. SMTP only requires a bounce if you accept it
in the first place or it fails to send something. Of couse, this implies
that you have a tight external mail/relay policy. So if you don't accept
the message, you won't have any post validation bounce/rejection message
overhead.
Hope some of these tips provide some insight with dealing with spam at the
current SMTP level.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com