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 pr

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

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

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 (despit

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

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 i

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 wondr

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 f

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

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

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 mai

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:

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 forw

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

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

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 reputa

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 domain

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 sur

[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 st

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