On Wed, Feb 11, 2004 at 09:31:59AM -0500, Hector Santos wrote:
----- 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:
If this is a final destination, then I don't see how you are conflict with
RFC 2821.
Good
However, if you don't perform a check, how do you know its a final
destination?
I don't relay, so this is the 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.
I would like to check RCPT later on.
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.
yes, probably
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.
As said, I do not allow relaying.
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.
(I believe the name is SOBIG.)
Checks for valid receipts must be done, but after the check for whether
the mail is infected with virus, or spam.
You really need to do more upfront checking.
Why? My idea is to reduce the error messages to genuine errors,
and filter the virus and spam before doing the genuine mail tests.
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"
55x codes may need investigation, and then correction of errors at the
sender side. The idea with 555 was that the nominal sender (which was
forged) can do away with the mail without investigating it.
The other 55x codes should probably be investigated.
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.
That may be, that it should not be a 55x code.
Then it could be a best practice with a recommended error string, so
that we do not get those myriads of different error strings for
rejection of a mail because of virus or spam content.
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
Yes, several possibilities exist.
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."
We are all users.
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.
Yes, thats understood.
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?
This will happen. But I have reduced my problem considerably. Very.
Based on my current experiences, it would be diminished by over 95 %.
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!
Probably, but it may be a much greater violation of SMTP than what I
am proposing. And what I am proposing would be effective enough, IMHO.
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>
But I generated a bogus error report - "no such user", that can end up in
the forged senders inbox. Sometimes the forged sender is me :-(
Best regards
Keld