Re: [mailop] ARC lesson please

2017-05-22 Thread Steve Atkins 

> On May 22, 2017, at 10:01 PM, Hal Murray  wrote:
> 
>> ARC is the very-near-future solution to much of this. Get your vendors on it.
>> http://arc-spec.org
> 
> I'm missing something.  What keeps a bad guy from setting up shop and 
> claiming to be forwarding mail and claiming that SPF was valid on the crap he 
> is sending?
> 
> It seems to me that a critical step for doing things right is that the user 
> has to get involved and agree to receive forwarded mail, including all the 
> spam that gets past the spam filters at the forwarder.  I think that would 
> work for geeks but it's probably too complicated for the typical user.  Do 
> you have to be geeky enough to set up forwarding?
> 
> The same holds for mailing lists but you don't have to be a geek to get added 
> to one.  I think it would be great if the mail environment asked me if I 
> wanted to get added to a list before it started accepting mail for that list. 
> I wonder if a typical user could handle that.
> 
> I don't know what happens to transactional mail.
> 
> Is this only going to work for big players who generate or receive enough 
> traffic so the receiver can develop a useful reputation?

Go read https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-01 for an initial
discussion of most of the important pieces of that.

Cheers,
  Steve


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

[mailop] ARC lesson please

2017-05-22 Thread Hal Murray 
> ARC is the very-near-future solution to much of this. Get your vendors on it.
> http://arc-spec.org

I'm missing something.  What keeps a bad guy from setting up shop and 
claiming to be forwarding mail and claiming that SPF was valid on the crap he 
is sending?

It seems to me that a critical step for doing things right is that the user 
has to get involved and agree to receive forwarded mail, including all the 
spam that gets past the spam filters at the forwarder.  I think that would 
work for geeks but it's probably too complicated for the typical user.  Do 
you have to be geeky enough to set up forwarding?

The same holds for mailing lists but you don't have to be a geek to get added 
to one.  I think it would be great if the mail environment asked me if I 
wanted to get added to a list before it started accepting mail for that list. 
 I wonder if a typical user could handle that.

I don't know what happens to transactional mail.

Is this only going to work for big players who generate or receive enough 
traffic so the receiver can develop a useful reputation?


-- 
These are my opinions.  I hate spam.




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

Re: [mailop] So, about this iOS10 unsubscribe feature...

2017-05-22 Thread Dave Warren 
On Mon, May 22, 2017, at 18:59, frnk...@iname.com wrote:
> Just starting last week we started seeing our outbound queues fill up
> with undeliverable client messages generated because of this one-click
> unsubscribe feature.  Since this Apple feature has been in place for
> over six months, I’m surprised we haven’t seen this until now.
Is the problem iOS 10 doing something wrong, or is it just some
bulk mail sender has started sending mail with invalid
Unsubscribe information and users that try to unsubscribe are
generating queue noise?
I don't use the feature much myself on a day to day basis, but I did
monkey with it a bit when it first came out and it seems to work as
described.

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

Re: [mailop] So, about this iOS10 unsubscribe feature...

2017-05-22 Thread frnkblk 
Just starting last week we started seeing our outbound queues fill up with 
undeliverable client messages generated because of this one-click unsubscribe 
feature.  Since this Apple feature has been in place for over six months, I’m 
surprised we haven’t seen this until now.

 

Here are the domains that are currently in our server queues:

  e.highwayhealth.org

  e.everydown.org

  e.thrivehealth.org

  e.pro-associates.org

  e.educationforourfuture.org

  e.booktemplate.org

  e.amicon.org

  e.gatherit.org

Note that none of these have an MX record.

 

How are others dealing with this? Just purging their outbound queues?

 

Frank

 

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Josh Nason
Sent: Thursday, September 15, 2016 3:27 PM
To: mailop 
Subject: [mailop] So, about this iOS10 unsubscribe feature...

 

