On 29/Jul/10 13:21, Charles Lindsey wrote:
The REAL cause of the problem is that From: line. My proposal is that MLM
should change the From: header in such a way that the mail appears to have
come from MLM.example and not from discardable.example. Clearly, this
removes the cause of the problem at a stroke (the mail will no longer be
discarded), but obviously it raises several other issues instead.
SRS on "From"? It is intriguing that, after having taken a rather
different approach, DKIM faces much the same problems that SPF had
been criticized for, for the same minor fraction of the email traffic.
IMHO, the real cause of the problem is that the same "From" field is
being used for entirely different message streams. On the one hand,
the MLM wants the input message to be signed, so it can authenticate
the poster. On the other hand, MLM output isn't the land of the
author domain (including IPR, usually) even if the original "From"
stays there to identify the author.
As for the solution, it is much cleaner if Joe himself sets up an
ADSP-unencumbered address to start with. I see phishermen use
approach #3 even if it is not standardized. Perhaps, we should find
ways to avoid that, rather than introducing new possibilities.
On 29/Jul/10 14:46, Douglas Otis wrote:
The TPA-Label approach does _not_ depend upon changes made by the
mailing-list! The TPA-Label limits change to code already handling ADSP
records, and of course to domains making ADSP assertions. There is only
a small number of domains making actionable ADSP assertions. The
TPA-Label would allow Author Domains a means to assert explicit
exceptions when processing their restrictive ADSP assertions.
I agree that TPA-Label would make it more practical to use policies
other than "unknown". However, I have the feeling that it is more
useful for small domains that want to use external services, than for
mailing lists. For a large domain whose users are free to subscribe
to any list, I see two major concerns:
1. There is no standard way for the domain to learn when any of its
users subscribe to a new list. In practice, users would have to
check whether the relevant TPA already exists, and possibly apply
for it internally, before subscribing.
2. Granting a TPA implies a good degree of trust. I don't think
/any/ mailing list would obtain a TPA from, say, PayPal; the sites
who would could then be trusted "by proxy" by anyone who takes
PayPal's assessments for good...
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html