[Top] [All Lists]

Re: sieve draft

1997-10-27 14:58:31
 TJS(_at_)ANDREW(_dot_)CMU(_dot_)EDU writes:


  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
 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.

<Prev in Thread] Current Thread [Next in Thread>