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.
--
Bill Cole
bill(_at_)scconsult(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg