[Mailman-Users] Executive summary of DMARC issues

[Gary Algier]

On 05/14/14 23:47, Stephen J. Turnbull wrote:
> Peter Shute writes:
>
>   > When MS365 forwards the mails sent to the distribution list, should
>   > that make the DMARC authentication fail? I thought that only
>   > happened if you made changes like adding a prefix to the subject
>   > line like Mailman does.
>
> If it forwards verbatim *and* the sending domain signs the mail with
> DKIM (the common case), DMARC validation will succeed.  Without DKIM,
> DMARC validation is guaranteed to fail.  However, even in the sender
> uses DKIM, *any* change *whatsoever* to the body will cause validation
> to fail, and there are several changes to the header that could cause
> it to fail.  Furthermore, which parts of the header are protected by
> the DKIM signature are determined by the sender, not by DMARC AFAIK.
>
> If distribution lists are pure forwards, MS365 will be OK.  But I find
> it hard to believe that that level of functionality is popular with
> users -- there's a reason why all popular MLMs implement subject
> prefixes, body headers and body footers, and it isn't "because it's
> the Microsoft way".
>

I ran some tests this morning.  I created an Exchange distribution list here 
and added myself five ways on the list:
1. On our Exchange server (how I receive internal emails)
2. On a local Linux server running sendmail and dovecot (how I receive "real 
mail")
3. A Yahoo address.
4. A Gmail address.
5. An iCloud address.

I then sent an email to the list and to my work sendmail address.  It was 
delivered to both work addresses and the iCloud address.

Gmail put it in my Spam folder with the warning:
-------------------------------------------------------------------
Be careful with this message. Our systems couldn't verify that this message 
was really sent by yahoo.com. You might want to avoid clicking links or 
replying with personal information.
-------------------------------------------------------------------
There is also a link to their "Why messages are marked as Spam" page.

On Yahoo I found the bounce in my Spam folder with the following:
-------------------------------------------------------------------
This is an automated message from the Extensible Content Security
at host wg.ulticom.com.

The message returned below could not be delivered to its intended
destinations.

For further assistance, please send mail to <XXXXXXXXXXX at wg.ulticom.com>.

If you do so, please include this problem report. You can delete
your own text from the message returned below.

Reason:
<XXXXXXXX at yahoo.com>: host mta7.am0.yahoodns.net[98.138.112.34] said: 554
     5.7.9 Message not accepted for policy reasons.  See
     http://postmaster.yahoo.com/errors/postmaster-28.html (in reply to end of
     DATA command)
-------------------------------------------------------------------
The server wg.ulticom.com is our WatchGuard Anti-Spam appliance.  It had no 
trouble accepting it when it came in the first time (it does not do DMARC 
checks), but when it tried to delivery the email to Yahoo, they rejected it. 
Of course, the reject went to Yahoo anyway, but with a MAILER-DAEMON sender 
address.

I saved the two copies from my sendmail address and compared them:
% h=$(sed -n -e 'y/:/|/' -e '/DKIM-Signature|/s/.* h=\([^;]*\).*/\1/p' direct.eml)
% diff -s -u <(egrep -i "^($h):" direct.eml) <(egrep -i "^($h)" list.eml)
Files /dev/fd/4 and /dev/fd/5 are identical
% diff -s -u <(sed '1,/^$/d' direct.eml) <(sed '1,/^$/d' list.eml)
Files /dev/fd/4 and /dev/fd/5 are identical

The first diff compares only the headers in the DKIM Signature.
The second diff compares the body.
The DKIM checks seem to be good.  So, it seems that nothing has changed in the 
content or checked header.  It must be SPf.

% dig +short TXT _spf.mail.yahoo.com
"v=spf1 ptr:yahoo.com ptr:yahoo.net ip4:206.108.40.0/27 ip4:199.16.139.0/26 ?all"

It seems that in the case of a simple Exchange distribution list, the Yahoo 
members will fail (into their Spam folder!), some others may fail depending 
upon their service's SPF fussiness, and others may have to root around in 
their Spam folders for the content.

--
Gary Algier, WB2FWZ            gaa at ulticom.com             +1 856 787 2758
Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054     Fax:+1 856 866 2033

Nielsen's First Law of Computer Manuals:
     People don't read documentation voluntarily.