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

From: "Chris Bartram" <[email-masked]>
Date: Wed, 5 Nov 1997 21:37:24 -0500

In <[email-masked]> [email-masked] 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

---

From: Chris Newman <[email-masked]>
Date: Mon, 17 Nov 1997 14:36:52 -0800 (PST)

>   which is where DSNs are *supposed* to go

This is incorrect.  UAs will have access to the "MAIL FROM" address unless
an upstream system violated Internet standards.  The final delivery agent
is REQUIRED to copy the "MAIL FROM" address into the "Return-Path" 
header.  Anything which doesn't is broken. 

>    simply silently disregard them?

This is already defined in the standards.  DSNs are not sent if there is
an empty "MAIL FROM" address, so "reject" would be equivlent to "discard"
in this case.

>   be useful, and in most cases will make the problem/impact worse

Agreed.  But Sieve is designed for much more than just
UCE/UBE/SPAM/whatever. See my previous message for why a "bounce/reject"
action provides vital functionality.

		- Chris

---

From: Tomas Fasth <[email-masked]>
Date: Wed, 19 Nov 1997 17:06:33 +0100

> header.  Anything which doesn't is broken.

Chris, can you give us the exact location in an RFC that backs up your
assertion? I'm not sure it is required and I'm not sure you can ever
rely
on it's existence once the message have moved into the domain of the
MUA.

If you're right, my FreeBSD "out-of-the-box" installation is certainly
broken. The "P" flag required to generate the Return-Path header is
_not_
set for the local mailer by default. I don't know why, but the very
existence of this discrepency (the fact that it's optional) is enough
for
me to maintain that this header might not always be available. Period.

> an empty "MAIL FROM" address, so "reject" would be equivlent to "discard"

Ouch. Are you suggesting that the transfer from reject to discard would
be
done silently without giving a chance to the scripter to do something
else?

> action provides vital functionality.

Don't you think an automatic repetitive reject (whatever cause) can be
regarded as a kind of spam? What guarantee do you have that the receiver
of
the delivery rejection notification know how to handle such a message?
If the traffic is fluent, s/he might instead (wrongly but possibly)
decide
to order his filtering device to reject such stream of junk mail which,
as
you decribed above, might result in a silent discard because the lack of
an originator address.
We now have a stream of messages taking up network resources and with no
other purpose than using brute force (using automating tools) to
convince
a fellow netizen to stop sending messages. Some might regard that as
spamming as well.

My point is; when demanding new and powerful functionality in a tool
that
will become available to average end users, you should at least consider
the side (and less wanted) effects and consequences before having it
implemented. Just because it seem like a cool feature, it does not
necessary
equal to a useful one. Especially if you mix features from different
problem
domains in the same implementation entity. That is only going to cause
trouble.

-- 
Hälsningar/Regards

Tomas Fasth <[email-masked]>
Tel: +46-13-218-181 Cel: +46-708-870-957 Fax: +46-708-870-258
EuroNetics Operation, Mjärdevi Science Park, 58330 Linköping, Sweden
(TwinSpot Network is a subsidiary of EuroNetics Operation)

---

From: Tim Showalter <[email-masked]>
Date: Wed, 19 Nov 1997 15:44:41 -0500 (EST)

> done silently without giving a chance to the scripter to do something

Sure.  What would be more appropriate?  If you're going to refuse messages,
then you're really going to refuse messages.  If you don't want to refuse
messages, don't refuse messages.  What's the problem?

> regarded as a kind of spam?

No, it's not spam in any sense of the word -- it's not unsolicited.

> What guarantee do you have that the receiver
> of the delivery rejection notification know how to handle such a message?

What do you intend by this?  How can someone not be ready to handle a bounce
message?

> you decribed above, might result in a silent discard because the lack of

Good.

> a fellow netizen to stop sending messages. Some might regard that as

They would be wrong for all of the reasons described above.

What you're saying is that if A sends B a mesasge, and B sets up his mailer
to reject A's messages, and A sets up his mailer to reject B's rejects, that
A is likely to keep sending mail to B in the hopes that his mailer will
somehow change its behavior.  I think this is absurd.

-- 
                                           Tim Showalter [email-masked]

---

From: Tomas Fasth <[email-masked]>
Date: Thu, 20 Nov 1997 13:35:08 +0100

> messages, don't refuse messages.  What's the problem?

You're right, I'll take that back.

> somehow change its behavior.  I think this is absurd.

It is. I'm sorry, it has been a bad day. I redraw.

-- 
Hälsningar/Regards