Re: [mailop] Blocking emails from domains without SPF records

2016-08-17 Thread Franck Martin via mailop
I think we were talking here about rejecting emails from a domain that do not have a SPF policy, which is a bit different from rejecting emails from a domain with a SPF policy "-all" and a fail result. For IPv6, bad stuff happens to non authenticated emails , as the archive on this list is chowing

Re: [mailop] Tracking Office 365 Delay notices?

2016-08-17 Thread Michael Wise via mailop
Indeed on the hoped-for button … It is possible in the other cases you refer to that the details to the left of @ were redacted in the Message Trace database. I normally try and do my debugging from the full headers, one way or another. There’s typically a way to get a test message delivered som

Re: [mailop] Tracking Office 365 Delay notices?

2016-08-17 Thread Aaron C. de Bruyn
On Wed, Aug 17, 2016 at 4:18 PM, Michael Wise wrote: > > > In this case, if I’m understanding it right, the traffic never got IN to > the Office365 environment, or if so, it might not have been associated with > the actual domain in question, but … the number of times I’ve used Message > Trace ca

Re: [mailop] Tracking Office 365 Delay notices?

2016-08-17 Thread Michael Wise via mailop
In this case, if I’m understanding it right, the traffic never got IN to the Office365 environment, or if so, it might not have been associated with the actual domain in question, but … the number of times I’ve used Message Trace can be counted on the fingers of one hand; I much prefer working

Re: [mailop] Tracking Office 365 Delay notices?

2016-08-17 Thread Aaron C. de Bruyn
On Wed, Aug 17, 2016 at 3:20 PM, Michael Wise wrote: > > No worries! J > > $DIETY knows, these things happen. > Yup. I'm not sure if you can comment on one part of my original question. In this situation the message obviously didn't make it from hotmail to Office 365 because of the expired doma

Re: [mailop] Tracking Office 365 Delay notices?

2016-08-17 Thread Michael Wise via mailop
No worries! ☺ $DIETY knows, these things happen. Aloha, Michael. -- Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been Processed." | Got the Junk Mail Reporting Tool ? From: Aaron C. de Bruyn [mailto:aa...@he

Re: [mailop] Tracking Office 365 Delay notices?

2016-08-17 Thread Michael Wise via mailop
Thanks, no worries. Replied in separate thread. Aloha, Michael. -- Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been Processed." | Got the Junk Mail Reporting Tool ? From: Aaron C. de Bruyn [mailto:aa...@hey

Re: [mailop] Tracking Office 365 Delay notices?

2016-08-17 Thread Aaron C. de Bruyn
Sorry Michael--false alarm. It looks like their domain expired. Through a tragedy of DNS caching we are still communicating with them as well as gmail.com and a few of their clients. Most other people can't. Sorry for the noise. -A On Wed, Aug 17, 2016 at 3:00 PM, Michael Wise wrote: > > >

Re: [mailop] Blocking emails from domains without SPF records

2016-08-17 Thread Michelle Sullivan
Mark Foster wrote: By 'configured to do so', does Michelle mean , well, obeying SPF? Yes I mean if the receiving server is both checking SPF and enforcing the policy configured ;-) (sorry I did a really bad job of being clear :) ) -- Michelle Sullivan http://www.mhix.org/ _

Re: [mailop] Tracking Office 365 Delay notices?

2016-08-17 Thread Aaron C. de Bruyn
I didn't want the poor user to get a bunch of spam. I'll send you the e-mail address privately in a moment. -A On Wed, Aug 17, 2016 at 3:00 PM, Michael Wise wrote: > > > There is no data to understand the nature of the problem. > > “recipi...@redacted.tld” might as well be “*” > > If t

Re: [mailop] Blocking emails from domains without SPF records

2016-08-17 Thread Michelle Sullivan
Steve Atkins wrote: Anyone who is sending mail over IPv6 has touched the network recently enough that they don't have that excuse, and it's not unreasonable to hold them to a slightly higher standard. 100% with you on that... but you know the way it is... the more people start using ipv6 the

Re: [mailop] Tracking Office 365 Delay notices?

2016-08-17 Thread Michael Wise via mailop
There is no data to understand the nature of the problem. “recipi...@redacted.tld” might as well be “*” If there is some real data you can share with me privately, I can see what I can find out. Or, the user can raise an issue with Office365 Customer Suppo

Re: [mailop] Blocking emails from domains without SPF records

2016-08-17 Thread Steve Atkins
> On Aug 17, 2016, at 2:38 PM, Michelle Sullivan wrote: > > Franck Martin wrote: >> I don't think you should block however: > > I'm not making any call either way - it's upto the admins involved. > Personally I have a valid SPF record my milter I wrote and build from scratch > the other week

[mailop] Tracking Office 365 Delay notices?

2016-08-17 Thread Aaron C. de Bruyn
I have a client using Office 365. They have 39 accounts, and they have all been in use for about 9 months. This morning one of the users says "no one has been able to e-mail me for several days". She was able to get the remote user to forward me details. Apparently the remote user is a Hotmail

Re: [mailop] Blocking emails from domains without SPF records

2016-08-17 Thread Mark Foster
Perhaps i've missed something, but isn't the whole point of SPF that if a _sender domain_ publishes a -all SPF record, that any platform using SPF is _supposed to reject email that doesn't pass_ ? Forwarded email is going to cause an SPF failure, unless the envelope-sender is rewritten (ala ma

Re: [mailop] Blocking emails from domains without SPF records

2016-08-17 Thread Michelle Sullivan
Franck Martin wrote: I don't think you should block however: I'm not making any call either way - it's upto the admins involved. Personally I have a valid SPF record my milter I wrote and build from scratch the other week uses libspf2 to make determinations on whether to accept or reject ema

Re: [mailop] Blocking emails from domains without SPF records

2016-08-17 Thread Franck Martin via mailop
I don't think you should block however: -IPv4 rate limit if the email is not authenticated (pass SPF or DKIM) -IPv6 reject email if it is not authenticated (pass SPF or DKIM) On Wed, Aug 17, 2016 at 12:23 PM, Michelle Sullivan wrote: > Brandon Long via mailop wrote: > >> If your mail server doe

Re: [mailop] Blocking emails from domains without SPF records

2016-08-17 Thread Michelle Sullivan
Brandon Long via mailop wrote: If your mail server doesn't expect to get forwarded mail, I can see using SPF like that. If you do expect to get forwarded mail, then it seems likely to cause more false positives than it's worth. I don't see that... Renaud just quoted https://www.iplocatio

Re: [mailop] Blocking emails from domains without SPF records

2016-08-17 Thread Brandon Long via mailop
If your mail server doesn't expect to get forwarded mail, I can see using SPF like that. If you do expect to get forwarded mail, then it seems likely to cause more false positives than it's worth. Brandon On Wed, Aug 17, 2016 at 6:41 AM, Al Iverson wrote: > It's kind of a moot point. Not many

Re: [mailop] Blocking emails from domains without SPF records

2016-08-17 Thread Al Iverson
It's kind of a moot point. Not many sites block mail lacking SPF today, but the longer you send mail from a domain without an SPF record, the more likely you are to eventually run into woe. So your point is valid, but only in a pretty limited way. I'd say add the SPF record. Gmail doesn't say that

Re: [mailop] Facebook/Twitter, advice/anyone here?

2016-08-17 Thread David Hofstee
You can fix the bounce handling problem for 97%+ of the bounces. You just have to put in a lot of effort to make it smarter (which LinkedIn should put in). Or they can buy a custom bouncehandler from us ;-). So I don't agree to the 'just keep emailing and ignore bounces' thing either. And I do

[mailop] Blocking emails from domains without SPF records

2016-08-17 Thread Renaud Allard via mailop
Hello, I am following another message which suggested that btinternet.com was blocking emails from domains without SPF records. This website suggests this is "common practice" in point 4: https://www.iplocation.net/email-delivery-problems Do you have this kind of policy or any evidence of this be