On Thu, Feb 12, 2004 at 07:56:59AM -0500, Keith Moore wrote:
On Feb 12, 2004, at 12:53 AM, Keld Jørn Simonsen wrote:
On Wed, Feb 11, 2004 at 10:47:00PM -0500, Keith Moore wrote:
Yes, many things are easier to check upfront than whether this is virus
or spam - the latter takes a full scan of the body. And then I think
these easy checks should be done as long as they also reliably can
classify the mail as forged, such as bogus MX and no PTR and some such.
neither of these checks can reliably classify the email as forged.
You are right. But there probably are checks that can be done upfront to
find bogus mail, that was my point.
My aim is, still, to get rid of bogus error mail.
And as far as I see it in my own mailbox, this is mail of the
following kinds, *only*:
1. reports that the body contained virus
2. reports that the user is unknown
3. reports that the user's account has been closed.
4. reports that the user's mailbox is full.
I think we'd agree that #1 should not be sent to the "sender" of the
virus since it is so often forged.
But reports #2-4 are often useful, and they _should_ be detected before
the server has a chance to look at the content of the message.
reports 2-4 are very often useful! But these reports should not be
generated, if the mail in question was a virus (number 1).
That is my whole point.
yes, I do think that having uniform reporting would be useful.
I would be happy not to make a new SMTP error reply code if this can be
done better with some other reply means. What would you suggest?
DSNs and ENHANCEDSTATUSCODES.
OK with me.
I have yet to see a third party RBL that didn't misrepresent what it
was reporting - either in that the information being reported was often
stale, or in that there was an attempt to mislead people about the
validity of the criteria they were using. For instance, the RBLs that
blocked mail from machines that appeared to relay mail was a dubious
criterion because there were valid reasons to relay mail and not all or
even most mail from such machines was spam. (Now with SMTP
authentication there are fewer valid reasons). RBLs that accept
reports from other parties spread misinformation. For instance, if a
site uses spamassassin's criteria as a way to decide whether to report
to an RBL that a particular IP is sending spam that is spreading
unreliable information. ("propagation of error")
I can understand that some rbls are propagating errors.
I dont think that some rbls today builds their data on
spamassasin result, which one should that be?
I also have my reservations to whether a sensibe RBL for infected
machines can be built. How to eliminate machines that are not infected,
but propagates virus via some open email lists? I personally get
a lot of virus mail, but surely some of the machines are not
infected, but only relaying. I would like to investigate the
possibility, however.
There might be some cases where the _authoritative_ DNS zone for a
MAIL
FROM domain or the _authoritative_ DNS zone for the source IP address
of an SMTP connection says "messages that look like this are not
authorized". And in some of those cases the SMTP server might be able
to tell that a message "looks like this" from just MAIL FROM and/or
RCPT TO. In those cases it _might_ make sense for the SMTP server to
return 2xx in response to those commands (if they are otherwise valid)
just so that it can black-hole the message. Though I think it might
make even more sense to return 4xx in response to those commands - or
just stop responding to that connection - and then refuse to accept
any
new connections from that source IP for some period of time. The
rationale here is that the SMTP server doesn't want to waste bandwidth
or cpu cycles by sucking down a message that's going to be discarded
anyway, and it does want to avoid being interrupted by a compromised
machine or spammer's machine if it tries again later.
My analysis is that for a number of servers the CPU load stemming from
this kind of bogus mail is not a problem.
I'm not sure what you mean by "analysis" here.
Maybe "experience" is closer to what I mean, but I think that many MTA
systems have enough muscle to do some work to deliver better quality
of error responses. This given the amount of mail received in smaller
businesses, and the muscle normally found in current hardware.
But my limited
experience is that many mail servers spend much more time and bandwidth
processing spam than processing useful mail. (especially if you count
the effort spent trying to bounce spam)
Yse that is sad, but with the amount of spam and virus today, this is
foreseable. As said on one of my servers about 99 % is bogus mail.
Best regards
keld