As I said in my original email I was looking for solutions to slow them
down. You seemed to think I was suggesting examining or tightening up
the return codes. Nothing code be further from the truth.
I do believe that we shouldn't leave a stone unturned to find answers
for halting spam.
Chuck
Bill Cole wrote:
At 6:39 AM -0400 7/11/03, C. Wegrzyn wrote:
I've been giving more thought to how to slow down spamming. It seems
we should just follow 7.3 of RFC2821 - return either 250 or 252 to
VRFY and EXPN commands. In this way the sender can't find out if
someone is really on a system.
I don't know what sort of mail servers you work with, but the ones I
do see insignificant amounts of VRFY and EXPN requests and already
return the same meaningless responses for all such queries regardless
of their arguments. This has been common practice for many years.
RFC2821 was written to describe existing practice more than it was to
recommend new security tactics.
Second I would kick back a 551 to every message being sent by a
domain/user I don't recognize or wanted to reject as SPAM. In the
former case I would send the email to the real recipient allowing
them to decide what to do with it.
1. If you kick back a 5xx code of any sort to any mail, you have
decided 'what to do with it' permanently and irrevocably.
2. Any system that generates a message to the recipient for each
message detected as spam is at least as bad as the spam for the
recipients behind it.
In any case, this sort of thing is well-established practice. The only
utility I see in discussing details of response codes to various
conditions would be to standardize them for various meanings in the
area of spam. I may be misunderstanding the current state of IETF/IRTF
affairs, but I think that's someone else's job. [2]
I the latter case I would just toss it or fill in the subject with
SPAM:.
Modification of existing headers by an MTA for any reason other than
address re-writing is fundamentally wrong.[1] Adding headers (as
SpamAssassin does) makes far more sense and prevents multiple such
strategies from colliding with each others' efforts. There are
certainly practical arguments for doing the conceptually wrong thing
given the shortcomings of the world's dominant worm transmission
vector^W^W^W desktop mail client, but it would be a bad precedent for
an IRTF process to accommodate ephemeral and easily overcome
shortcomings at the cost of making a 'hack' recommendation like
subject line mangling.
[1] Many have disagreed with that exception, but between tradition and
pragmatic concerns it is hard to really swear off that arguably bad
habit. I think the battle was lost when the revival of sendmail with
v8 kept header address rewriting alive.
[2] It's also arguably not all that useful. Many sites already have
concerns with using 5.7.x extended status codes because they reveal
policy detail to parties believed to be malicious.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg