Re: [mailop] SPF strict / DMARC interaction / "big" provider behavior...
On Wed 17/Jun/2020 21:15:57 +0200 vom513 via mailop wrote: I run my own personal mail server, Linux, usual open source bits… One of my many layers/checks for inbound is SPF. Insofar as I reject at the “front door” (SMTP connection) if SPF fails (example is a domain using “-all”). I would imagine this is pretty vanilla so far compared to other folks. I do more or less the same, publish spf-all and honor it at the front door, and have no hitches. Possibly, what I do is to follow SPF spec, including checking DNSWL, both in the policy published and in the front door. Best Ale -- ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF strict / DMARC interaction / "big" provider behavior...
Dnia 17.06.2020 o godz. 15:31:40 John Levine via mailop pisze: > > For most of us, the only time we take "-all" seriously is if it's the > only thing in the SPF record, to state that a domain sends no mail at > all. Other than that, treat it the same as ~all or ?all because as > you have found a lot of people publish -all because it's "more secure" > but have no clue what they're doing. Couldn't agree more. That's pretty much the only approach to "-all" in SPF record that makes sense. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF strict / DMARC interaction / "big" provider behavior...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-06-17 at 16:45 -0400, Bill Cole via mailop wrote: > > This problem is part of why DMARC was developed. Very few people are > adequately confident of their understanding of DMARC and of its > reliability to make it the root cause of mail rejections that they do > not intend. Someone in the US State Department is apparently very confident, but mistaken. dig _dmarc.state.gov txt +short "v=DMARC1; p=reject; rua=mailto:dmarcrepor...@state.gov, mailto:repo...@dmarc.cyber.dhs.gov"; Yet they send mail out via Mailchimp, with a from: header of From: =?utf-8?Q?The=20Office=20of=20Foreign=20Missions?= and only a single DKIM signature from d=mailchimpapp.net. -BEGIN PGP SIGNATURE- iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCXuq5+xUcY2FybEBmaXZl LXRlbi1zZy5jb20ACgkQL6j7milTFsG7vACdFs0oYQODlWd+GygjGZQ21ZujilMA oIvX4F+BMFrIrVPxfakf9pDvn/q8 =uLoA -END PGP SIGNATURE- ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF strict / DMARC interaction / "big" provider behavior...
On 17 Jun 2020, at 15:15, vom513 via mailop wrote: My understanding for the longest time is that an SPF policy of “-all” is a strong statement and should be honored as such. A lot of people believed that a long time ago. However, those of us running systems that handle a substantial quantity of non-bulk B2B email quickly learned that Sturgeon's Law applies to the set of all email and DNS admins, and therefore "-all" defaults in SPF records are often an expression of ignorance rather than one of hostility to transparent forwarding or a description of reality. This problem is part of why DMARC was developed. Very few people are adequately confident of their understanding of DMARC and of its reliability to make it the root cause of mail rejections that they do not intend. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF strict / DMARC interaction / "big" provider behavior...
In article <2e5fef36-789f-61c2-41d6-dba139fc8...@heeg.de> you write: >I'm pretty wary of SPF, especially since it just breaks mail forwarding which >some of our users like to do to >consolidate all mail in one mailbox. I know they should not do this, ... People have been forwarding mail about as long as there has been electronic mail. The fact that SPF can't describe forwarded mail is a failure of SPF, not of mail. One of the reasons that DMARC allows either SPF or DKIM validation is that DKIM isn't affected by forwarding (at least not by normal forwarding.) What's really strange is that the guy who invented SPF ran pobox.com which is a mail forwarding service. I never understood what he was thinking. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF strict / DMARC interaction / "big" provider behavior...
Am 17.06.20 um 21:15 schrieb vom513 via mailop: > I know the ultimate answer is “do what makes sense for me” - but I’d love > some feedback from folks here on what they consider best practice etc. Also > please help me with my understanding of SPF / DMARC interactions (especially > with regard to what the big providers are doing) if I’m out of line. I'm pretty wary of SPF, especially since it just breaks mail forwarding which some of our users like to do to consolidate all mail in one mailbox. I know they should not do this, but attempts at enlightening them are pretty futile, and I don't want them to point their fingers at us about missed e-mails. At the moment, I do some DKIM checks (since that works mostly ok even in the presence of forwarding) and some very strict analysis of sender domains. A remarkable amount of spam is sent from domains which can be recognized as not trustworthy, for example because the domains are registered with anonymizing services and hosted at providers who don't give a f*ing f. I may look at SPF (especially in combination with DMARC) at a later time to detect some more unwanted mail but currently most of the remaining spam (as far as I can see) is the stuff being sent via cracked regular mail accounts. Body filtering is basically the only thing that helps against that (and of course, blocking mails from notoriously insecure providers from which legit mail is very unlikely.) Cheers, Hans-Martin ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF strict / DMARC interaction / "big" provider behavior...
In article <3e229a32-88db-4fdb-b67a-c68d0b65e...@gmail.com> you write: >SPF. Insofar as I reject at the “front door” (SMTP connection) if SPF fails >(example is a domain using >“-all”). I would imagine this is pretty vanilla so far compared to other >folks. To be blunt, it is among hobby mail servers. It isn't among people who actually want to provide mail service. For most of us, the only time we take "-all" seriously is if it's the only thing in the SPF record, to state that a domain sends no mail at all. Other than that, treat it the same as ~all or ?all because as you have found a lot of people publish -all because it's "more secure" but have no clue what they're doing. R's, John ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] SPF strict / DMARC interaction / "big" provider behavior...
Hello all, Apologies in advance if this is off-topic for this list. I hope it doesn’t stir too much of a hornet nest :) I run my own personal mail server, Linux, usual open source bits… One of my many layers/checks for inbound is SPF. Insofar as I reject at the “front door” (SMTP connection) if SPF fails (example is a domain using “-all”). I would imagine this is pretty vanilla so far compared to other folks. One of my kids got a part time job, and part of their onboarding HR stuff came to their address on my server. It was rejected. The sending domain has a “-all” and this message was from an outsourced HR “partner” that apparently was sending from a machine not in the SPF record anywhere… When they asked them to send to their @gmail.com - it came right through (but details did show SPF fail). I should also note the from domain has a DMARC policy of none. I’ve tested this a little bit, sending to my gmail / yahoo accounts. It seems like the behavior I see from some of the big guys (gmail and yahoo for this purpose) is: strict SPF (-all) + DMARC none == accept strict SPF (-all) + no DMARC record == accept strict SPF (-all) + DMARC reject== reject I managed to pretty much replicate this behavior on my server by having my SPF check just add the header (but not reject). I then let OpenDMARC do it’s thing (it’s thing being reject if need be). However this doesn’t sit well with me. I’ve put my policy back to dropping SPF hard fails at the front door. I think the case above that bothers me the most is the "strict SPF (-all) + no DMARC record == accept”. I was very surprised these got through. In fairness, the test messages I sent above pretty much all went to the providers “SPAM” folder. But I’m still bothered that they are accepting hard SPF fails. My understanding for the longest time is that an SPF policy of “-all” is a strong statement and should be honored as such. If the sending org can’t keep their servers and message sources straight and up to date - that’s their problem (well my problem too ultimately because I’m going to reject their mails from unauthorized sources). Taking this a step further, I feel like if the “big guys” accept these messages anyway, they have set a (bad) precedent and said in a manner of speaking “whats the point of having SPF, we will accept it anyway…”. I know the ultimate answer is “do what makes sense for me” - but I’d love some feedback from folks here on what they consider best practice etc. Also please help me with my understanding of SPF / DMARC interactions (especially with regard to what the big providers are doing) if I’m out of line. Thanks. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
