[syslinux] Lost hotmail, dmarc_moderaction_action

[Geert Stappers]

On Sat, Jan 03, 2015 at 02:46:02PM -0500, Gene Cumm wrote:
> On Sat, Jan 3, 2015 at 12:53 PM, John 'Warthog9' Hawley wrote:
> > On 01/03/2015 08:56 AM, Gene Cumm wrote:
> >> On Fri, Jan 2, 2015 at 3:43 PM, Geert Stappers 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:
> >>>>>
> >>>>> For some reason I have not received the original email
> >>>>
> >>>> 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
> >>>>
> >>>
> >>> 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 op yahoo.co.uk>
> >>>     (reason: 554 5.7.9 Message not accepted for policy reasons.  See http://postmaster.yahoo.com/errors/postmaster-28.html)
> >>> <**0 op yahoo.de>
> >>>     (reason: 554 5.7.9 Message not accepted for policy reasons.  See http://postmaster.yahoo.com/errors/postmaster-28.html)
> >>> <**0 op 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. 

<info from="web interface mailman" extra_from="backend mailinglist software">
  dmarc_moderation_action Option
  dmarc_moderation_action (privacy): Action to take when anyone posts
    to the list from a domain with a DMARC Reject/Quarantine Policy.

    Munge From -- applies the "from_is_list Munge From" transformation to
      these messages.

    Wrap Message -- applies the "from_is_list Wrap Message" transformation
      to these messages.

    Reject -- this automatically rejects the message by sending a bounce
      notice to the post's author. The text of the bounce notice can be
      configured by you.

    Discard -- this simply discards the message, with no notice sent to
      the post's author.

This setting takes precedence over the from_is_list setting if the
message is From: an affected domain and the setting is other than Accept.
</info>

<info from="web interface mailman">
  from_is_list Option
  from_is_list (general): Replace the From: header address with the
    list's posting address to mitigate issues stemming from the original
    From: domain's DMARC or similar policies.

  Several protocols now in wide use attempt to ensure that use of the
  domain in the author's address (ie, in the From: header field) is
  authorized by that domain. These protocols may be incompatible with
  common list features such as footers, causing participating email
  services to bounce list traffic merely because of the address in the
  From: field. This has resulted in members being unsubscribed despite
  being perfectly able to receive mail.

  The following actions are applied to all list messages when selected
  here. To apply these actions only to messages where the domain
  in the From: header is determined to use such a protocol, see the
  dmarc_moderation_action settings under Privacy options... -> Sender
  filters.

  Settings:

  No
    Do nothing special. This is appropriate for anonymous lists. It
    is appropriate for dedicated announcement lists, unless the From:
    address of authorized posters might be in a domain with a DMARC
    or similar policy. It is also appropriate if you choose to use
    dmarc_moderation_action other than Accept for this list.
  Munge From
    This action replaces the poster's address in the From: header with
    the list's posting address and adds the poster's address to the
    addresses in the original Reply-To: header.
  Wrap Message
    Just wrap the message in an outer message with the From: header
    containing the list's posting address and with the original From:
    address added to the addresses in the original Reply-To: header and
    with Content-Type: message/rfc822. This is effectively a one message
    MIME format digest.

  If dmarc_moderation_action applies to this message with an action
  other than Accept, that action rather than this is applied
</info>

Just, 2015-01-04, 12:30 UTC, was dmarc_moderation_action set to 'Wrap Message'
and I tend to switch to 'Reject' with a text like

  Your DMARC configuration doesn't allow us to forward your message. 


> This appears to be a system-wide setting with per-list override options.

No, 'dmarc_moderation_action' is per list.


> 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".

It doesn't make sense to be friendly to the unfriendly DMARC.


Groeten
Geert Stappers
-- 
Leven en laten leven
------------- volgend deel ------------
Een niet-tekst bijlage is gescrubt...
Naam: signature.asc
Type: application/pgp-signature
Grootte: 836 bytes
Omschrijving: Digital signature
URL : <http://www.zytor.com/pipermail/syslinux/attachments/20150104/65f74d58/attachment.sig>