Re: [mailop] SPF recommendations

2017-12-17 Thread Noel Butler 
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

2017-12-17 Thread Noel Butler 
On 15/12/2017 14:28, John Levine wrote:

> In article <6582089ce2ad3fb3fd074ada73672...@ausics.net>,
> Noel Butler   wrote: 
> 
>> 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

2017-12-15 Thread Michael Peddemors 

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

-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)

2017-12-15 Thread Al Iverson 
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 Long  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.
>
> -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

2017-12-15 Thread Philip Paeps 

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

2017-12-14 Thread Brandon Long via mailop 
On Thu, Dec 14, 2017 at 7:16 PM Grant Taylor via mailop 
wrote:

> 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

2017-12-14 Thread Bill Cole 

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

2017-12-14 Thread Brandon Long via mailop 
On Thu, Dec 14, 2017 at 8:05 PM Noel Butler  wrote:

> 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

2017-12-14 Thread John Levine 
In article <6582089ce2ad3fb3fd074ada73672...@ausics.net>,
Noel Butler   wrote:
>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

2017-12-14 Thread Noel Butler 
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)

2017-12-14 Thread Jim Popovitch 
On Thu, Dec 14, 2017 at 8:07 PM, Bill Cole
 wrote:
> 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

2017-12-14 Thread Grant Taylor via mailop 

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

2017-12-14 Thread Grant Taylor via mailop 

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

2017-12-14 Thread Steve Atkins 

> On Dec 14, 2017, at 4:06 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.
>  

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

2017-12-14 Thread Laura Atkins 

> 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

2017-12-14 Thread Evert Mouw via mailop 

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)

2017-12-14 Thread Bill Cole 

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

2017-12-14 Thread steve 
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

2017-12-14 Thread Noel Butler 
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

2017-12-14 Thread Grant Taylor via mailop 

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)

2017-12-14 Thread Brandon Long via mailop 
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
>
___
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)

2017-12-14 Thread Al Iverson 
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

Re: [mailop] SPF recommendations (was: Re: Earthlink trouble with our PTR)

2017-12-14 Thread Brandon Long via mailop 
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.

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)

2017-12-14 Thread Jim Popovitch 
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.

-Jim P.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop