On 19-feb-04, at 14:47, Robert G. Brown wrote:
I actually think that the spamassasin/procmail combination above is
nearly ideal on the MUA side,
It is not, because:
1. Bandwidth is used up by spam (which is fortunately usually not that
big) and worms (which tend to be much bigger)
Bouncing these requires (at the MTA or beyond) requires examining them
and applying tests to the entire message, generally, so bouncing at the
MTA saves no wasted bandwidth -- it close to doubles it.
I agree that rejecting the message based on content during the session
won't help here, but I wasn't arguing that doing it on the MTA is
ideal, just that filtering on the MUA isn't an ideal solution.
If you reject the message during the SMTP session you don't need to
generate a bounce message, the other side will do this. So the
bandwidth waste is the same in both cases.
2. A lot of processing time is used on your system(s)
The processing power required, BTW, while non-trivial is easily within
the reach of modern CPUs for up to perhaps a thousand users per server
Fortunately things aren't as bad as this (that means services like
Hotmail would need mail server clusters of super computer proportions)
but doing content based mail filtering is certainly "non-trivial", as
you say.
3. Either:
3a. Legitimate senders who are tagged as spam are blackholed and are
unaware that you don't read their message
3b. You must manually sort through all messages that are flagged as
spam
Instead you have legitimate readers who may be unaware that a message
to
them was bounced or blacklisted,
Requiring that the intended recipient is informed of mail transmission
problems doesn't make much sense since if the failure can be
communicated, then the message itself could also have been
communicated.
Anyway, I think it's more important to provide feedback to the sender
as the sender knows how important the message is.
And you (the user) CAN'T sort through all messages that
are flagged as spam because they aren't spooled, they are rejected!
I'm not interested in flagging messages as spam, I'm interested in
rejecting a significant percentage of unwanted mail. If the mail isn't
unwanted, then by all means, have it delivered, regardless of it being
spam or not.
So there's the gauntlet. You propose that bounces are important. Are
they important enough to justify bouncing 9 messages out of 10 to false
return addresses?
I believe sending back feedback when a message is filtered for some
reason is important, because this way a limited amount of false
positives is acceptable as the sender gets to retry the communication
in some way. However, I fully agree that sending back bounces to the
"from" address does much more harm than good here. But rejecting the
message DURING THE SMTP SESSION (sorry for shouting) doesn't have these
drawbacks as you are by definition (still) talking to the actual source
of the message.
(Ignoring the corner case where someone accepts a message with forged
headers and then tries to deliver it to a third party here.)
I believe our current email systems and protocols are broken so
fundamentally, given the current environment, that it's no use trying
to fix them. We need something new.