We have cross-referenced the advice Microsoft support gave customers experiencing the problem, and the consensus among Microsoft support engineers seems to be that while SPF should be sufficient to avoid the problem in the first place, it is not sufficient to undo the damage once the red warning starts popping up. Their recommendation is to use DKIM signatures to eventually remove the warning. It seems to be a reputation- or blacklist-based system rather than a stateless inspection of SPF, DKIM, DMARC and so on.

We have been unable to trigger the warning on our Exchange 365 accounts (both our own and those loaned by impacted customers), so we cannot say whether this would actually solve the problem or not, but it seems worth a try. We have implemented DKIM and our support folk can provide a build to anyone interested in giving DKIM a shot.

My suspicion is that this all started as a bug causing SPF not to prevent the reputation/blacklisting event; that the bug was corrected but that this did not retroactively undo all the incorrect blacklisting; and that DKIM is probably the only way out.

Hey, at least they're not trying to charge us $0.01 per message to make it to the inbox without a spam warning this time :-)

  Eric

-----Original Message-----
From: LISTSERV List Owners' Forum [mailto:[log in to unmask]] On Behalf Of F J Kelley
Sent: Thursday, December 08, 2016 15:52
To: [log in to unmask]
Subject: Re: Fw: Troubleshooting the red (Suspicious) Safety Tip for fraud detection checks

We have not resolved it.  Our SPF for mail includes the IP for our listserv box.  So if there is a get-host search on the (rfc821) MAIL FROM (as the docs suggest) it might be ok.  Or not.  This has not been consistent.  My understanding is that it is consistent at some sites.  

________________________________________
From: Charles Schmiesing <[log in to unmask]>
Sent: Thursday, December 8, 2016 3:30 PM
To: [log in to unmask]; F J Kelley
Cc: Charles Schmiesing
Subject: Re: Fw: Troubleshooting the red (Suspicious) Safety Tip for fraud detection checks

Thank you for sharing the link to the Microsoft site, but it left me wondering what you had to do to resolved the issue. We now have users from two domains that have reported this message (or something very similar). I could alter the SPF record of one of the domains, but the other domain is completely out of my control. I was hoping I could alter a setting within the lists themselves that would prevent this from occurring. Thanks for any insight you can share, Charles

############################

To unsubscribe from the LSTOWN-L list:
write to: mailto:[log in to unmask]
or click the following link:
http://peach.ease.lsoft.com/scripts/wa-PEACH.exe?SUBED1=LSTOWN-L&A=1

############################

To unsubscribe from the LSTOWN-L list:
write to: mailto:[log in to unmask]
or click the following link:
http://peach.ease.lsoft.com/scripts/wa-PEACH.exe?SUBED1=LSTOWN-L&A=1