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
_______________________________________________
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
