[Discuss] DMARC issue, Yahoo and beyond

[bill at horne.net (Bill Horne)]

On 5/16/2014 11:44 AM, Richard Pieri wrote:
> Bill Horne wrote:
>> /will/ /not/ /see/ my post, because *their* email server will reject my
>> email, since the Mailman robot modifies the "Subject" line and does
>> other things that break DMARC. Someone correct me if I've got that wrong
> Rewriting fields created by originator or sender when this isn't
> absolutely necessary to ensure validity arguably breaks RFC 2822.
>
> On the other hand, the Subject field is optional and the contents aren't
> guaranteed to be constant by RFC 2822 so DMARC's dependence on such
> constancy also arguably breaks RFC 2822.
>
> Either way, if removing the Subject field rewrite solves the problem
> then do it. The alternative is munging other headers in ways that
> blatantly break RFC 2822. Less munging is always the technically
> superior choice.

I agree that, technically, "less is more". However, /practically/, 
munging subject lines or other headers may be the best the BLU can do.

This might turn into a debate about the FUSSP, but here goes: I don't 
want to get into an argument about whether DMARC is "right" or "wrong".  
There are a myriad of post-receipt countermeasures available to 
SysAdmins and users after spam arrives, but they are all labor-intensive 
ex post facto procedures which are easy for spammers to work around or 
ignore. I worked to reduce spam years ago, and I happen to know guys who 
are less than six degrees away from APEWS, but an organization like 
Yahoo or Gmail has to find automated measures just to stay within the 
won't-cost-us-too-many-users range. In any case, GHotCastHoo admins are 
able to /dictate/ policy, and they know it.

I don't think we're adding tags to subject lines as an anti-spam 
measure: some subscribers have the capability to /sort/ emails based on 
subject-line tags, but /rejecting/ spams isn't possible by the time an 
email client sees them. The "discuss" tag is handy for those whom sort 
their mail inbox by subject, too, but I /think/ we can all agree that we 
/could/ do without it if that's the only option.

My first question is whether mailman allows the BLU to selectively munge 
headers based on the recipient's preferences: if a YahGooHotCast 
subscriber can turn off munging by themselves, then we're done, but I 
don't remember if that's possible. If the answer is "No", then I suggest 
we explore some custom-code for Mailman.

The second question is what to do if that's not possible. I don't know 
enough about DMARC to say what is or is not acceptable, but I think it's 
possible to sort BLU emails based on fields /other/ than the Subject: 
line "discuss" tag in most email clients, so I'm asking if the BLU can 
meet enough of the DMARC requirements to avoid cutting off YahGooCastHot 
subscribers when a YaGooHotCast subscriber posts to the discuss list.

My third question is how many subscribers are affected, and whether the 
BLU is able to construct a custom solution just for them.

Bill


-- 
Bill Horne
William Warren Consulting
339-364-8487