In
<Pine(_dot_)LNX(_dot_)3(_dot_)95L(_dot_)971024224341(_dot_)5558C-200000(_at_)monopoly(_dot_)andrew(_dot_)cmu(_dot_)edu>
TJS(_at_)ANDREW(_dot_)CMU(_dot_)EDU writes:
Hi,
I'm glad to see this draft coming forward. I do have a few issues with it
though... ;-)
- first, your draft was attached as a BASE64 encoded text file... That's
ok, but woulda been nicer if if were text/plain or even quoted-printable.
- the "required" flag on rules...
I know several *nix implementations will be reading these on-the-fly, and
might benefit from such a flag, but those of us who plan to implement GUIs
where you can't even enter an action or rule that's not valid will have
no use for such a flag... I'm not quite sure how I'd handle this - I
suspect that having the spec require something parse the rules file
before rules are loaded wouldn't go over well? Everyone's gotta "link up"
the rules at some point though - it seems to me (IMHO) that a parse and
flagging of actions or tests that aren't supported be flagged at that
point. I have no desire to "make space" in our already implemented (though
not standard-compliant --yet) rule system for rules that we don't support.
I recall some of the debate on this earlier, and if the point is more for
"storage" of rules, perhaps to be downloaded to clients on demand, then
I withdraw my protest; though I didn't really get the impression that this
is what this proposal is about.
- more importantly, the "bounce" action.
I have a *real* problem with users being able to "bounce" a message, for
a couple reasons;
I deal with spam ALOT, and probably 60-80% of UCE that comes in has
faked return addresses -either completely bogus names or (happening more
often) faked names using someone ELSE's domain. Further, many of the
UCEs received lately have their return addresses merely set to "remove"
robot addresses -- which tests done by folks on the SPAM-L and net-abuse
newsgroups have demonstrated repeatedly that responses to these addresses
does NOT remove you from a list, but merely confirms that the address the
spammer sent to is a valid address (and in turn yields yet more spam).
Anyway, my point; while the idea of sending back a "go away spammer"
seems like a satisfying one, it's NOT going to get to them. Further, it's
either gonna contribute to a mail-bomb attack on an innocent third-party
whose from address was forged, confirm their own address for the spammers
mailing list (which they're all selling/swapping these days), or it's
gonna clog up your own system's MTA as it tries to deliver to a shut down
or invalid domain.
A "bounce", to be effective, needs to take place in the MTA (SMTP Server
process) - refusing the message before it's actually delivered into any
local mailboxes (i.e. as the diagram below:
C:<connect server>
S:220 server ready
C:HELO myhost
S:250 Ok
C:MAIL FROM:<joespammer(_at_)hitsrus(_dot_)com>
S:250 Ok
C:RCPT TO:<postmaster>
S:250 Ok
C:DATA
S:354 Start sending message
C:<message contents sent>
*********************************
S:5xx message refused, spammer
*********************************
This stops the message before it gets into your queues, and forces the
sender's system to deal with it as an undeliverable message -- using THEIR
resources, not yours.
To do this kind of refusing, you have to perform rules globally - not from
any individual's rule-set (unfortunately); as obviously different users will
have different rules.
My proposal would be to drop the "bounce" action, utilizing just the
"drop"/"delete" action instead. Using bounce is going to put a major load
on "friendly" mail systems and will almost never have the desired (though
admirable) effect.
-Chris Bartram
3k Associates, Inc.