On 4/15/14 6:14 PM, Sabahattin Gucukoglu wrote:
There should be a mechanism for an author to send a message to a mailing list,
granting the mailing list permission to redistribute that message, and have
that permission conveyed to the mailing list recipient such that when the
mailing list recipient receives the message, they can assure themselves that
the originating domain is OK with that redistribution. Sounds like some
protocol which could be written.
That suffers the same problems as X-O-A-R: you have to know when to trust the
intermediate. In the absence of that knowledge, any message transformation is
invisible to the recipient, and potentially malicious. You would have to
invent a scheme for identifying transformations, so users could verify them
against the original sender's signature.
Not necessarily. If the originator of the message sends to a mailing
list, the originator's site should trust the mailing list to
redistribute the message and make any transformations. (If you can't
trust your users to make a decision on which lists to send to, that's a
different thing.) If the originator's site is going to allow that, you
could create a mechanism where the originator's site gets some sort of
cryptographic data from the mailing list site and include that in its
signed message, such that when the eventual recipient gets the message,
it can verify that it came from a mailing list site that the originator
explicitly sent the mail to. That doesn't require the originator's or
the recipient's site to independently trust the mailing list. (It would,
of course, be perfectly OK for the recipient's site to check that it's
getting the list mail from an authorized site; that's separate from of
the above.)
And again, this is only if the originator indicates that it *wants* to
allow its users to have their mail redistributed. The site is well
within rights to indicate that it doesn't want that to happen, and a
friendly mailing list would bounce the mail in that case.
On 4/15/14 6:17 PM, Theodore Ts'o wrote:
On Wed, Apr 16, 2014 at 11:00:31AM +1200, Brian E Carpenter wrote:
(If the originating domain is expressly *not* OK with the
redistribution, the mailing list should bounce the message back to the
author saying as much.)
Isn't that exactly what p=reject implies? If so, the logical behaviour
for all list software would be to check the DMARC record for the
originating domain of each message, and bounce it if p=reject.
Yep.
The question is which is more or less unfriendly?
1) Forbidding yahoo.com users from participating on mailing lists
2) Rewriting the from field of yahoo.com users.
More or less friendly to whom? If yahoo.com says that it doesn't want
mail from its users sent via other servers, it might be unfriendly to
its users to bounce the mail, but it's pretty darn friendly to
yahoo.com. (Imagine the question: "So, you say you don't want things
with your users' addresses sent from my server. Are you OK with me
rewriting your users' addresses with '.invalid' on the end and then
sending them?") And it's much friendlier to eventual recipients of this
mail to bounce it (forcing the originator to send from a different
address) than to get a piece of mail that will cause them to get a
bounce if they reply to it without noticing that there's a ".invalid" at
the end.
The problem is that the current protocol is not rich enough to express
everyone's intentions. Yahoo conceivably might want to say, "It's OK to
receive mail from a yahoo.com user from a site that is redistributing a
piece of mail that a yahoo.com user explicitly sent to it." But there's
no way to say that in the protocol now. Given that, yahoo.com has made
the current choice to say, "Reject all yahoo.com mail that comes from a
site other than yahoo.com". That's a choice yahoo.com is free to make. A
friendly mailing list is well within spec to honor that request by not
redistributing the mail.
I could easily see the mailing list software making this be
configurable, so it's up to each mailing list admin. :-)
I think that's a perfectly reasonable thing to do.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478