----- Original Message -----
From: "Keld Jørn Simonsen" <keld(_at_)dkuug(_dot_)dk>
To: <ietf-smtp(_at_)imc(_dot_)org>
Cc: "Keld Jørn Simonsen" <keld(_at_)dkuug(_dot_)dk>
Sent: Wednesday, February 11, 2004 6:12 AM
Subject: Re: Best practices to avoid virus and spam
Bruce Lilly said:
1. Always check for virus/spam before checking for valid reciepient, or
whether the mailbox is full or some such.
Checking recipient can be done at the time of RCPT TO. Checking for
Your first suggestion conflicts with RFC 2821.
I think it would be OK to check it with the original receipt, or at the
final receipt. So "always" was not directed towards any intermediate MTAs.
Would it then still be in conflict with RFC 2821? Which section?
If this is a final destination, then I don't see how you are conflict with
RFC 2821.
However, if you don't perform a check, how do you know its a final
destination?
So by not checking the RCPT, you are in conflict with 2821 iff you are not
and trusted session. In which case, you are an open relay.
Based on your suggestions, I can only presume the client is authenticated or
trusted in which case, the SMTP tradition is to accept all mail with no need
to check for RCPT. Your SMTP router logic (not SMTP sender logic) will
then determine if the mail is local or remote.
In this case, you promote BOUNCES for invalid final destinations. If you
want to get rid of the bounces, you should validate the local user recipient
immediately. If this was a routed message, well, again, you should not be
accepting the mail this unless the client is authenticated.
My idea is to check for whether the mail is a genuine post, or whether
it is a bogus mail. And only treat is as a genuine mail if we could not
classify it as a bogus mail. Then we can test it for all the normal
error conditions.
It is perfectly ok to have a DATA mail filter that provides successful 250
response or refusal 45x or 55x DATA responses. But technically, this
should only be done for final destination. If you are doing this without
checking for final destination, then you may be conflictive with
passthru/relay mail concepts.
2. Generate a specific error message, maybe we should introduce a
standard error code for this, like 551 - mail rejected as virus or
spam.
So here's another conflict (though returning 554 would be acceptable).
I did not mean to especially use 551, but a new code such as 555.
My idea was to get rid of all these different error messages
that I have tried to list in my filters.
You could use extended smtp codes to do this.
Well, I wanted as final receiving MTA to discard the message, the sender
address is bogus anyway.
You need to do more with protocol level checks than rely on mail filters.
You will not catch it all, and most certainly you are contributing the
bounce problem. What if you can't detect a virus email but the recipient
(local or remote) was bad? A bounce is generated and now you are part of the
SORBIG generation viruses.
You really need to do more upfront checking.
I understand that almost the same amount of error mail will be
generated. The idea, however, is that the receiver of the error
mail will have a much better understanding of which kind of error mail
it is, and for those receivers that are confident that they do not
send out virus or spam, they can just ignore the bogus error mail.
Yes, it will help both receivers and the senders to see a more descriptive
dynamic rejection responses. When we added our DATA mail filter, it was
completely apparent for the need to have the mail filter be able to pass an
description rejection response. But it was not important if was 555, just
whether it was 45x or 55x. 45x told the sender "Hey, ok to try again" 55x
said "don't even bother to try again chump"
I think the point here is that SMTP is not meant to be in the mail
intepretation business. If you have a dynamic DATA mail filter, well, that
integration needs be flexible enough so that your filter can pass back a
response code and/or description response.
If a 555 is proposed for SMTP, I suggest that it not specific to "reject due
to Virus/Spam" but make it two.
555 Mail rejection to do system policy mail integrity violation
556 Mail rejection to do system policy no-solicitating (SPAM)
violation
Also, see Carl Malamud's No-solicitation draft, it uses a 550 for rejection
The bogus error mail is - at least for me personnally - the origins of
almost all unwanted email today.
About 60-80%! <g>
Yes, the virus and spam mail would be delivered to the MTA's.
But not to the MUAs. And that is the main problem. I don't care too much
about what my machine does, as long as the load is beyond 0,1 and I dont
have to waste my personal time on looking at the mails. And my mail
server (which is also an ftp and http-server and other things)
happily chunks away on 100.000 emails a day, of which 99.800
are bogus mail, which get rejected or discarded. No sweat.
You have very valid point which I brought up here just recently. The
"cencensus" (at atleast 2-3 more vocal ones) is that it is a "user problem."
I don't agree. But that point it is too late.
However, with your DATA approach, it is still something that can only be
done on BEHALF on the final destination user with his permission.
My approach is to concentrate more on the PROTOCOL level with a high focus
on "smtp compliance" removing all ideas of "mail intepretation" by the SMTP
server. If you follow some of the suggestions I provided to you, you will
get rid of a major percentage of the problem.
Still what I am after is limiting the emails that
end up in the user email inboxes (like my own), and I think what I
suggest would get a long way to reach that goal.
True. We proved it! :-) But you need to keep in mind it has to be for
final destination. The merit of whether you should trap passthru mail, is I
think, a new topic of discussion, but I think it is too dangerous to play
with.
Nonetheless, you are assuming you will always be able detect the virus at
the DATA stage. What if you don't? What if you were too late in getting
an AVS update with the new monster email virus propagating the SMTP bounce
system?
What it basically meam you need to more at the protocol level. Like you
said, the majority of your unsolicited mail is spoofed. Therefore, if you
can STOP it at the protocol level, you have just fixed a major problem!
RBLs are also cheaper to employ as the mail can be discarded upfront,
while antivirus/antispam requires scanning of the data, which costs more
CPU, and network bandwidth.
And just imagine, if you rejected the RCPT user, you don't even need to do
an RBL, DMP, SPF, CBV or DATA filter overhead process <g>
Anyway just discarding mails with attachments of said types would
get you almost all of the virus.
A major problem with AVS software with SORBIG. They learned and MYDOOM was
better handle now. SORBIG was OUT OF CONTROL!
If you have a machine with a fixed ip-address, however, then there
would not be any problem for that MTA. And MTAs on dynamic IP is
questionable anyhow.
Add the extended greeting you will knock out atleast 40% of those suckers!
See our antispam statistics at http://www.winserver.com/sslinfo
A near zero no-spam problem and 100% no mydoom problem.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com