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
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' HawleyJohn, 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
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 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) > >>> <**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.<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>
I'm testing syslinux PXE EFI boot with VMware workstation 9.04 running on Windows 8.1 VMware correctly performs the DHCP request indicating either the "EFI IA32" or "EFI BC" architecture and the TFTP server correctly sends back w/o error the "corresponding" syslinux.efi "EFI BC" -> EFI64\syslinux.efi "EFI IA32"-> EFI32\syslinux.efi but it always hangs w/o requesting any other transfer, I also tested using VMware 11 same results. any idea? Thanks