On Nov 1, 3:02am, Tomas Fasth wrote:
}
} What other than spam would be a subject for delivery refusal?
Some examples:
I run an email customer support service. Customers with paid support can
legitimately send mail to support(_at_)supporters(_dot_)com(_dot_) All other
messages
sent to that address are bounced, with the suggestion that they pay up.
(No, I don't really run such a service. These are examples.)
I subscribed to the fud-list(_at_)blather(_dot_)com mailing list, but now I
don't
want it any more. I've sent a dozen unsubscribe requests, but nobody
is managing the list and it keeps coming to me. I want to bounce the
messages back to the (admittedly unresponsive) list admin address and
to the postmaster(_at_)blather(_dot_)com in hopes of getting their attention.
But
that doesn't mean that everyone at my site thinks the fud-list is spam.
I could come up with more, but they're mostly variations on one of those
two themes: (1) Only messages matching some criteria should be delivered,
and all others should get a bounce explaining why they were not; (2) some
source of mail not normally considered to be spam is for whatever reason
abusing a mailbox, and a bounce should be generated to notify the sender
of this unintentional abuse.
} A thing that a MTA would want to do is to screen unwanted traffic.
} But that kind of processing should only use information that is
} available as part of the protocol itself, not the data it is
} transporting.
Not true. For example, there may be a valid reason for some mailboxes
to reject all messages that do not have a digital signature, or that are
not encrypted using a particular public key. But the protocol doesn't
reveal whether the data is digitally signed or encrypted.
} Actually, can you give examples of any other filtering tools that
} allow a bounce action that is distinguishable from a reply action?
A reply action is typically directed to addresses taken from the RFC822
header of the message, e.g. the "From" or "Reply-To" fields. A bounce
is typically directed to the envelope sender, e.g. the SMTP "MAIL FROM"
address. There presently aren't many (if any) tools that are able to
make that distinction, because there are few MTA-level filtering tools;
almost all must run "post-delivery" without access to the SMTP envelope.
One purpose of the sieve language, as I understand it, is to enable the
user to intervene *before* the MTA delivers the message, thus making it
*possible* to have distinguished "bounce" and "reply" actions.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com