Re[2]: bounce, mta, & mua (was Re: sieve draft)

 In 
<Pine(_dot_)SOL(_dot_)3(_dot_)95L(_dot_)971105035352(_dot_)3044F-100000(_at_)nil(_dot_)andrew(_dot_)cmu(_dot_)edu>
 TJS(_at_)ANDREW(_dot_)CMU(_dot_)EDU writes:

Warning; long, rambling response follows:    ;-)

> > > My desire would be that filtering could be inserted at almost any stage.
> > > If the result of the filter is that the message is going to be rejected
> > > or rerouted, then better to catch it as early as possible before the bits
> > > have crossed the wires.
> > >
> > > However, it is true that the farther you get from the recipient MUA, the
> > > less likely the user is to get control over the disposition of messages.
> > Is it reasonable to believe that this could be done in a robust and safe
> > way? I fear such a dream can easily turn into a nightmare if not
> > carefully
> > analysed before implemented.
> Procmail has done a fairly decent job and presents roughly the same dangers,
> and I think it has even more potential to shoot users in the feet.  But I
> haven't used it, and haven't even looked at the documentation much...
We have implemented filtering in our mail system, both at the MTA (SMTP)
level (i.e. global filter rules that can *truly* bounce messages based on
invalid return[from/reply-to/sender] addresses and a few other rules) as
well as the MTA/UA level (i.e. individuals can define rulesets that apply to
messages which have been deposited in their "mailbox" -though before the
messages are viewable by the UA). User-invoked rules can file/forward/
delete/various other actions, and are based on a syntax similar to what has
been proposed; though our rules are entered into our system via a GUI that
prevents the entry of actions we don't support (therefore my earlier object-
ions to the necessity of parsing/storing rules or actions that our system
does not support). As a side note, I still don't see a use for requiring
us to preserve actions/rules that our system will not process *unless* there
is also some standard extension (say for POP or IMAP) where clients can
download their "stored" rulesets from the server upon connection... I don't
see that happening here.

The "MTA"(SMTP) level filtering refuses to accept messages, i.e. we actually
return a 5xx error in response to the "DATA" smtp command, forcing the sending
system to deal with the "bounce". Messages bounced this way never make it as
far as an individual's mailbox. In turn, the filters at this level must be
"global" since the MTA is operating on "the" instance of the message (before
it is split and delivered to the -perhaps many- individuals designated as
the recipients). This kind of bounce forces the overhead/problems of bad
-or forged- return addresses onto the sending machine -- as opposed to the
local system having to queue a *new* message attempting to deliver a notice
to (the reported) sender of the original message.

A note; as one that deals intimately with alot of SPAM, more and more of these
"people" are using the (legal and difficult to filter otherwise):
  MAIL FROM:<>
(i.e. empty return address) to foil normal DSNs and bounces. A UA (even one
that has managed to find out/preserve the SMTP "MAIL FROM" address is often
going to encounter this on exactly the type of messages a user would most
often want to refuse. Queueing a new message to deliver a DSN using this
address won't work.

  I don't object (too much) to a "reject" action as a special form of a
"reply" action (which as I mentioned, *will* cause alot of problems to mail
administrators, though nonetheless is a potentially useful function) but don't
try to fool yourselves (or potential users invoking this action) into thinking
that this action is at all useful in reference to any UCE/SPAM. And there
will certainly need to be implementation notes describing some of the draw-
backs;
 * most UAs will not have access to the SMTP "MAIL FROM" address anyway,
  which is where DSNs are *supposed* to go
 * even those that do will have to know to ignore (obviously) empty
   MAIL FROM addresses - so do implementations that support this action
   need exception handlers to deal with an invalid return address? Or
   simply silently disregard them?
 * using this action in response to a UCE/SPAM message will almost NEVER
  be useful, and in most cases will make the problem/impact worse

Even a reply action is gonna need to be able to handle exceptions; even non-
SPAM messages sometimes have invalid reply addresses, and if your "auto-
responder" (action using reply) can't complete because of an invalid address
(i.e. a bogus domain or something) then there should be an option that the
rules could do something else... Final word; if it's gonna be done, do it
right. :-)

             -Chris Bartram