Quoting Danny Angus <danny(_at_)apache(_dot_)org>:
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.
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?
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.
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.
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg