Re: [mailop] SPF recommendations
On 15/12/2017 15:40, Brandon Long via mailop wrote: > All that SPF authenticates is the RFC5321.From, which is rarely visible to > the end user and trivial for phishers to work around. > > Brandon And its often all that's needed, no its not complete, no its not perfect, but nothing ever is -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
On 15/12/2017 14:28, John Levine wrote: > In article <6582089ce2ad3fb3fd074ada73672...@ausics.net>, > Noel Butlerwrote: > >> Agreed, if I publish a -all (which I do and have done for a very very >> long time), I expect receivers doing SPF processing of my domains >> messages, to honor that! Who the hell are they to assume they know my >> network and its senders better than me. > > They don't know your network, but they know the junk that your users > send them, some from your network, some from other places. All the more reason to honor my -all If your not going to honor my decided polices, why bother with SPF, DKIM, DMARC at all, or are you in favor of selective ignorance, either way, everyone might as well stop using them all, right now if they take the attitude of some around here. > I have a vision of small senders who publish -all as tiny gorillas, > thumping their wee chests and bellowing "FEAR ME OH INTERNET" in their > adorable high squeaky voices. Some rather large gorilla's publish them as well :) > R's, > John errr I never asked the following, I know how it fails > PS: > > How does DMARC fail at forwarding? > Please review the previous million or so messages on this topic. -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
And for my feedback.. We use -all for important domains, involved in ecommerce or confidential data. And yes, sometimes we get a bounce, because someone forwarded their email to another party, but it is rare.. (and forwarding should be discouraged). However, it is better than the risk of abuse. Not that a great fan or proponent of SPF everywhere, or think it is the end all. And we also do 'some' recognition of failed SPF when we do filtering, but not so much. However, when it comes to big banks and big companies where 'phishing' is common, we do use it to seed our Known Sender Forgery system, but in those cases we actually treat -all and ~all quite similar. Companies of this size SHOULD know the dangers of phishing, and SHOULD have accurate SPF records.. And yes, it COULD trigger a rejection notice when coming through a forwarder, but should you forward something as sensitive as banking information ;) But it is only a 'small' part of the overall arsenal. Doesn't help much when 'phish' attacks use a domain with a small typo difference.. eg all the fake paypal/apple domains getting registered on a regular basis. On 17-12-15 06:12 AM, Al Iverson wrote: You're not wrong. I would only say say that perhaps this makes -all harmless versus something one truly needs to worry about or avoid. There's a lot of past, quite possibly bogus, guidance where we were all pushed as ESP senders to implement -all, given the impression that once upon a time it provided an indirect deliverability boost in some places. Inertia is strong. I still personally want -all for myself, because I think there are possibly a lot of third or fourth tier smaller ISPs, and hobbyists, and non-US ISPs, that perhaps have SPF support but aren't there with DMARC yet. Cheers, Al Iverson On Thu, Dec 14, 2017 at 5:28 PM, Brandon Longwrote: My point is that -all is policy, and most people ignore the policy portions of SPF because it completely fails a lot of forwarding cases. -all is asking receivers to reject mail that doesn't pass. ~all isn't policy. In practice, very few receivers implement SPF policy (except -all by itself for domains which don't send mail as a special case). Maybe there are some smaller receivers who will pay attention to it, but you're almost certainly going to get more false positives from them than real positives. And you won't even notice. If you want policy, use DMARC, it's what it's there for, and these things are considered. As much as DMARC rightly gets pushback for the parts of forwarding it fails at, it's definitely more useful for policy goals, and has much wider adoption. DKIM, for example, explicitly says that a DKIM fail means nothing. Which doesn't prevent folks from rejecting messages with broken DKIM signatures, probably the same folks who follow -all. Brandon On Thu, Dec 14, 2017 at 12:17 PM Al Iverson wrote: On Thu, Dec 14, 2017 at 2:14 PM, Brandon Long via mailop wrote: On Thu, Dec 14, 2017 at 11:09 AM Jim Popovitch wrote: On Thu, Dec 14, 2017 at 11:33 AM, Vladimir Dubrovin via mailop wrote: In fact, you should not use "-all" for your mail domain if you care about deliverability. FALSE! (Also, you should not randomly add CC recipients to the same mailinglist that you are responding to) Aside from a few HUGE providers, those with very large and disparate networks/offices/topology -all means that the domain operator knows what they are doing, knows what their network consists of and how email is routed within their network. It further states that the -all publisher has committed to staying abreast of what happens in their environment in order to assure their IP space is properly routing email. It instills confidence. ~all is just plain lazy, and is akin to saying that you don't have confidence in your ability to own and control your own network; and you want others to spend some level of time/money (in the form of CPU cycles) analyzing email emitted from your network to determine it's suitability for deliverability. Or, it acknowledges the fact that the people you send mail to may forward that mail, and trying to control that is silly. Yeah, but a fail doesn't magically turn into a pass if you turn -all into ~all. I don't think either is a universal use case, but I see good reasons for both ways and it depends on what type of company and mail sender you are. For me, I think -all makes a lot of sense for marketing senders and folks really worried about phishing/spoofing. And I see lots of -all mail get forwarded just fine, thanks to, for example, the fine folks at Google who write the return path when forwarding. :) Old school forwarding is still a pain even if you pull SPF out of the equation, no? Cheers, Al -- al iverson // wombatmail // miami http://www.aliverson.com http://www.spamresource.com
Re: [mailop] SPF recommendations (was: Re: Earthlink trouble with our PTR)
You're not wrong. I would only say say that perhaps this makes -all harmless versus something one truly needs to worry about or avoid. There's a lot of past, quite possibly bogus, guidance where we were all pushed as ESP senders to implement -all, given the impression that once upon a time it provided an indirect deliverability boost in some places. Inertia is strong. I still personally want -all for myself, because I think there are possibly a lot of third or fourth tier smaller ISPs, and hobbyists, and non-US ISPs, that perhaps have SPF support but aren't there with DMARC yet. Cheers, Al Iverson On Thu, Dec 14, 2017 at 5:28 PM, Brandon Longwrote: > My point is that -all is policy, and most people ignore the policy portions > of SPF because it completely fails a lot of forwarding cases. > > -all is asking receivers to reject mail that doesn't pass. > > ~all isn't policy. > > In practice, very few receivers implement SPF policy (except -all by itself > for domains which don't send mail as a special case). > > Maybe there are some smaller receivers who will pay attention to it, but > you're almost certainly going to get more false positives from them than > real positives. And you won't even notice. > > If you want policy, use DMARC, it's what it's there for, and these things > are considered. As much as DMARC rightly gets pushback for the parts of > forwarding it fails at, it's definitely more useful for policy goals, and > has much wider adoption. > > DKIM, for example, explicitly says that a DKIM fail means nothing. Which > doesn't prevent folks from rejecting messages with broken DKIM signatures, > probably the same folks who follow > -all. > > Brandon > > > On Thu, Dec 14, 2017 at 12:17 PM Al Iverson wrote: >> >> On Thu, Dec 14, 2017 at 2:14 PM, Brandon Long via mailop >> wrote: >> > >> > On Thu, Dec 14, 2017 at 11:09 AM Jim Popovitch wrote: >> >> >> >> On Thu, Dec 14, 2017 at 11:33 AM, Vladimir Dubrovin via mailop >> >> wrote: >> >> > >> >> > In fact, you should not use "-all" for your mail domain if you care >> >> > about deliverability. >> >> >> >> FALSE! (Also, you should not randomly add CC recipients to the same >> >> mailinglist that you are responding to) >> >> >> >> Aside from a few HUGE providers, those with very large and disparate >> >> networks/offices/topology >> >> >> >> -all means that the domain operator knows what they are doing, knows >> >> what their network consists of and how email is routed within their >> >> network. It further states that the -all publisher has committed to >> >> staying abreast of what happens in their environment in order to >> >> assure their IP space is properly routing email. It instills >> >> confidence. >> >> >> >> ~all is just plain lazy, and is akin to saying that you don't have >> >> confidence in your ability to own and control your own network; and >> >> you want others to spend some level of time/money (in the form of CPU >> >> cycles) analyzing email emitted from your network to determine it's >> >> suitability for deliverability. >> > >> > Or, it acknowledges the fact that the people you send mail to may >> > forward >> > that >> > mail, and trying to control that is silly. >> >> Yeah, but a fail doesn't magically turn into a pass if you turn -all into >> ~all. >> >> I don't think either is a universal use case, but I see good reasons >> for both ways and it depends on what type of company and mail sender >> you are. For me, I think -all makes a lot of sense for marketing >> senders and folks really worried about phishing/spoofing. And I see >> lots of -all mail get forwarded just fine, thanks to, for example, the >> fine folks at Google who write the return path when forwarding. :) >> >> Old school forwarding is still a pain even if you pull SPF out of the >> equation, no? >> >> Cheers, >> Al >> >> -- >> al iverson // wombatmail // miami >> http://www.aliverson.com >> http://www.spamresource.com >> >> ___ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- al iverson // wombatmail // miami http://www.aliverson.com http://www.spamresource.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
On 2017-12-15 10:06:44 (+1000), Noel Butler wrote: On 15/12/2017 09:27, Grant Taylor via mailop wrote: On 12/14/2017 03:28 PM, Brandon Long via mailop wrote: My point is that -all is policy, and most people ignore the policy portions of SPF because it completely fails a lot of forwarding cases. Every postmaster (or organization behind them) has the prerogative to run their mail server(s) the way that they want to. Agreed, if I publish a -all (which I do and have done for a very very long time), I expect receivers doing SPF processing of my domains messages, to honor that! Who the hell are they to assume they know my network and its senders better than me. The pros and cons of SPF -all vs. ~all have been discussed often on this mailing list (do people read archives anymore?) and the discussion always ends up split between the "receivers with many non-techy users who just want their mail" and "senders who insist they know where all their mail originates". If you're a large enough receiver, I think you probably have enough other data/signals to treat SPF -all fails simply as another signal in a more elaborate scoring system. If you're a small enough sender, you can probably insist that your users use your MSAs. I publish -all for my personal domain because I know all the users and I can whitelist plain forwarders (e.g. freebsd.org). My -all indicates that any message with an envelope @trouble.is that does not come from one of my listed servers is so much more likely to be a forgery that I don't care about the few exceptions. Depending on their users, everyone will have different policies. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
On Thu, Dec 14, 2017 at 7:16 PM Grant Taylor via mailopwrote: > On 12/14/2017 06:23 PM, Steve Atkins wrote: > > If you want to argue more loudly that you *do* understand what it means > > you could publish a matching DMARC record with p=discard. Doing that > would > > tell recipient ISPs that either you've actually done appropriate analysis > > of your mail stream, you understand that rejecting mail with SPF -all > > failures will cause legitimate mail to be lost and have made an informed > > decision. Or, at least, that you're saying that's the case. They're more > > likely to trust your assertion in that case - though it's still just > > a signal that they will combine with others before deciding whether or > > not to deliver an email. > > So why do people believe me more now when I publish p=reject for DMARC > than they did when I published -all for SPF? > Depending on how you count, DMARC is the third or fourth attempt at policy publishing for email. As these things go, it incorporates a lot of things that were learned in real world usage of the previous attempts, including SPF. It's much wider adoption seems at least partially to validate the improvements. That said, it may not be the last attempt, it's certainly not perfect. What happens when a lot of people shoot themselves in the foot and > receivers start giving DMARC less and less credence. Will we then need > something new to convince them that I really do mean what I publish? > DMARC gives senders the ability to actually judge whether they have control of their mail sending, and also gives senders the ability to judge whether and how folks are honoring it. I view that as a self perpetuating problem. I'd rather stop that cycle > and take a stand now. > > IMHO there is too much coddling in the world. > It's not coddling, SPF policy is flawed and it's been superseded by something better. The community could have tried to fix SPF directly, things like SRS were working in that direction, but the community decided that wasn't the right direction. Also, at some point, this is about users, and they want their mail. Our goal should be making sure they get the mail they should and not the bad stuff. There is no black & white algorithm to apply to do that. Users use forwarding services, many fairly prominently (alumni.mit.edu, ieee.org, acm.org are the most obvious examples that come to mind, but there are plenty more). Mail routing is complicated in the real world. You can be hostile to your users, and I'm sure there are users who either don't know better or like the BOFH attitude. It's a nice niche. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
On 14 Dec 2017, at 22:09 (-0500), Grant Taylor via mailop wrote: What happens when a lot of people shoot themselves in the foot and receivers start giving DMARC less and less credence. Will we then need something new to convince them that I really do mean what I publish? Yes. It will happen slower with DMARC than it did with SPF because the bar is high for getting DMARC wrong in just the right way to shoot one's foot without blowing it off, whereas it is really easy to do with SPF. Specifically, I've seen incorrect '-all' SPF tails survive for many months without being fixed, because the legitimate mail being rejected had an undeliverable sender address (i.e. couldn't deliver OR bounce, just died.) DMARC errors are more likely to be either mostly harmless or more like a head-bazooka than a foot-bullet. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steady Work: https://linkedin.com/in/billcole ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
On Thu, Dec 14, 2017 at 8:05 PM Noel Butlerwrote: > On 15/12/2017 10:29, st...@greengecko.co.nz wrote: > > > > December 15, 2017 1:12 PM, "Noel Butler" wrote: > > On 15/12/2017 09:27, Grant Taylor via mailop wrote: > > On 12/14/2017 03:28 PM, Brandon Long via mailop wrote: > > My point is that -all is policy, and most people ignore the policy > portions of SPF because it completely fails a lot of forwarding cases. > > > Every postmaster (or organization behind them) has the prerogative to run > their mail server(s) the way that they want to. > > > Agreed, if I publish a -all (which I do and have done for a very very long > time), I expect receivers doing SPF processing of my domains messages, to > honor that! Who the hell are they to assume they know my network and its > senders better than me. > > > You really don't have any rights over an email once delivered, and given > just how hard it is to ensure your SPF is followed in these days of mobile > devices I don't think you should. Expect the receiving mail platform to use > the published policy to score a message sure, but not to dictate delivery. > > Sorry if this point has been made before. > > > But its not delivered in most cases, SPF checking should be done on the > MTA, yes yes yes yes, i'm very aware some people choose to not do it that > way, but most providers I've comer across do use MTA, so therefor the > message is not accepted for delivery. > > If we all start making decisions over those who expect a different result, > WTF is the whole point. Are you going to allow your users to get phished > because you chose to score rather than honor the banks -all, you need to > remember most people are not technical, they dont read half the crap that > gets put in a report, so congratulations you've just allowed a bunch of > 80yo non tech grandparents from being phished because you said the bank > doesnt know what they are doing and let their message through so they could > click on the fraudulent link and lose half their life savings. > All that SPF authenticates is the RFC5321.From, which is rarely visible to the end user and trivial for phishers to work around. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
In article <6582089ce2ad3fb3fd074ada73672...@ausics.net>, Noel Butlerwrote: >Agreed, if I publish a -all (which I do and have done for a very very >long time), I expect receivers doing SPF processing of my domains >messages, to honor that! Who the hell are they to assume they know my >network and its senders better than me. They don't know your network, but they know the junk that your users send them, some from your network, some from other places. I have a vision of small senders who publish -all as tiny gorillas, thumping their wee chests and bellowing "FEAR ME OH INTERNET" in their adorable high squeaky voices. R's, John PS: >How does DMARC fail at forwarding? Please review the previous million or so messages on this topic. -- Regards, John Levine, jo...@iecc.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 recommendations
On 15/12/2017 10:29, st...@greengecko.co.nz wrote: > December 15, 2017 1:12 PM, "Noel Butler"wrote: > > On 15/12/2017 09:27, Grant Taylor via mailop wrote: > On 12/14/2017 03:28 PM, Brandon Long via mailop wrote: My point is that -all > is policy, and most people ignore the policy portions of SPF because it > completely fails a lot of forwarding cases. > Every postmaster (or organization behind them) has the prerogative to run > their mail server(s) the way that they want to. Agreed, if I publish a -all (which I do and have done for a very very long time), I expect receivers doing SPF processing of my domains messages, to honor that! Who the hell are they to assume they know my network and its senders better than me. You really don't have any rights over an email once delivered, and given just how hard it is to ensure your SPF is followed in these days of mobile devices I don't think you should. Expect the receiving mail platform to use the published policy to score a message sure, but not to dictate delivery. Sorry if this point has been made before. But its not delivered in most cases, SPF checking should be done on the MTA, yes yes yes yes, i'm very aware some people choose to not do it that way, but most providers I've comer across do use MTA, so therefor the message is not accepted for delivery. If we all start making decisions over those who expect a different result, WTF is the whole point. Are you going to allow your users to get phished because you chose to score rather than honor the banks -all, you need to remember most people are not technical, they dont read half the crap that gets put in a report, so congratulations you've just allowed a bunch of 80yo non tech grandparents from being phished because you said the bank doesnt know what they are doing and let their message through so they could click on the fraudulent link and lose half their life savings. and the "mobile users" debate is about 15 years too late, if they want to use our domains, they can use our submission servers :) -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations (was: Re: Earthlink trouble with our PTR)
On Thu, Dec 14, 2017 at 8:07 PM, Bill Colewrote: > On 14 Dec 2017, at 14:01 (-0500), Jim Popovitch wrote: > >> Aside from a few HUGE providers, those with very large and disparate >> networks/offices/topology > > > SPF isn't related to the complexity of a network, but control of users using > a domain name, which is a very different thing. Forget about users, think IoT devices. ~all makes it easy for a hacked device to send emails using your domain. >> -all means that the domain operator knows what they are doing, > > > No, it means they know what their users do. Not every network or domain is used as a mailbox provider. > Or that they THINK they do. > >> knows >> what their network consists of and how email is routed within their >> network. It further states that the -all publisher has committed to >> staying abreast of what happens in their environment in order to >> assure their IP space is properly routing email. It instills >> confidence. > > > There continue to be sites that do traditional ~/.forward-style transparent > SMTP forwarding, which preserves the envelope sender as received. There > continue to be websites which give users the ability to send content to > others which use the address of the user initiating the action as the > envelope sender, so that bounces go to the person who might care. > > Last I checked, it was frowned upon for sysadmins to execute users who > obliviously violate a SPF '-all' policy by mailing a 'wrong' person or using > a 'wrong' 3rd-party system. > > >> ~all is just plain lazy, and is akin to saying that you don't have >> confidence in your ability to own and control your own network; > > > You keep using that word. I do not think it means what you think it means. Ahh, a Princess Bride fan... > If you consider users to be a subordinate part of a "network" then no > "network" is controllable or should be. No, that's not what I'm saying. Forget about users, think spambot infested devices on your network (or on someone else's network using your domain). >> and >> you want others to spend some level of time/money (in the form of CPU >> cycles) analyzing email emitted from your network to determine it's >> suitability for deliverability. > > > There you go saying "your network" again, yet fundamentally '~all' says 'my > users might cause mail using my domain name to come from networks OTHER THAN > mine.' Which is true of almost any significant set of users. Mail actually > from the domain owner's network properly will be authenticated by what comes > BEFORE the '~all' default. Of course, but we're not really discussing what comes before the ~all or-all, rather what comes after the properly identified network resources listed in the SPF RR. -Jim P. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
On 12/14/2017 06:23 PM, Steve Atkins wrote: If you want to argue more loudly that you *do* understand what it means you could publish a matching DMARC record with p=discard. Doing that would tell recipient ISPs that either you've actually done appropriate analysis of your mail stream, you understand that rejecting mail with SPF -all failures will cause legitimate mail to be lost and have made an informed decision. Or, at least, that you're saying that's the case. They're more likely to trust your assertion in that case - though it's still just a signal that they will combine with others before deciding whether or not to deliver an email. So why do people believe me more now when I publish p=reject for DMARC than they did when I published -all for SPF? What happens when a lot of people shoot themselves in the foot and receivers start giving DMARC less and less credence. Will we then need something new to convince them that I really do mean what I publish? I view that as a self perpetuating problem. I'd rather stop that cycle and take a stand now. IMHO there is too much coddling in the world. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
On 12/14/2017 05:29 PM, st...@greengecko.co.nz wrote: given just how hard it is to ensure your SPF is followed in these days of mobile devices I don't think you should I'll argue that mobile devices should be connecting to MSAs that are under full control and configured to work within SPF (et al.) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
> On Dec 14, 2017, at 4:06 PM, Noel Butlerwrote: > > On 15/12/2017 09:27, Grant Taylor via mailop wrote: > >> On 12/14/2017 03:28 PM, Brandon Long via mailop wrote: >>> My point is that -all is policy, and most people ignore the policy portions >>> of SPF because it completely fails a lot of forwarding cases. >> >> Every postmaster (or organization behind them) has the prerogative to run >> their mail server(s) the way that they want to. > > Agreed, if I publish a -all (which I do and have done for a very very long > time), I expect receivers doing SPF processing of my domains messages, to > honor that! Who the hell are they to assume they know my network and its > senders better than me. > They don't answer to you - who the hell are you to assume you know what their users want more than they do? They answer to their users. If it is mail that their users are likely to want (because, for instance, they're forwarding mail from somewhere else) then they'll deliver it. You do not dictate policy to the receiving ISP. You, at most, provide a signal to that ISP that gives them additional information about your intent and your policies. They will combine that with their other data, weighted appropriately according to their experience, demographics and policies. The appropriate weighting for a failed SPF -all (when making delivery decisions) is probably going to be very, very low. It's not symmetrical - an SPF pass may have a significant effect on delivery decisions. Part of the reason that the weighting for a failed SPF -all is so low is because there's widespread experience that a) those publishing it don't necessarily understand what it implies and b) recipients often actually want the mail. If you want to argue more loudly that you *do* understand what it means you could publish a matching DMARC record with p=discard. Doing that would tell recipient ISPs that either you've actually done appropriate analysis of your mail stream, you understand that rejecting mail with SPF -all failures will cause legitimate mail to be lost and have made an informed decision. Or, at least, that you're saying that's the case. They're more likely to trust your assertion in that case - though it's still just a signal that they will combine with others before deciding whether or not to deliver an email. (Failed SPF is still a useful signal for some things, though, particularly when deciding whether or not to send an asynchronous bounce.) Cheers, Steve ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
> On Dec 14, 2017, at 3:27 PM, Grant Taylor via mailop> wrote: > >> In practice, very few receivers implement SPF policy (except -all by itself >> for domains which don't send mail as a special case). > > What sort of data / experience do you have to back that statement up? (I've > not looked for any.) I don’t know there’s any published data. However, I’ve examined thousands (hundreds of thousands?) of lines of SMTP log files, monitored hundreds of sends to millions of emails and have been paying attention to what does and does not get email delivered / not delivered for more than 15 years. My experience matches Brandon’s; there are very few places and no one of any size that is rejecting solely on a SPF -all record. My recommendations are ~all is fine as is -all. Some folks are more comfortable with one or the other. In practice they give senders the same practical recommendation. Know, too, that at least one Very Large Provider (covering up to 70% of addresses on some mailing lists) not only doesn’t bounce mail with a -all, they make some guesses about SPF and will label mail “SPF (best-guess) Pass” for some cases. Cases that I’ve investigated include a rDNS domain match between the connecting IP and the 5321.from domain as well as the sending IP also being the MX for the domain. In other words, you can ask for whatever policy you want. But no one has to comply with it. And, the current reality is that few major receivers are complying with those requests. laura -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
It seems to raise some feelings... On 15-12-17 01:06, Noel Butler wrote: On 15/12/2017 09:27, Grant Taylor via mailop wrote: On 12/14/2017 03:28 PM, Brandon Long via mailop wrote: My point is that -all is policy, and most people ignore the policy portions of SPF because it completely fails a lot of forwarding cases. Every postmaster (or organization behind them) has the prerogative to run their mail server(s) the way that they want to. Agreed, if I publish a -all (which I do and have done for a very very long time), I expect receivers doing SPF processing of my domains messages, to honor that! Who the hell are they to assume they know my network and its senders better than me. Also agreed. I run a very small private mailserver and publish a strict SPF policy. I'm pretty sure many small organizations will find it easier to implement SPF than DMARC. (Yes I'm also using DMARC.) Also I know for sure that any mail not originating from my mail server is not a valid mail, so I'm wondering a bit why some of you really like to accept mail that fails the policy of the originating domain holder. I'm a bit worried that when others don't honor my SPF policy, then I'm more at risk because I'm less protected against people who forge email addresses. Sure it is just a policy and other mail administrators can and should follow their own reasoning, but being nice towards SPF-publishing senders (and getting less spam by doing so) surely is an option to consider? Forwarding cases, well... like DKIM / DMARC has no forwarding problems. Maybe we should get rid of forwarding anyway but I get it that it is an important consideration for some of us ;) Cheers, Evert ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations (was: Re: Earthlink trouble with our PTR)
On 14 Dec 2017, at 14:01 (-0500), Jim Popovitch wrote: Aside from a few HUGE providers, those with very large and disparate networks/offices/topology SPF isn't related to the complexity of a network, but control of users using a domain name, which is a very different thing. -all means that the domain operator knows what they are doing, No, it means they know what their users do. Or that they THINK they do. knows what their network consists of and how email is routed within their network. It further states that the -all publisher has committed to staying abreast of what happens in their environment in order to assure their IP space is properly routing email. It instills confidence. There continue to be sites that do traditional ~/.forward-style transparent SMTP forwarding, which preserves the envelope sender as received. There continue to be websites which give users the ability to send content to others which use the address of the user initiating the action as the envelope sender, so that bounces go to the person who might care. Last I checked, it was frowned upon for sysadmins to execute users who obliviously violate a SPF '-all' policy by mailing a 'wrong' person or using a 'wrong' 3rd-party system. ~all is just plain lazy, and is akin to saying that you don't have confidence in your ability to own and control your own network; You keep using that word. I do not think it means what you think it means. If you consider users to be a subordinate part of a "network" then no "network" is controllable or should be. and you want others to spend some level of time/money (in the form of CPU cycles) analyzing email emitted from your network to determine it's suitability for deliverability. There you go saying "your network" again, yet fundamentally '~all' says 'my users might cause mail using my domain name to come from networks OTHER THAN mine.' Which is true of almost any significant set of users. Mail actually from the domain owner's network properly will be authenticated by what comes BEFORE the '~all' default. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steady Work: https://linkedin.com/in/billcole ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
December 15, 2017 1:12 PM, "Noel Butler" wrote: On 15/12/2017 09:27, Grant Taylor via mailop wrote: On 12/14/2017 03:28 PM, Brandon Long via mailop wrote:My point is that -all is policy, and most people ignore the policy portions of SPF because it completely fails a lot of forwarding cases. Every postmaster (or organization behind them) has the prerogative to run their mail server(s) the way that they want to. Agreed, if I publish a -all (which I do and have done for a very very long time), I expect receivers doing SPF processing of my domains messages, to honor that! Who the hell are they to assume they know my network and its senders better than me. You really don't have any rights over an email once delivered, and given just how hard it is to ensure your SPF is followed in these days of mobile devices I don't think you should. Expect the receiving mail platform to use the published policy to score a message sure, but not to dictate delivery. Sorry if this point has been made before. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
On 15/12/2017 09:27, Grant Taylor via mailop wrote: > On 12/14/2017 03:28 PM, Brandon Long via mailop wrote: > >> My point is that -all is policy, and most people ignore the policy portions >> of SPF because it completely fails a lot of forwarding cases. > > Every postmaster (or organization behind them) has the prerogative to run > their mail server(s) the way that they want to. Agreed, if I publish a -all (which I do and have done for a very very long time), I expect receivers doing SPF processing of my domains messages, to honor that! Who the hell are they to assume they know my network and its senders better than me. > -all is asking receivers to reject mail that doesn't pass. > Yes. > > I, as a sender, have decided that I want receivers to reject messages that do > not match my published policy. Period. End of story. agreed! How does DMARC fail at forwarding? DMARC (SPF and / or DKIM) specify who is allowed to send email, including forwarding, on the purported sending domains behalf. Over the large number of years I've run SPF I've had no complaints about forwarding problems, even most mailing lists get it right, something I can *NOT* say about DKIM, which has given us grief, so much so, we stopped using it. -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations
On 12/14/2017 03:28 PM, Brandon Long via mailop wrote: My point is that -all is policy, and most people ignore the policy portions of SPF because it completely fails a lot of forwarding cases. Every postmaster (or organization behind them) has the prerogative to run their mail server(s) the way that they want to. That doesn't mean that the policy is any less a policy. It just means that people may not honor it. Nor does the fact that receivers may not honor it mean that senders should not publish the policy that they want. -all is asking receivers to reject mail that doesn't pass. Yes. I, as a sender, have decided that I want receivers to reject messages that do not match my published policy. Period. End of story. In practice, very few receivers implement SPF policy (except -all by itself for domains which don't send mail as a special case). What sort of data / experience do you have to back that statement up? (I've not looked for any.) Maybe there are some smaller receivers who will pay attention to it, but you're almost certainly going to get more false positives from them than real positives. And you won't even notice. (Data?) If you want policy, use DMARC, it's what it's there for, and these things are considered. As much as DMARC rightly gets pushback for the parts of forwarding it fails at, it's definitely more useful for policy goals, and has much wider adoption. How does DMARC fail at forwarding? DMARC (SPF and / or DKIM) specify who is allowed to send email, including forwarding, on the purported sending domains behalf. If I don't authorize anyone other than my MTA to send email (as short sighted as that may or may not be), then anyone else sending email claiming to be from me is blatantly unauthorized. Do people forward messages? Do mailing lists redistribute messages? Sure. Did my server contact the ultimate recipients and deliver a message on my behalf in these cases? Absolutely not. So is the message that was distributed purporting to be from me legitimate or not? - There's a lot of room for debate on that. But it does not change the fact that SPF / DKIM / DMARC are designed to provide information and add validity to inform recipients who is authorized to send message and derive who is not. - What the receiver does with said information is at the receiving postmaster's (or their organization) discretion. I feel like (a significant portion of) many discussions around SPF / DKIM / DMARC revolve around what I consider to be a priming issue. - People don't want to publish / filter a $Technology because not enough other people are filtering / publishing said $Technology. I personally believe in SPF / DKIM / DMARC technologies enough that I both publish information and run filters based on the information that others publish. - I running my mail server for the world that I want, not the world that we have. - Hopefully, someday, the gray area between the two will get smaller. DKIM, for example, explicitly says that a DKIM fail means nothing. Which doesn't prevent folks from rejecting messages with broken DKIM signatures, probably the same folks who follow IMHO DKIM is to be considered a proof positive, that a message has not been modified. You can't prove the negative, that a message has been modified. - I believe that other cryptographic signatures are in a similar position. (I'm ignoring collisions for this discussion.) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations (was: Re: Earthlink trouble with our PTR)
My point is that -all is policy, and most people ignore the policy portions of SPF because it completely fails a lot of forwarding cases. -all is asking receivers to reject mail that doesn't pass. ~all isn't policy. In practice, very few receivers implement SPF policy (except -all by itself for domains which don't send mail as a special case). Maybe there are some smaller receivers who will pay attention to it, but you're almost certainly going to get more false positives from them than real positives. And you won't even notice. If you want policy, use DMARC, it's what it's there for, and these things are considered. As much as DMARC rightly gets pushback for the parts of forwarding it fails at, it's definitely more useful for policy goals, and has much wider adoption. DKIM, for example, explicitly says that a DKIM fail means nothing. Which doesn't prevent folks from rejecting messages with broken DKIM signatures, probably the same folks who follow -all. Brandon On Thu, Dec 14, 2017 at 12:17 PM Al Iversonwrote: > On Thu, Dec 14, 2017 at 2:14 PM, Brandon Long via mailop > wrote: > > > > On Thu, Dec 14, 2017 at 11:09 AM Jim Popovitch wrote: > >> > >> On Thu, Dec 14, 2017 at 11:33 AM, Vladimir Dubrovin via mailop > >> wrote: > >> > > >> > In fact, you should not use "-all" for your mail domain if you care > >> > about deliverability. > >> > >> FALSE! (Also, you should not randomly add CC recipients to the same > >> mailinglist that you are responding to) > >> > >> Aside from a few HUGE providers, those with very large and disparate > >> networks/offices/topology > >> > >> -all means that the domain operator knows what they are doing, knows > >> what their network consists of and how email is routed within their > >> network. It further states that the -all publisher has committed to > >> staying abreast of what happens in their environment in order to > >> assure their IP space is properly routing email. It instills > >> confidence. > >> > >> ~all is just plain lazy, and is akin to saying that you don't have > >> confidence in your ability to own and control your own network; and > >> you want others to spend some level of time/money (in the form of CPU > >> cycles) analyzing email emitted from your network to determine it's > >> suitability for deliverability. > > > > Or, it acknowledges the fact that the people you send mail to may forward > > that > > mail, and trying to control that is silly. > > Yeah, but a fail doesn't magically turn into a pass if you turn -all into > ~all. > > I don't think either is a universal use case, but I see good reasons > for both ways and it depends on what type of company and mail sender > you are. For me, I think -all makes a lot of sense for marketing > senders and folks really worried about phishing/spoofing. And I see > lots of -all mail get forwarded just fine, thanks to, for example, the > fine folks at Google who write the return path when forwarding. :) > > Old school forwarding is still a pain even if you pull SPF out of the > equation, no? > > Cheers, > Al > > -- > al iverson // wombatmail // miami > http://www.aliverson.com > http://www.spamresource.com > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations (was: Re: Earthlink trouble with our PTR)
On Thu, Dec 14, 2017 at 2:14 PM, Brandon Long via mailopwrote: > > On Thu, Dec 14, 2017 at 11:09 AM Jim Popovitch wrote: >> >> On Thu, Dec 14, 2017 at 11:33 AM, Vladimir Dubrovin via mailop >> wrote: >> > >> > In fact, you should not use "-all" for your mail domain if you care >> > about deliverability. >> >> FALSE! (Also, you should not randomly add CC recipients to the same >> mailinglist that you are responding to) >> >> Aside from a few HUGE providers, those with very large and disparate >> networks/offices/topology >> >> -all means that the domain operator knows what they are doing, knows >> what their network consists of and how email is routed within their >> network. It further states that the -all publisher has committed to >> staying abreast of what happens in their environment in order to >> assure their IP space is properly routing email. It instills >> confidence. >> >> ~all is just plain lazy, and is akin to saying that you don't have >> confidence in your ability to own and control your own network; and >> you want others to spend some level of time/money (in the form of CPU >> cycles) analyzing email emitted from your network to determine it's >> suitability for deliverability. > > Or, it acknowledges the fact that the people you send mail to may forward > that > mail, and trying to control that is silly. Yeah, but a fail doesn't magically turn into a pass if you turn -all into ~all. I don't think either is a universal use case, but I see good reasons for both ways and it depends on what type of company and mail sender you are. For me, I think -all makes a lot of sense for marketing senders and folks really worried about phishing/spoofing. And I see lots of -all mail get forwarded just fine, thanks to, for example, the fine folks at Google who write the return path when forwarding. :) Old school forwarding is still a pain even if you pull SPF out of the equation, no? Cheers, Al -- al iverson // wombatmail // miami http://www.aliverson.com http://www.spamresource.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations (was: Re: Earthlink trouble with our PTR)
On Thu, Dec 14, 2017 at 11:09 AM Jim Popovitchwrote: > On Thu, Dec 14, 2017 at 11:33 AM, Vladimir Dubrovin via mailop > wrote: > > > > In fact, you should not use "-all" for your mail domain if you care > > about deliverability. > > FALSE! (Also, you should not randomly add CC recipients to the same > mailinglist that you are responding to) > > Aside from a few HUGE providers, those with very large and disparate > networks/offices/topology > > -all means that the domain operator knows what they are doing, knows > what their network consists of and how email is routed within their > network. It further states that the -all publisher has committed to > staying abreast of what happens in their environment in order to > assure their IP space is properly routing email. It instills > confidence. > > ~all is just plain lazy, and is akin to saying that you don't have > confidence in your ability to own and control your own network; and > you want others to spend some level of time/money (in the form of CPU > cycles) analyzing email emitted from your network to determine it's > suitability for deliverability. > Or, it acknowledges the fact that the people you send mail to may forward that mail, and trying to control that is silly. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF recommendations (was: Re: Earthlink trouble with our PTR)
On Thu, Dec 14, 2017 at 11:33 AM, Vladimir Dubrovin via mailopwrote: > > In fact, you should not use "-all" for your mail domain if you care > about deliverability. FALSE! (Also, you should not randomly add CC recipients to the same mailinglist that you are responding to) Aside from a few HUGE providers, those with very large and disparate networks/offices/topology -all means that the domain operator knows what they are doing, knows what their network consists of and how email is routed within their network. It further states that the -all publisher has committed to staying abreast of what happens in their environment in order to assure their IP space is properly routing email. It instills confidence. ~all is just plain lazy, and is akin to saying that you don't have confidence in your ability to own and control your own network; and you want others to spend some level of time/money (in the form of CPU cycles) analyzing email emitted from your network to determine it's suitability for deliverability. -Jim P. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop