[syslinux] Lost hotmail

Sat Jan 3 11:46:02 PST 2015

On Sat, Jan 3, 2015 at 12:53 PM, John 'Warthog9' Hawley
<warthog19 at eaglescrag.net> wrote:
> On 01/03/2015 08:56 AM, Gene Cumm wrote:
>> On Fri, Jan 2, 2015 at 3:43 PM, Geert Stappers <stappers at stappers.nl> wrote:
>>> On Sat, Dec 27, 2014 at 05:07:04PM +0100, Geert Stappers wrote:
>>>> On Mon, Dec 22, 2014 at 11:06:58AM +0200, Ady wrote:
>>>>>> On Sun, Dec 21, 2014 at 12:21:32PM -0800, Patrick Masotta wrote:
>>>>>>>  [ ... Failed to build gnu-efi. ... ]
>>>>>
>>>>> For some reason I have not received the original email from Patrick
>>>>> Masotta in my inbox, so I am using the first reply sent by Geert in
>>>>> order to actually reply to the OP...
>>>>
>>>>
>>>> What is visible in the log files of the mail server
>>>> of the Syslinux mailinglist?
>>>>
>>>> Could the mailinglist mail server deliver to the hotmail mail server
>>>> that Ady is using?
>>>>
>>>>
>>>> The idea behind those questions is to find out where
>>>> the e-mail got lost for 'Ady <ady-sf AT hotmail DOT com>'
>>>>
>>>>
>>>> Additional information of the "lost" e-mail
>>>>  Message-ID: <1419193292.37517.YahooMailBasic at web161706.mail.bf1.yahoo.com>
>>>>
>>>>  Received: from terminus.zytor.com (terminus.zytor.com [IPv6:2001:1868:205::10])
>>>>         by gpm.stappers.nl (Postfix) with ESMTPS id 80F313040F7
>>>>         for <stappers at stappers.nl>; Sun, 21 Dec 2014 21:43:35 +0100 (CET)
>>>>  Received: from terminus.zytor.com (localhost [IPv6:::1])
>>>>         by terminus.zytor.com (8.14.8/8.14.7) with ESMTP id sBLKLk6j024306;
>>>>         Sun, 21 Dec 2014 12:22:37 -0800
>>>>  Received: from nm5-vm0.bullet.mail.bf1.yahoo.com
>>>>         (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150])
>>>>         by terminus.zytor.com (8.14.8/8.14.7) with ESMTP id sBLKLcnR024278
>>>>         for <syslinux at zytor.com>; Sun, 21 Dec 2014 12:21:43 -0800
>>>>
>>>>
>>>
>>> Addtional information:
>>>
>>> On 2014-12-30 got I as moderator of this ML bounce notification
>>> with text as
>>>
>>>    ----- The following addresses had permanent fatal errors -----
>>> <***@lnds.dk>
>>>     (reason: 550 5.7.1 The messages violates the DMARC policy of yahoo.com (83c3fcea-9015-11e4-95e4-b82a72d0454d))
>>> <***@xs4all.nl>
>>>     (reason: 550 5.7.1 DMARC failure for domain yahoo.com, policy reject)
>>> <***@yahoo.co.id>
>>>     (reason: 554 5.7.9 Message not accepted for policy reasons.  See http://postmaster.yahoo.com/errors/postmaster-28.html)
>>> <***@yahoo.co.in>
>>>     (reason: 554 5.7.9 Message not accepted for policy reasons.  See http://postmaster.yahoo.com/errors/postmaster-28.html)
>>> <***@yahoo.co.kr>
>>>     (reason: 554 5.7.9 Message not accepted for policy reasons.  See http://postmaster.yahoo.com/errors/postmaster-28.html)
>>> <**0 at yahoo.co.uk>
>>>     (reason: 554 5.7.9 Message not accepted for policy reasons.  See http://postmaster.yahoo.com/errors/postmaster-28.html)
>>> <**1 at yahoo.co.uk>
>>>     (reason: 554 5.7.9 Message not accepted for policy reasons.  See http://postmaster.yahoo.com/errors/postmaster-28.html)
>>> <**0 at yahoo.de>
>>>     (reason: 554 5.7.9 Message not accepted for policy reasons.  See http://postmaster.yahoo.com/errors/postmaster-28.html)
>>> <**1 at yahoo.de>
>>>     (reason: 554 5.7.9 Message not accepted for policy reasons.  See http://postmaster.yahoo.com/errors/postmaster-28.html)
>>> <**0 at yahoo.fr>
>>>     (reason: 554 5.7.9 Message not accepted for policy reasons.  See http://postmaster.yahoo.com/errors/postmaster-28.html)
>>>
>>>
>>>
>>> For those who have the power to change it:  Please do!
>>
>> Reading over it, a simple TXT record for SPF might suffice:
>>
>>   v=spf1 +mx ~all
>>
>> My presumption is that Yahoo! spam policy now rates neutral responses
>> as spam and rejects (instead of rating them neutral and delivering to
>> a user's spam/junk mail folder).  In my opinion, it's a llittle absurd
>> for Yahoo! to take this approach but I also recognize that times are
>> evolving and it's a reactive security measure to a historically
>> insecure system.
>>
>
> The problem isn't one that the mailing list operator can fix "well", and
> it's mainly based on the fact that DMARC was designed in a vacuum of
> anyone who actually understands mailing lists and/or anyone who uses or
> cares about them.
>
> http://wiki.list.org/pages/viewpage.action?pageId=17891458
>
> The summary here is that the DNSKEY that Yahoo signs the message with
> (and has nothing to do with SPF as was suggested above) is invalidated
> by the mailing list's need to comply with legalities of needing a footer
> with unsubscribe information, etc.  By altering the message (as sent by
> yahoo) the checksum no longer matches and when a compliant receiver gets
> it, it looks at Yahoo's DMARC policy and by spec rejects the message
> entirely.  Thus Hotmail throwing e-mails from Yahoo in the trash.
>
> SPF / DNS keys / DMARC are more problem than fix at this point, and I'd
> actually recommend not enabling any of them.  The best answer is to stop
> using a mail provider (yahoo, aol, etc) that has such spectacularly bad
> DMARC rules if you are going to do things on mailing lists.
>
> - John 'Warthog9' Hawley

John, thanks once again on that link.  I've been reading it and one it links to.

http://wiki.list.org/display/DEV/DMARC

It appears the easiest alternative might be to use something like
dmarc_moderaction_action set to Munge.  This appears to be a
system-wide setting with per-list override options.  The result would
be that if a sender's DMARC policy is p=reject (and optionally
p=quarantine), manipulate the FROM/ReplyTo headers to be more "DMARC
friendly".

-- 
-Gene