Re: DMARC: perspectives from a listadmin of large open-source lists

[Pete Resnick <[e-mail]>]

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. - [phone]