ietf-asrg
[Top] [All Lists]

RE: [Asrg] SMTP level unsubscribe

2003-08-14 08:23:42

Of course from the MTA administrator's point of view, they need to
protect their network from massive abuse. And of course it is the
right of the organisation to block whatever traffic it chooses from
its own network. Some people might be against the idea of additional
filtering over and above the personal consent policy of the
recipient, although I can understand why such filtering may be
necessary in practice.

In practice my @apache mail is filtered when it arrives at the
apache mailserver, and again when it makes the hop to my own server,
and again when it is downloaded by my client, my idea was that all
this filtering could be aggregated and sent up-stream so that it 
is imposed as near to the source as I can push it.

Yes, I see... reducing the amount of unnecessary traffic later.

Some might say that administrative filtering is more within the
scope of a BCP rather than a standard. I'm not sure either way.

Yeah, but a single well designed standard for expressing consent
could be used to describe both.

I suppose that mail administrators and end receivers will use
similar matching rules and policy enforcement decisions. Both
groups want to match some rules against incoming messages and
both wish to apply a suitable policy decision.

So initially at least I'm happy that the same consent definition
language could express the policies of both, since I don't see
anything which is exclusive to either admins or receivers. (If
anyone begs to differ, I'd like to know.)

However there are definitely two types of policy, although they
may be expressed using the same format.

The question arises as to what should happen if the MTA admin's
policy decision for an incoming message conflicts with that of 
the reciever's personal policy? 

If both policies are in agreement for the message then this is
fine. However situations might arise where:

 - the MTA site policy permits delivery, but the personal consent 
   policy of the reciever does not

 - the MTA site policy does not permit delivery, but the personal
   consent policy allows it

In the case of the former, it seems sensible not to deliver the
message because the recipient's personal policy is bound to be
more specific than that of the incoming mail server.

In the case of the latter, I suspect the site admin policy 
would take precedence. I'm not sure if this should be the default
behaviour (maybe that's a BCP issue) but in practice some admins
will want to override individual policy for the sake of protecting
the whole site against mass spam floods.

So what I would propose is that one language/format could meet the
needs of both, but that the site's policy is distinct from that
of its end-users.

Then any sender will be able to impose the rules before 
transport, and the recipient will be able to apply them after 
and still benefit from any saving made by having some mail
delivery never even attempted.

This is an interesting approach. It suggests the idea of two protocols
(or maybe one protocol used for two different purposes):

 - for sending personal consent policy to the ISP's MTA
 - for a sending MTA to query a remote MTA's policy details

The latter is likely to be the more controversial.

Yeah, but in practice it would still be within the control of
the mail admins exactly which rules are exposed and which are 
protected by silence.

I know this has been debated on the list before. No doubt someone
can remind us of the relevant threads.

I can see that there are arguments for both, and in fact I'm
a big proponent of configuring SMTP to not reveal information in
error messages, so I'm not totally wedded to the idea of querying
unless the information is only exchanged between trusted MTA's
or is of non-contentious material.

Of course, the question of how to decide which MTAs to trust is
tricky. What material would you consider "non-contentious"? Can
you provide an example?

After all the difference between sending a message and having it
bounced, and asking "will you accept x" and being told "no" is 
largely one of bandwidth, and not a qualitative difference in 
the information gained by the experience.

Ah, that's a slightly different phrasing...

     "please tell me everything you will accept"
 and "will you accept X?"

...reveal vastly different amounts of information. The former is
undesirable because disclosing the whole policy would allow a
spammer to construct a message designed to be accepted.

The latter reveals less information, although it may be vulnerable
to a dictionary attack in which the spammer tries all possible X 
combinations until a "yes" response is received. This might waste
enough of their time to discourage them, but with so many owned
machines acting as relays it's probably not their personal time
that's being wasted anyway.

BTW, I'm being a little glib about the possible policy enforcement 
decisions here. Assuming that a message will either be accepted 
or rejected is perhaps simplistic. This doesn't detract too much
from the point at hand but there are other options such as 
delaying delivery, silently dropping a message and so on. I'd
like to develop a list of "standard" policy responses, as this 
is something which will be useful to express in a consent
definition language.

Keep the ideas coming...

Andrew

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



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