On Fri, Jan 15, 2016 at 09:52:30AM +1100, Tony Langdon via luv-main wrote:
On 15/01/2016 12:14 AM, Russell Coker via luv-main wrote:
We had a problem of Gmail and other recipients falsely regarding mail from the LUV server as forged and assigning it to the spam folder.
Nothing that can't be fixed with a filter (use the "Never send it to spam" option in the Gmail filter for LUV list mail).
Unless it's being rejected by Gmail entirely, which is the case with messages sent from some Yahoo domain(s), that can't easily be fixed without breaking one standard or another.
We are dealing with a couple of bugs in Mailman, what I consider to be a deficiency in OpenDKIM and some interactions between SPF and DMARC.
If you would like to help with some of these technical issues then go for it.
I'm very tempted to investigate the Mailman header folding bug/feature, although I'd understand the maintainers not wanting to deal with edge cases like that, considering there's already effort on a newer version. I'd be even more inclined to fix this, if it weren't for the fact that SPF would fail DMARC domain alignment anyway... Amending the DMARC standard, and/or accommodating "trusted forwarders" might be the only solution, but then you have yet another problem, the subjectivity of trust.
http://postmaster.facebook.com/reputation_and_authentication
Facebook is now compelling sysadmins to use SPF or DKIM. This isn't going to go away. It's only a matter of time before Internode starts using DKIM to placate Facebook.
Looks like it's a case of having to follow suit., like it or not.
I think SPF or DKIM are far more bearable than DMARC (especially the inflexible domain alignment); if only that standard allowed either SPF or DKIM alignment, rather than both (AFAIK), but implementations may differ anyway. I'll eventually test this myself. The problem DMARC was designed to solve is that MUA will typically display the "From:" header as the sender, and it's easier to implement some crackpot standard to enforce alignment of that with authentication mechanisms, than expect every MUA to change behaviour by warning if a sender's authentication has not been verified.