Subject: RE: [Asrg] SMTP level unsubscribe

From: Andrew Akehurst <[email-masked]>
Date: Thu, 14 Aug 2003 15:31:12 +0100 (BST)

----- Forwarded message from Danny Angus <[email-masked]> -----

> 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.

> 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.

> > 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 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.
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.

d.

----- End forwarded message -----

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Danny Angus" <[email-masked]>
Date: Thu, 14 Aug 2003 16:26:20 +0100

> bandwidth, and not a qualitative difference in the information

What I expect to happen is that this "no" will be contained within a rule
that the sender can apply generally for this recipient (e.g. not this
sender, not this Mime type, not content containing "badword" or whatever),
and that it would also have a "time to live" (or "time to love" as I just
mistyped!) thereby empowering the sender to make assumptions about other
matching messages, and reduce unproductive bandwidth use.

Perhaps simply attempting to send a message and if it is rejected the
rejection contains the rule which caused the rejection, and it's TTL, and
allow the sender to apply it themselves?

Before everyone flames me, I *do* get the fact that this could be used to
quickly build up a profile of what is allowable, and so spammers could
tailor mail to make it allowable, but lets see if we can work this problem
out before we dismiss it completely.

Times to live would also raise some questions, such as how would people
react if a bad rule had a big TTL and their honest mail was destroyed for
hours before the TTL expired.

d.

---

From: Andrew Akehurst <[email-masked]>
Date: Thu, 14 Aug 2003 17:06:22 +0100 (BST)

Quoting Danny Angus <[email-masked]>:

>> I wrote:
>> 
>> 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.

> What I expect to happen is that this "no" will be contained within a
> rule that the sender can apply generally for this recipient (e.g. not
> this sender, not this Mime type, not content containing "badword" or
> whatever), and that it would also have a "time to live" (or "time to
> love" as I just mistyped!) thereby empowering the sender to make
> assumptions about other matching messages, and reduce unproductive
> bandwidth use.
>
> rejection contains the rule which caused the rejection, and it's TTL,
> and allow the sender to apply it themselves?

I presume you mean rejection during the SMTP connection session using 
some kind of 5xx policy rejection code (rather than using a bounce
e-mail message)?

Are you talking about a strategy similar to DNS lookup cacheing?

I hear some DNS servers cache negative lookup results for a certain
period so as to reduce the number of queries they need to make
elsewhere.

> Before everyone flames me, I *do* get the fact that this could be used
> to quickly build up a profile of what is allowable, and so spammers
> could tailor mail to make it allowable, but lets see if we can work this
> problem out before we dismiss it completely.

One mitigating factor is that the MTA which knows what the policy is
and which issues the rejection code might choose not to disclose the
rule which triggered the rejection.

If the sending MTA is (somehow) trusted by the receiving MTA then the
receiving MTA might decide to disclose that rule. Otherwise it could
return a more generic error with no further detail.

There is still the issue of how such "trust" can be defined, however.

> react if a bad rule had a big TTL and their honest mail was destroyed
> for hours before the TTL expired.

The TTL would have to be chosen carefully. Too long a TTL could result 
in problems when the reciever changes their consent policy but the 
change is not reflected elsewhere. Of course if only *rejections* are 
cached then this would only be a problem if the recipient makes their
consent policy more lenient in some way.

However, too short a TTL would likely mean that the rule cached will
not match any further messages before it expires - which would 
defeat the point of using such a cache in the first place.

Andrew