Hi all -- I'm sure you've heard about the new iOS10 feature that highlights an 
unsubscribe at the top of bulk emails. I assumed it was only going to be active 
if a sender had list unsubscribe turned on, but was mistaken. 

 

However, the prompt I get saying 'Mail will send a message from (my email) to 
unsubscribe from this mailing list.'

 

Anyone know where that message is going to be sent to? I assume the reply 
address, but am unclear and can't seem to find documentation on it.


 

-- 

     
   
  

Josh Nason / Email Reputation Manager  
     
 +1 603-289-1244 | @JoshNason 
 

Email is hot! This is why 

  it's the original form of social media.

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

Re: [mailop] SPF record

2017-05-22 Thread Brandon Long via mailop 
Well, the obvious usage of ARC where DKIM is not a solution is for any
modifying hop, such as a mailing list.   The mailing list can DKIM sign the
modified message, but it then lacks alignment and also takes on "ownership"
of the message (see discussion about forwarding in general taking the
reputation hit for what is forwarded).

ARC does require knowing when to use the arc information and when not to,
so trust.  Trust can be learned or hard coded.

ARC also means I don't need to trust an intermediary as long as they don't
break the chain (or modify the message, which ARC will also tell you)

So:

Sender -> Trusted forwarder -> Untrusted forwarder -> destination

Because it's an untrusted forwarder, I can't trust their received headers.

Even with a trusted forwarder, that doesn't mean you know the auth results,
the forwarder may forward regardless of auth status, and that auth status
is information lost.  AuthRes was designed for internal passing of auth
information, ARC extends that to external passing.

Brandon



On Mon, May 22, 2017 at 4:30 PM, Vladimir Dubrovin via mailop <
mailop@mailop.org> wrote:

>
> DKIM is solution.
>
> ARC is not solution and never will. Actually, I see no any reason for ARC,
> really. If you trust sender, you can trust his Received: without any
> cryptography. If you do not trust sender, you can not trust ARC regardless
> of cryptography. ARC doesn't work without trusts.  The only good thing in
> ARC comparing to Received: is domain name instead of hostname. Or do I miss
> something?
>
>
> 23.05.2017 0:54, Steve Atkins пишет:
>
> On May 22, 2017, at 2:42 PM, W Kern  
>  wrote:
>
>
> We quarantine inbound SPF failures. Customers complain but we point that out. 
> So those are not the issue.
>
> I am talking about the scenario where a third party sender WITH an -all SPF 
> record sends to my customer and then MY customer forwards it elsewhere 
> (gmail, hotmail).
>
> From our server's perspective it is a legitimate acceptance and no SPF 
> failure occurred. Of course we are going to accept it.
>
> But unless we REWRITE it then when we forward back out its an SPF failure at 
> the forwarding destination, and where we have tried rewriting we have seen 
> pushback and technical issues.
>
> I suppose we could write something unique and refuse to forward such emails, 
> but the standard software doesn't accommodate that as of yet.
>
> ARC is the very-near-future solution to much of this. Get your vendors on it.
> http://arc-spec.org
>
> Cheers,
>   Steve
> ___
> mailop mailing 
> listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
> Vladimir Dubrovin
> [image: @Mail.Ru]
>
> ___
> 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 record

2017-05-22 Thread Vladimir Dubrovin via mailop 

DKIM is solution.

ARC is not solution and never will. Actually, I see no any reason for
ARC, really. If you trust sender, you can trust his Received: without
any cryptography. If you do not trust sender, you can not trust ARC
regardless of cryptography. ARC doesn't work without trusts.  The only
good thing in ARC comparing to Received: is domain name instead of
hostname. Or do I miss something?


23.05.2017 0:54, Steve Atkins пишет:
>> On May 22, 2017, at 2:42 PM, W Kern  wrote:
>>
>>
>> We quarantine inbound SPF failures. Customers complain but we point that 
>> out. So those are not the issue. 
>>
>> I am talking about the scenario where a third party sender WITH an -all SPF 
>> record sends to my customer and then MY customer forwards it elsewhere 
>> (gmail, hotmail). 
>>
>> From our server's perspective it is a legitimate acceptance and no SPF 
>> failure occurred. Of course we are going to accept it. 
>>
>> But unless we REWRITE it then when we forward back out its an SPF failure at 
>> the forwarding destination, and where we have tried rewriting we have seen 
>> pushback and technical issues. 
>>
>> I suppose we could write something unique and refuse to forward such emails, 
>> but the standard software doesn't accommodate that as of yet. 
> ARC is the very-near-future solution to much of this. Get your vendors on it.
>
> http://arc-spec.org
>
> Cheers,
>   Steve
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


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

Re: [mailop] SPF record

2017-05-22 Thread W Kern 



On 5/22/2017 3:46 PM, valdis.kletni...@vt.edu wrote:

On Mon, 22 May 2017 14:42:20 -0700, W Kern said:


I am talking about the scenario where a third party sender WITH an -all
SPF record sends to my customer and then MY customer forwards it
elsewhere (gmail, hotmail).

So you accept spam if it has a valid SPF?



We try not to. The obvious stuff gets caught.

But as as I mentioned, sometimes edgy stuff slips through, especially if 
the customer has lowered their tolerance levels.


And email does get credit for a 'correct' SPF resolution and good 
sending server reputation, so well written spam from a compromised email 
account on a legit server can pass. And that is only one of many scenarios.


I have experience with both home brew SA systems and commercial systems 
(McAfee, Postini, Fuse etc from back in the day, etc).  All of them 
leak(ed) certain types of spam.


Evidently your anti-spam system can perfectly identify each individual's 
customer's definition of spam, even from known good systems.


I'd be curious as to what you are using and maybe it would solve this 
particular problem for us.


-bill

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

Re: [mailop] SPF record

2017-05-22 Thread Brandon Long via mailop 
Forwarding is complicated, but it's not going away.

If you take "ownership" of forwarded mail by changing the MAIL FROM, then
you are more likely to be charged for the spam you forward.  If you don't
take ownership, then spf will fail, and a good spam filter will be more
likely to notice it's forwarded mail and not blame your IPs (as much).

It is true, that with ARC, you can "pass" an SPF pass forward to the next
hop, voiding the auth issue.  And, hopefully, the spam filter can use the
arc hop information to know the message was forwarded as well, and do a
better job of attributing the spam.

Overall, I'm kind of surprised there is still this level of debate over the
utility of the "policy" parts of SPF, especially among folks who should
know email[1].  It seems pretty clear that, in general, the policy parts of
SPF are a failure, and hence the move to using DMARC for policy which can
rely on either SPF or DKIM for auth, thereby reducing the cases where auth
failure leads to poor policy enforcement.  Even DMARC is not 100%
effective, there are plenty of cases where it fails (RFC 7960), and clearly
there is some difference between DMARC (5322.From) and SPF (5321.From).

Brandon

[1] the occasional argument with those who just discovered SPF and don't
understand the the history of email auth and policy is more expected.

On Mon, May 22, 2017 at 3:19 PM, Jim Popovitch  wrote:

> On Mon, May 22, 2017 at 6:05 PM, Michael Wise via mailop
>  wrote:
> >
> > At least a Mailing List is in a position to rewrite the headers so that
> SPF works when it sends the traffic out.
> >
>
> Yep, but only those managed by ppl who know how to keep things
> updated, patched, etc.   Lots of bad managed mailing lists out
> there/here..
>
> -Jim P.
>
> ___
> 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 record

2017-05-22 Thread valdis . kletnieks 
On Mon, 22 May 2017 14:42:20 -0700, W Kern said:

> I am talking about the scenario where a third party sender WITH an -all 
> SPF record sends to my customer and then MY customer forwards it 
> elsewhere (gmail, hotmail).

So you accept spam if it has a valid SPF?


pgp1vLecxuz_9.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SPF record

2017-05-22 Thread Jim Popovitch 
On Mon, May 22, 2017 at 6:05 PM, Michael Wise via mailop
 wrote:
>
> At least a Mailing List is in a position to rewrite the headers so that SPF 
> works when it sends the traffic out.
>

Yep, but only those managed by ppl who know how to keep things
updated, patched, etc.   Lots of bad managed mailing lists out
there/here..

-Jim P.

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

Re: [mailop] SPF record

2017-05-22 Thread Michael Wise via mailop 


At least a Mailing List is in a position to rewrite the headers so that SPF 
works when it sends the traffic out. 


Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool ?



-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Steve Atkins
Sent: Monday, May 22, 2017 2:52 PM
To: mailop@mailop.org
Subject: Re: [mailop] SPF record





> On May 22, 2017, at 12:57 PM, Michael Wise via mailop 
> > wrote:

>

>

> Forwarding ... is GROSSLY insecure and causes far more problems than it 
> solves.

> Just grabbing the traffic from the original INBOX with IMAP or POP3 is a much 
> more secure solution.



/me gestures vaguely at this wondrous email forwarding based system you're 
currently discussing this on.



Cheers,

  Steve





___

mailop mailing list

mailop@mailop.org

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailop=02%7C01%7Cmichael.wise%40microsoft.com%7C5a54713f01754e26e67a08d4a15de780%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636310872064099409=6CMIKjEYcNfp2Bn6at4nVH5JbFqcgWgA%2Bltv4IhyIzw%3D=0
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SPF record

2017-05-22 Thread W Kern 



On 5/22/2017 2:54 PM, Steve Atkins wrote:

ARC is the very-near-future solution to much of this. Get your vendors on it.

http://arc-spec.org


Very interesting. Will research more on it.

Thanks.

-bill

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

Re: [mailop] SPF record

2017-05-22 Thread Steve Atkins 

> On May 22, 2017, at 2:42 PM, W Kern  wrote:
> 
> 
> We quarantine inbound SPF failures. Customers complain but we point that out. 
> So those are not the issue. 
> 
> I am talking about the scenario where a third party sender WITH an -all SPF 
> record sends to my customer and then MY customer forwards it elsewhere 
> (gmail, hotmail). 
> 
> From our server's perspective it is a legitimate acceptance and no SPF 
> failure occurred. Of course we are going to accept it. 
> 
> But unless we REWRITE it then when we forward back out its an SPF failure at 
> the forwarding destination, and where we have tried rewriting we have seen 
> pushback and technical issues. 
> 
> I suppose we could write something unique and refuse to forward such emails, 
> but the standard software doesn't accommodate that as of yet. 

ARC is the very-near-future solution to much of this. Get your vendors on it.

http://arc-spec.org

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

Re: [mailop] SPF record

2017-05-22 Thread Steve Atkins 

> On May 22, 2017, at 12:57 PM, Michael Wise via mailop  
> wrote:
> 
> 
> Forwarding ... is GROSSLY insecure and causes far more problems than it 
> solves.
> Just grabbing the traffic from the original INBOX with IMAP or POP3 is a much 
> more secure solution.

/me gestures vaguely at this wondrous email forwarding based system you're 
currently discussing this on.

Cheers,
  Steve


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

Re: [mailop] SPF record

2017-05-22 Thread W Kern 





On 5/22/2017 1:31 PM, valdis.kletni...@vt.edu wrote:

On Mon, 22 May 2017 13:21:08 -0700, W Kern said:


Then it's your fault for *accepting* the spam/virus that ended up getting
forwarded.



We quarantine inbound SPF failures. Customers complain but we point that 
out. So those are not the issue.


I am talking about the scenario where a third party sender WITH an -all 
SPF record sends to my customer and then MY customer forwards it 
elsewhere (gmail, hotmail).


From our server's perspective it is a legitimate acceptance and no SPF 
failure occurred. Of course we are going to accept it.


But unless we REWRITE it then when we forward back out its an SPF 
failure at the forwarding destination, and where we have tried rewriting 
we have seen pushback and technical issues.


I suppose we could write something unique and refuse to forward such 
emails, but the standard software doesn't accommodate that as of yet.


As far as us forwarding spam/virus, if you know a perfect anti-virus 
and  spam filter that exactly matches the 'customers' expectation of 
what spam is versus their email provider, I am all ears.


I have seen situations where customers have loosened up their quarantine 
rules and then they expect gmail,hotmail to catch the spam (and blame 
us). We are trying to crack down on that but again the  systems aren't 
yet in place.
Our solution has been to try to force them to pop/imap off their email 
accounts rather than forward in general. As Michael pointed out that is 
much more reliable anyway and helps keep our systems off somebodies 
spammer list.



The rest of your commentary isn't related to the specific point being
discussed - SPF in the context of forwarding, such as this:


or when their customers Website is delivering transactional
email but the customer didn't alter their SPF record to include the
webserver.



Its similar to forwarding and the problem of people not understanding 
correct SPF records, so therefore some have an assertion on this thread 
that we should all ignore them, so that things like 'old school' 
forwarding still work.


-bill


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

Re: [mailop] SPF record

2017-05-22 Thread valdis . kletnieks 
On Mon, 22 May 2017 13:21:08 -0700, W Kern said:

> On 5/22/2017 11:22 AM, valdis.kletni...@vt.edu wrote:
> > not an SPF problem.
> > Forwarding has worked just fine for 30 or so years, if not longer. The
> > "problem" only happens if you insist on attaching SPF to it.

> Except when it is a shared server and that server forwards enough
> spam/virii (despite anti-spam efforts) to a common email host (gmail,
> outlook, etc) to get EVERYONE on that server blocked.

Then it's your fault for *accepting* the spam/virus that ended up getting
forwarded.

> failure or when their customers Website is delivering transactional
> email but the customer didn't alter their SPF record to include the
> webserver.

That isn't even related to the point under discussion - SPF and forwarding.


pgpGokSVJjYbq.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SPF record

2017-05-22 Thread W Kern 



On 5/22/2017 11:22 AM, valdis.kletni...@vt.edu wrote:

not an SPF problem.
Forwarding has worked just fine for 30 or so years, if not longer. The
"problem" only happens if you insist on attaching SPF to it.




Except when it is a shared server and that server forwards enough 
spam/virii (despite anti-spam efforts) to a common email host (gmail, 
outlook, etc) to get EVERYONE on that server blocked.


Let alone that some email providers not only blame you for forwarding 
Spam to their customers, they penalize your server for the SPF/Forward 
failure or when their customers Website is delivering transactional 
email but the customer didn't alter their SPF record to include the 
webserver.



William Kern
PixelGate Networks

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

Re: [mailop] SPF record

2017-05-22 Thread Michael Wise via mailop 

Forwarding ... is GROSSLY insecure and causes far more problems than it solves.
Just grabbing the traffic from the original INBOX with IMAP or POP3 is a much 
more secure solution.

Aloha,
Michael.
-- 
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting Tool ?

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of 
valdis.kletni...@vt.edu
Sent: Monday, May 22, 2017 11:23 AM
To: Michael Peddemors 
Cc: mailop@mailop.org
Subject: Re: [mailop] SPF record

On Mon, 22 May 2017 10:59:21 -0700, Michael Peddemors said:
> Some have pointed out on the list the problem with 'forwarding', 
> however that is a forwarding problem, and not an SPF problem.

Forwarding has worked just fine for 30 or so years, if not longer. The 
"problem" only happens if you insist on attaching SPF to it.

If a car manufacturer had been making perfectly usable vehicles with perfectly 
functional windshield wipers for decades, and you discovered that the 
windshield wipers tend to malfunction when you attach other devices to the 
windshield, is that the fault of the windshield wipers, or the other devices?

> Since every email client out there can check multiple mailboxes, if 
> you want to properly take advantage of SPF as a recipient, don't do 
> email forwarding ;)

No, what you meant was:

If you want to properly take advantage of SPF as a recipient, ensure that no 
users at other sites set a forward to your mail system if their sysadmin has 
set an SPF record that will cause problems.

Which is, in general, obviously not achievable.

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

Re: [mailop] SPF record

2017-05-22 Thread valdis . kletnieks 
On Mon, 22 May 2017 10:59:21 -0700, Michael Peddemors said:
> Some have pointed out on the list the problem with 'forwarding', however
> that is a forwarding problem, and not an SPF problem.

Forwarding has worked just fine for 30 or so years, if not longer. The
"problem" only happens if you insist on attaching SPF to it.

If a car manufacturer had been making perfectly usable vehicles with perfectly
functional windshield wipers for decades, and you discovered that the windshield
wipers tend to malfunction when you attach other devices to the windshield,
is that the fault of the windshield wipers, or the other devices?

> Since every email client out there can check multiple mailboxes, if you
> want to properly take advantage of SPF as a recipient, don't do email
> forwarding ;)

No, what you meant was:

If you want to properly take advantage of SPF as a recipient, ensure that
no users at other sites set a forward to your mail system if their sysadmin
has set an SPF record that will cause problems.

Which is, in general, obviously not achievable.


pgplKjkIt9ptZ.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SPF record

2017-05-22 Thread Michael Peddemors 

On 17-05-20 12:24 PM, Steve Atkins wrote:



On May 19, 2017, at 6:58 PM, Bryan Blackwell  wrote:

Hi folks,

Please pardon the noob question, just want to make sure this is what a proper 
SPF record should look like:

example.org.IN  TXT "v=spf1 mx ~all"


It's fine. I'd marginally prefer one that listed the source IP addresses 
explicitly ...

skiblack.com. IN TXT "v=spf1 ip4:70.175.229.213 ~all"

... but that might require a little more maintenance, depending on how your MX 
and smarthosts are set up.

"~all" is the smart policy to use; ignore those who tell you to use "-all" or 
"?all".




Sorry Steve, but IMHO have to disagree.. if you ARE going to use SPF, 
you should use -all..


Otherwise you might as well not use SPF.. and save the DNS queries..

Some have pointed out on the list the problem with 'forwarding', however 
that is a forwarding problem, and not an SPF problem.


Since every email client out there can check multiple mailboxes, if you 
want to properly take advantage of SPF as a recipient, don't do email 
forwarding ;)


I like sending this link,

https://emailcopilot.com/blog/how-should-i-end-my-spf-record-all/

It shows that only 22% use -all, which IMHO opinion means not a lot of 
faith in SPF records, but they put it in because it is recommended..


(Two year old stats though, btw)

If you are a bank, or any form of a phishing target, using -all is the 
obvious choice.. yes, certain forwarding mechanisms will then fail, but 
really it should, IF you want the benefits of SPF.. (if it was 
forwarded, you are at risk of it being altered any ways)


Using +all is worse than no SPF record at all..

Will have to start running some stats of our own on this, but we aren't 
'great' believers in it (SPF).  However, if someone does have a '-all', 
and they are a likely or proven phishing target, we do use that 
information in our 'Known Sender Forgery' tools...


More efficient.. but yes, it will reject email forwarded..

We use a -all on some of our domains, and we do see 'bounces' on 
occasion, but in those cases, even though they may be critical emails 
that the sender should receive, the small amount of blow back is better 
than the alternative.


We are also a proponent of 'stop remote forwarding', and some of our 
ISP's are moving to this as a policy even.  (Reduces support AND 
backscatter and is good for business)


It would be interesting to see use cases for remote email forwarding 
that remain in today's world.. and of course, there are standards for 
rewriting sender domain when forwarding as well.


And as always, remember SPF is 'not' designed to be a spam protection 
tool to be clear.. and most of the professional spammers have better SPF 
records that legitimate companies ;) (Same with DKIM/DMARC)


But, as mentioned previously.. More important issues to address than 
SPF, that will make the world a better/safer place.






--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic

A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

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