Microsoft O365 labels nanog potential fraud?
Is anyone else getting this message on every nanog post today? "This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing<http://aka.ms/LearnAboutSpoofing]>" I don't know if this link itself is malware, as it goes to the MS store, or if something is broken in the Nanog Mail machine. If it's just me, never mind. I'll figure it out. -mel beckman
Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is concerned. These two systems above try to minimize spoofed e-mail by doing the following: SPF: Each domain adds a list of IP Addresses that are allowed to send e-mail on their behalf. DKIM: Each email sent by an "original" mail server is cryptographically signed with a key available, again, in the DNS. When you send an e-mail to a list, you send it to the mailing list mail server. After that, of the server forwards that e-mail to the recipients, its original address is shown, therefore if Outlook checks for SPF records, that check will fail. An easy way to get around this is for the list to change the From field to something else, like "Mel Beckman via NANOG" and a local email address. However, when you send that email, it may also be signed with DKIM: any change in subject (say "[NANOG]" is added) or the body (say "You received this email because you subscribed to NANOG" is appended) will also cause that check to fail. Typically the behavior of the recipient if one or both of these checks failed is described in yet another DNS record, called a DMARC Policy. Some set this to very strict levels (reject e-mail / send to spam), some others to warn the user (like what you saw?), and some others, knowing this happens, to ignore/notify. This message probably appears because of the above SPF / DKIM / DMARC combo but I can't be 100% sure from the provided info. In any case, this is likely not your fault. If you want to be sure, verify the contents of the e-mail against the public NANOG archive which is available over HTTPS. My guess is that nothing has been changed. Thanks, Antonios
On 29 Mar 2017, at 03:22, Mel Beckman <mel@beckman.org> wrote:
Is anyone else getting this message on every nanog post today?
"This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing<http://aka.ms/LearnAboutSpoofing]>"
I don't know if this link itself is malware, as it goes to the MS store, or if something is broken in the Nanog Mail machine.
If it's just me, never mind. I'll figure it out.
-mel beckman
Antonia's, Thanks for the very clear explanation. I use DKIM and SPF, but didn't know about this corner case. I'm surprised the SPF, etc architects missed it, or seem to have. In any event, I seem to be getting all the messages. -mel beckman
On Mar 29, 2017, at 12:04 AM, DaKnOb <daknob.mac@gmail.com> wrote:
Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is concerned. These two systems above try to minimize spoofed e-mail by doing the following:
SPF: Each domain adds a list of IP Addresses that are allowed to send e-mail on their behalf.
DKIM: Each email sent by an "original" mail server is cryptographically signed with a key available, again, in the DNS.
When you send an e-mail to a list, you send it to the mailing list mail server. After that, of the server forwards that e-mail to the recipients, its original address is shown, therefore if Outlook checks for SPF records, that check will fail. An easy way to get around this is for the list to change the From field to something else, like "Mel Beckman via NANOG" and a local email address.
However, when you send that email, it may also be signed with DKIM: any change in subject (say "[NANOG]" is added) or the body (say "You received this email because you subscribed to NANOG" is appended) will also cause that check to fail.
Typically the behavior of the recipient if one or both of these checks failed is described in yet another DNS record, called a DMARC Policy. Some set this to very strict levels (reject e-mail / send to spam), some others to warn the user (like what you saw?), and some others, knowing this happens, to ignore/notify.
This message probably appears because of the above SPF / DKIM / DMARC combo but I can't be 100% sure from the provided info.
In any case, this is likely not your fault. If you want to be sure, verify the contents of the e-mail against the public NANOG archive which is available over HTTPS. My guess is that nothing has been changed.
Thanks, Antonios
On 29 Mar 2017, at 03:22, Mel Beckman <mel@beckman.org> wrote:
Is anyone else getting this message on every nanog post today?
"This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing<http://aka.ms/LearnAboutSpoofing]>"
I don't know if this link itself is malware, as it goes to the MS store, or if something is broken in the Nanog Mail machine.
If it's just me, never mind. I'll figure it out.
-mel beckman
On 03/29/2017 04:17 AM, Mel Beckman wrote:
Thanks for the very clear explanation. I use DKIM and SPF, but didn't know about this corner case. I'm surprised the SPF, etc architects missed it, or seem to have. In any event, I seem to be getting all the messages.
I don't think they did miss it per say. SPF is specifically meant to say where senders are allowed to send from. Mailing lists (in some configurations), forwarders, et. al. (inadvertently) violate this when they re-send the message with the original sender from a not-explicitly-allowed source. Sender Rewriting Scheme is a way that these forwarding services can re-write the SMTP Envelope From address to not run afoul of SPF (et al). Mailing list managers, in particular, can also change the message in a few different ways to avoid some of these pitfalls. - Remove all but a subset of headers. - Alter the RFC 822 From: header such that the message appears to come from the mailing list its self. I also strongly recommend that mailing lists be viewed as an entity unto themselves. I.e. they receive the email, process it, and generate a new email /from/ /their/ /own/ /address/ with very similar content as the message they received. I strongly encourage mailing list admins to enable Variable Envelope Return Path to help identify which subscribed recipient causes each individual bounce, even if the problem is from downstream forwards. The problem with this is that it takes more processing power and bandwidth. Most people simply want an old school expansion that re-sends the same, unmodified, message to multiple recipients. - That methodology's heyday has come and mostly gone. -- Grant. . . . unix || die
In a message written on Wed, Mar 29, 2017 at 08:58:38AM -0600, Grant Taylor via NANOG wrote:
I also strongly recommend that mailing lists be viewed as an entity unto themselves. I.e. they receive the email, process it, and generate a new email /from/ /their/ /own/ /address/ with very similar content as the message they received.
I strongly encourage mailing list admins to enable Variable Envelope Return Path to help identify which subscribed recipient causes each individual bounce, even if the problem is from downstream forwards.
The problem with this is that it takes more processing power and bandwidth. Most people simply want an old school expansion that re-sends the same, unmodified, message to multiple recipients. - That methodology's heyday has come and mostly gone.
Actually, my problem is not so much processing power and bandwidth, but that every time I've encountered this problem I found a morass of painfully broken, horribly documented, super-complex software. With sendmail/postfix you can edit an alias file and say: bob: joe, tim, alex And boom, done. If I could enable some feature/module/whatever in either one with a line or two of config to make that do Variable Envelope Return Path I would, but every solution I know of requires setting up a complex milter, running some external daemon, which often depends on 3 different interpreted languages to be installed and so on down a dependency hell. While I haven't looked at real mailing list software recently (e.g. mailman) when I last did they didn't suport this either and it took a pile of 3rd party hacks to make it work. Why o why in 2017 can this not be a checkbox, a line of config, or so on. For that matter, setting up DKIM is horrendously complicated for no good reason... -- Leo Bicknell - bicknell@ufp.org PGP keys at http://www.ufp.org/~bicknell/
On Mar 29, 2017, at 11:06 AM, Leo Bicknell <bicknell@ufp.org> wrote:
While I haven't looked at real mailing list software recently (e.g. mailman) when I last did they didn't suport this either and it took a pile of 3rd party hacks to make it work.
The latest versions of Mailman (2.1.23 and 3.0.0) both work reasonably well out-of-the-box with SPF, DKIM, and DMARC. Some additional configuration tuning might be necessary for additional compatibility. However, those features are still available in an out-of-the-box configuration, they’re just not enabled by default because they might cause more problems than they would solve for certain types of typical installations. So, if you want those features, you need to turn them on. IMO, Mailman3 works better out-of-the-box with SPF, DKIM, and DMARC as compared to Mailman 2.1.x, but that codebase is still pretty fresh. We’re now using it by default for mailing lists hosted on python.org, but we have not yet converted any of the older Mailman 2.1.x lists over to Mailman 3. We haven’t noticed any major problems yet with the latest version of Mailman3, but we still want to be careful in our testing.
For that matter, setting up DKIM is horrendously complicated for no good reason…
Sites like DMARCian help with that process to a degree, but there’s still a lot of complexity there that I would like to see handled automatically. Unfortunately, that’s kind of the nature of the beast right now with these tools. The technology is still complex and difficult to configure, and it’s easy to set things up in a way that you wind up shooting yourself in the foot — and possibly with a large thermonuclear device. No provider is immune to these mistakes, and some providers are more likely to make big mistakes than others. -- Brad Knowles <brad@shub-internet.org>
* Grant Taylor via NANOG:
On 03/29/2017 04:17 AM, Mel Beckman wrote:
Thanks for the very clear explanation. I use DKIM and SPF, but didn't know about this corner case. I'm surprised the SPF, etc architects missed it, or seem to have. In any event, I seem to be getting all the messages.
I don't think they did miss it per say. SPF is specifically meant to say where senders are allowed to send from. Mailing lists (in some configurations), forwarders, et. al. (inadvertently) violate this when they re-send the message with the original sender from a not-explicitly-allowed source.
Sender Rewriting Scheme is a way that these forwarding services can re-write the SMTP Envelope From address to not run afoul of SPF (et al).
SPF (in its specified form) is very compatible with the way people have been running mailing lists since the mid-to-late 90s because the mailing list specifies itself as the SMTP envelope from address. This has the added benefit of enabling bounce processing. Unfortunately, the envelope from address is used for generating bounces only. Mail clients just show the header. That's why some SPF variants (like the one proposed by Microsoft) apply SPF rules to email headers as well, although this wasn't part of the original SPF spec (because it breaks too much). DKIM was designed from the start to (optionally) break mailing lists, and some mail providers now publish sender domain policies which other mail providers enforce. In effect, this requires pervasive header rewriting (within the mailing list software) before the message can be sent over the mailing list, obfuscating the true sender. It's a very unfortunate situation. The mailing list software could put the original sender address into a new header, and if that header is standardized, mail clients could just display that. But then, certain sender domains would just sign the absence of that header, and we are back to square one. Presumably, we could use a randomized header, so that at least DKIM protocol changes are required, but it is basically an arms race at this point.
On Wed, Mar 29, 2017 at 3:04 AM, DaKnOb <daknob.mac@gmail.com> wrote:
Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is concerned. These two systems above try to minimize spoofed e-mail by doing the following:
SPF: Each domain adds a list of IP Addresses that are allowed to send e-mail on their behalf.
DKIM: Each email sent by an "original" mail server is cryptographically signed with a key available, again, in the DNS.
When you send an e-mail to a list, you send it to the mailing list mail server. After that, of the server forwards that e-mail to the recipients, its original address is shown, therefore if Outlook checks for SPF records, that check will fail. An easy way to get around this is for the list to change the From field to something else, like "Mel Beckman via NANOG" and a local email address.
However, when you send that email, it may also be signed with DKIM: any change in subject (say "[NANOG]" is added) or the body (say "You received this email because you subscribed to NANOG" is appended) will also cause that check to fail.
Hello, Both SPF and DKIM are meant to be checked against the domain in the envelope sender (SMTP protocol-level return address) which the NANOG list sets to nanog-bounces@nanog.org. Checking against the message header "from" address is an incorrect implementation which will break essentially all mailing lists. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
Bill, If that's the case, then Microsoft appears to be at fault here. I'll try opening a ticket (I know. Windmills :) -mel On Mar 29, 2017, at 8:13 AM, William Herrin <bill@herrin.us<mailto:bill@herrin.us>> wrote: On Wed, Mar 29, 2017 at 3:04 AM, DaKnOb <daknob.mac@gmail.com<mailto:daknob.mac@gmail.com>> wrote: Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is concerned. These two systems above try to minimize spoofed e-mail by doing the following: SPF: Each domain adds a list of IP Addresses that are allowed to send e-mail on their behalf. DKIM: Each email sent by an "original" mail server is cryptographically signed with a key available, again, in the DNS. When you send an e-mail to a list, you send it to the mailing list mail server. After that, of the server forwards that e-mail to the recipients, its original address is shown, therefore if Outlook checks for SPF records, that check will fail. An easy way to get around this is for the list to change the From field to something else, like "Mel Beckman via NANOG" and a local email address. However, when you send that email, it may also be signed with DKIM: any change in subject (say "[NANOG]" is added) or the body (say "You received this email because you subscribed to NANOG" is appended) will also cause that check to fail. Hello, Both SPF and DKIM are meant to be checked against the domain in the envelope sender (SMTP protocol-level return address) which the NANOG list sets to nanog-bounces@nanog.org<mailto:nanog-bounces@nanog.org>. Checking against the message header "from" address is an incorrect implementation which will break essentially all mailing lists. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com<mailto:herrin@dirtside.com> bill@herrin.us<mailto:bill@herrin.us> Dirtside Systems ......... Web: <http://www.dirtside.com/>
On 03/29/2017 09:12 AM, William Herrin wrote:
Both SPF and DKIM are meant to be checked against the domain in the envelope sender (SMTP protocol-level return address) which the NANOG list sets to nanog-bounces@nanog.org. Checking against the message header "from" address is an incorrect implementation which will break essentially all mailing lists.
That may be what the original intent was. Every SPF implementation I've seen has checked the SMTP envelope FROM address /and/ the RFC 822 From: header address. Granted, that does not mean that it's the correct behavior. -- Grant. . . . unix || die
On Wed, Mar 29, 2017 at 11:25 AM, Grant Taylor via NANOG <nanog@nanog.org> wrote:
Every SPF implementation I've seen has checked the SMTP envelope FROM address /and/ the RFC 822 From: header address.
Hi Grant, The gold standard, Spamassassin, does not. Indeed, the message to which I reply was scored by spam assassin as "SPF_PASS" even though you do not include NANOG's servers in the SPF record for tnetconsulting.net. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
Indeed, in more detail (which I omitted for simplicity), these checks are performed in a series of headers, the last of which is the From: header. I think the “envelope-from” is either the first or the second in this 5-point list. That said, there are a lot of implementations out there that do not respect that and treat the From address as the sender whose honesty must be verified. Every time I send mail to a mailing list from my own domain, due to DMARC I get back several reports of SPF and DKIM fail, mainly because the mailing list messed up something.
On 29 Mar 2017, at 18:32, William Herrin <bill@herrin.us> wrote:
On Wed, Mar 29, 2017 at 11:25 AM, Grant Taylor via NANOG <nanog@nanog.org> wrote:
Every SPF implementation I've seen has checked the SMTP envelope FROM address /and/ the RFC 822 From: header address.
Hi Grant,
The gold standard, Spamassassin, does not. Indeed, the message to which I reply was scored by spam assassin as "SPF_PASS" even though you do not include NANOG's servers in the SPF record for tnetconsulting.net.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2017-03-29 at 11:32 -0400, William Herrin wrote:
The gold standard, Spamassassin, does not. Indeed, the message to which I reply was scored by spam assassin as "SPF_PASS" even though you do not include NANOG's servers in the SPF record for tnetconsulting.net.
The message from Mr. Taylor (to which Mr. Herrin is replying) arrived here with: Return-path: <nanog-bounces@nanog.org> From: Grant Taylor via NANOG <nanog@nanog.org> Reply-to: Grant Taylor <gtaylor@tnetconsulting.net> So an SPF implementation that checks either or both of the (rfc2821 envelope from / rfc2822 header from) domains will pass. The original was DKIM signed by d=tnetconsulting.net (c=simple/simple - you might want to change that) but of course that signature was broken by the nanog list handling. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAljb2dEACgkQL6j7milTFsGoxwCePikWwzhrqSLFV3QQIKNR8FfO eoAAnjjH7TgYcTSJC8DWe2l139iQfkkI =SEM6 -----END PGP SIGNATURE-----
The purpose of SPF is to REJECT messages before the data phase. This cannot be done if you are checking the RFC-822 From: header since that requires accepting the message and invalidates the entire purpose of SPF. I have never seen an SPF implementation that uses the RFC-822 header From. Doing so would be pointless.
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Grant Taylor via NANOG Sent: Wednesday, 29 March, 2017 09:26 To: nanog@nanog.org Subject: Re: Microsoft O365 labels nanog potential fraud?
Both SPF and DKIM are meant to be checked against the domain in the envelope sender (SMTP protocol-level return address) which the NANOG
On 03/29/2017 09:12 AM, William Herrin wrote: list
sets to nanog-bounces@nanog.org. Checking against the message header "from" address is an incorrect implementation which will break essentially all mailing lists.
That may be what the original intent was.
Every SPF implementation I've seen has checked the SMTP envelope FROM address /and/ the RFC 822 From: header address.
Granted, that does not mean that it's the correct behavior.
-- Grant. . . . unix || die
On Wednesday 29 March 2017 11:12:33 William Herrin wrote:
On Wed, Mar 29, 2017 at 3:04 AM, DaKnOb <daknob.mac@gmail.com> wrote:
Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is concerned. These two systems above try to minimize spoofed e-mail by doing the following:
SPF: Each domain adds a list of IP Addresses that are allowed to send e-mail on their behalf.
DKIM: Each email sent by an "original" mail server is cryptographically signed with a key available, again, in the DNS.
When you send an e-mail to a list, you send it to the mailing list mail server. After that, of the server forwards that e-mail to the recipients, its original address is shown, therefore if Outlook checks for SPF records, that check will fail. An easy way to get around this is for the list to change the From field to something else, like "Mel Beckman via NANOG" and a local email address.
However, when you send that email, it may also be signed with DKIM: any change in subject (say "[NANOG]" is added) or the body (say "You received this email because you subscribed to NANOG" is appended) will also cause that check to fail.
Hello,
Both SPF and DKIM are meant to be checked against the domain in the envelope sender (SMTP protocol-level return address) which the NANOG list sets to nanog-bounces@nanog.org. Checking against the message header "from" address is an incorrect implementation which will break essentially all mailing lists.
This is incomplete. TL;DR: SPF checks the envelope sender. DKIM doesn't check anything except to test that parts of the message haven't been altered. DMARC adds policy to both to check them against the header From:. Mailing list software may not work with DMARC-reject senders (but Nanog does). ---- SPF checks the envelope sender only. Some Microsoft implementations purportedly check the header From:, but they aren't supposed to. Microsoft at one time tried to extend SPF to check the header Sender or From via SPF 2.0, which didn't catch on. Large mail receivers have also extended SPF checks internally in various ways to try to infer whether messages are forged, but that's not really SPF. DKIM doesn't by default check anything except that the headers and body that were signed have not been altered since the signature was added. It definitely has nothing to do with the envelope sender. There was an ADSP extension to DKIM to add policy to the header From: address, but it is superceded by DMARC. DMARC adds sender policy to both mechanisms. For DMARC to pass, either SPF or DKIM must pass and the identifier must be aligned with the header From:. So for DMARC+SPF to pass not only must the message come from a source authorized by the envelope sender domain, but that domain must be the same domain (or parent domain or subdomain) of the header From: address. For DMARC+DKIM to pass, the DKIM signature must pass and the DKIM signing domain must be the same domain (or parent domain or subdomain) of the header From: address. Again, DMARC requires only one or the other mechanism to pass. So messages forwarded intact should be OK if they have an aligned DKIM signature. Mailing lists run by mailing list software usually alter the envelope sender. They can therefore create and pass their own SPF policy. However, if the From: address is preserved, this will not be an aligned message and will not pass DMARC+SPF. And of course if they don't modify the envelope sender, SPF will never pass. Mailing lists often modify either the subject line or message body. This breaks the existing DKIM signature. If they preserve the From: address, they will therefore never pass DMARC because they can't create an aligned signature. To work with DMARC-reject senders, mailing lists should either: a) not alter the existing message headers or body, so that pre-existing signatures can pass (Nanog works fine, for instance, so I doubt the OP on this thread is related). or b) replace the From: address, remove existing DKIM signatures, and add their own DKIM signature or c) reject posts from senders in DMARC-reject domains Other mail forwarders should not alter signed message headers or the message bodies. Microsoft's forwarding in particular tends to break forwarded messages by running them through Exchange internally, which likes to rewrite the message. This often breaks the DKIM signatures.
On Wed, Mar 29, 2017 at 12:24 PM, Alan Hodgson <ahodgson@lists.simkin.ca> wrote:
On Wednesday 29 March 2017 11:12:33 William Herrin wrote:
Both SPF and DKIM are meant to be checked against the domain in the envelope sender (SMTP protocol-level return address) which the NANOG list sets to nanog-bounces@nanog.org. Checking against the message header "from" address is an incorrect implementation which will break essentially all mailing lists.
This is incomplete.
TL;DR: SPF checks the envelope sender. DKIM doesn't check anything except to test that parts of the message haven't been altered. DMARC adds policy to both to check them against the header From:. Mailing list software may not work with DMARC-reject senders (but Nanog does).
Hi Alan, I accept your explanation as the correct one. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2017-03-29 at 09:24 -0700, Alan Hodgson wrote:
So for DMARC+SPF to pass not only must the message come from a source authorized by the envelope sender domain, but that domain must be the same domain (or parent domain or subdomain) of the header From: address.
For DMARC+DKIM to pass, the DKIM signature must pass and the DKIM signing domain must be the same domain (or parent domain or subdomain) of the header From: address.
Again, DMARC requires only one or the other mechanism to pass. So messages forwarded intact should be OK if they have an aligned DKIM signature.
Brad Knowles wrote:
...and it's easy to set things up in a way that you wind up shooting yourself in the foot -- and possibly with a large thermonuclear device.
For an example of that (unless I am misunderstanding something), we have: --> Hello marketo-email.box.com [192.28.147.169], pleased to meet you <-- MAIL FROM:<$MUNGED@marketo-email.box.com> <-- RCPT TO: ... dkim pass header.d=mktdns.com rfc2822 from header = $MUNGED@email.box.com dig _dmarc.email.box.com txt +short "v=DMARC1; p=reject; ..." dig email.box.com txt +short "v=spf1 ip4:192.28.147.168 -all" So given the dmarc reject policy, it needs to pass either spf (which fails 192.28.147.168 != 192.28.147.169), or dkim (which fails since it is not signed by anything related to email.box.com. Am I missing something, or is that just broken? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAljcJe4ACgkQL6j7milTFsFUMwCfT4Wgr0kUHjhVPvi0wER3Nfz+ osAAni5YH25tTCGk49jESd5NOKVk3Okd =JL7y -----END PGP SIGNATURE-----
On Wednesday 29 March 2017 14:28:30 Carl Byington wrote:
For an example of that (unless I am misunderstanding something), we have:
--> Hello marketo-email.box.com [192.28.147.169], pleased to meet you <-- MAIL FROM:<$MUNGED@marketo-email.box.com> <-- RCPT TO: ...
dkim pass header.d=mktdns.com rfc2822 from header = $MUNGED@email.box.com
dig _dmarc.email.box.com txt +short "v=DMARC1; p=reject; ..."
dig email.box.com txt +short "v=spf1 ip4:192.28.147.168 -all"
So given the dmarc reject policy, it needs to pass either spf (which fails 192.28.147.168 != 192.28.147.169), or dkim (which fails since it is not signed by anything related to email.box.com.
Am I missing something, or is that just broken?
That appears to be broken. The -all on the SPF record alone breaks it, since receivers should refuse it at that point. But yeah the DMARC is also broken. Interestingly, the mail I've seen recently from email.box.com has multiple signatures, one of which is from email.box.com. And it originated from 192.28.147.168. Weird.
In message <2066629.BbQ8KXnJic@skynet.simkin.ca>, Alan Hodgson writes:
On Wednesday 29 March 2017 14:28:30 Carl Byington wrote:
For an example of that (unless I am misunderstanding something), we have:
--> Hello marketo-email.box.com [192.28.147.169], pleased to meet you <-- MAIL FROM:<$MUNGED@marketo-email.box.com> <-- RCPT TO: ...
dkim pass header.d=mktdns.com rfc2822 from header = $MUNGED@email.box.com
dig _dmarc.email.box.com txt +short "v=DMARC1; p=reject; ..."
dig email.box.com txt +short "v=spf1 ip4:192.28.147.168 -all"
Well you should be checking the correct TXT record for SPF. dig marketo-email.box.com txt +short "v=spf1 ip4:192.28.147.168 ip4:192.28.147.169 -all"
So given the dmarc reject policy, it needs to pass either spf (which fails 192.28.147.168 != 192.28.147.169), or dkim (which fails since it is not signed by anything related to email.box.com.
Am I missing something, or is that just broken?
That appears to be broken. The -all on the SPF record alone breaks it, since receivers should refuse it at that point. But yeah the DMARC is also broken.
Interestingly, the mail I've seen recently from email.box.com has multiple signatures, one of which is from email.box.com. And it originated from 192.28.147.168. Weird. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, 2017-03-30 at 15:21 +1100, Mark Andrews wrote:
Well you should be checking the correct TXT record for SPF.
dig marketo-email.box.com txt +short "v=spf1 ip4:192.28.147.168 ip4:192.28.147.169 -all"
Hm, a closer reading of rfc7489 sheds some light on this: Would dmarc-spf consider marketo-email.box.com to be 'aligned' with the from header email.box.com domain? It is neither a child nor parent of email.box.com. The _dmarc txt record for email.box.com has no aspf: tag, so we should be operating in spf/dkim relaxed alignment mode. rfc7489, when discussing relaxed identifier alignment, says the "Organizational Domain" of the identifiers must match. But there is no explicit example of that. Instead, the examples talk about one of the identifiers being a parent of the other identifier. The envelope from marketo-email.box.com and the 2822 header from email.box.com have the same box.com organizational domain. If we ignore the examples in rfc7489, it looks like this is NOT broken. I am probably not the only one that wrote code matching on the parent/child relationship of the identifiers, rather than computing the Organizational Domains and matching those. As Mr. Hodgson pointed out, box.com has very recently started sending mail with multiple dkim signatures, header.d=email.box.com and 2822 header from = email.box.com. Now off to fix my code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAljcpTkACgkQL6j7milTFsHROACfYDmp1Vv7kUwWZQ9m1YCgSB+C y9kAnitNWUvORSQNgOv5AsyUL35Y8Yhc =CDq3 -----END PGP SIGNATURE-----
On Wednesday 29 March 2017 23:28:18 Carl Byington wrote:
Would dmarc-spf consider marketo-email.box.com to be 'aligned' with the from header email.box.com domain? It is neither a child nor parent of email.box.com.
As long as they're under the same Organizational Domain they should pass a relaxed mode test. The examples are somewhat meager in the RFC but the wording in section 3.1 seems clear. If senders want a tighter policy they have strict mode available.
participants (11)
-
Alan Hodgson -
Brad Knowles -
Carl Byington -
DaKnOb -
Florian Weimer -
Grant Taylor -
Keith Medcalf -
Leo Bicknell -
Mark Andrews -
Mel Beckman -
William Herrin