Bart Schaefer wrote:
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.)
IMO, your example above is not a subject for delivery refusal.
I regard it as a denial of service associated with a particular
maildrop.
I can easily imagine many kinds of commercial services similar to the
example above. Each having different access control mechanisms on the
same message store/maildrop site.
The question is, regarding that each automated maildrop service might
have it's own access control, where are all this best handled?
I suggest that a good design would be, from the MTA's point of view,
to regard the message as being successfully delivered to the maildrop,
which happens to have a service associated to it, a service which then
decides by it's own access control whether to accept the service request
or not.
I would not recommend to make that kind of handling a business of the
MTA. It would only be confusing and even hard to administer and
maintain.
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.
Hmm. In this case I think your approach is unfriendly.
Instead of taking the small annoyance of finding out the address of the
admin and the postmaster, and send them a polite request of removal,
you decide to bounce each and every message originating from that
particular list. I do not consider that a good use of filtering.
I do recognize a need of list management on the client side, but that
is hardly done by using filtering technics alone.
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.
I suggest we begin by distinguish between message delivery and
message acceptance. By doing this we might be able to reach some
kind of consensus on what we are trying to achieve here.
My opinion is that a message ought to be regarded as delivered if
the message have successfully reached the maildrop. Note that a
maildrop can be more than just a simple file or a slot in a database.
A maildrop can be the entry to another subsystem which might control
the access to further processing or final storage.
My point is that if we use this description as a model, message
delivery is just about to find the correct maildrop. That makes
the task of the MTA much less complicated.
By delegating maildrop specific processing, for example message
acceptance, to the subsystem beyond final delivery, you have,
in my opinion, achieved a better modular approach to the messaging
infrastructure.
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.
Yes, there are reasons for rejecting certain messages depending on
what context they are in. Yes, the protocol handler should not bother
about digital signatures and such.
But then, I regard neither of those things to be among a message
transport agent's responsibilities.
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.
I see. My interpretation of current internet standards in this area,
is that the SMTP "MAIL FROM" address, also called the originator
address or return-path, is recommended to only be used by the MTA for
resolving non-deliveries and mail system failures. There are also RFC
documents describing how such a "bounce" should be formatted.
There seem to be a slight confusion between the SMTP type of bounce and
your type of bounce. But then, I am asserting that your type of bounce
is not really a bounce, but rather something that is in practice the
same as a reply. There are even draft documents describing something
called message disposition notifications. I think those can be used
in such similar situations that have been described here and earlier.
Further, I do not regard your use of return-path as conformant with
current internet messaging practice.
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.
Which is my point. There are reasons for running the filtering tools
as "post-delivery". One is that since the filtering rules originates
from an end user and therefore have unpredictable results, it's not
a good idea to let those rules control the pre-delivery process.
You can always argue that there is need for filtering rules that
are centrally administred by the postmaster. But then, I assert that
this might be a dangerous approach. Do you really want to do this?
Slightest mistake in one of the rules will potentially affect all
the maildrops on the site.
Isn't it bad enough to have the sendmail.cf to worry about? ;-)
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.
The very idea of having individual users to dictate the behavior of
the MTA is revolting to me. It even sounds outright dangerous.
But then, I am sure that your cause is absolutely sincere.
I only ask you to consider another approach of solving your problem.
And there are many good uses for a filtering language like Sieve,
although I disagree with your particular type of use.
--
Hälsningar/Regards
Tomas Fasth <tomas(_dot_)fasth(_at_)twinspot(_dot_)net>
tel: +46-13-218-181 cel: +46-708-870-957 fax: +46-708-870-258