Mailing lists, subscriptions, UPS notifications, and probably others would be examples of legit emails where the from address can be your address if using ~all would cause a false positive soft fail.
-----Original Message----- From: "Darin Cox" <[email protected]> Sent: Wednesday, April 1, 2015 12:10pm To: [email protected] Subject: [MBF] Re: SPF Records Soft fail can still be useful to prevent forged spam sent to your users where the from address is also the user's address. Darin. -----Original Message----- From: John Tolmachoff Sent: Wednesday, April 01, 2015 11:50 AM To: [email protected] Subject: [MBF] Re: SPF Records In reality, if you are not using a "-all" SPF record, then might as well have no SPF record at all. From a receiving point, the only time you can reliably take action (or weight) is on an absolute record which is "-all" anything else equals "maybe" in which case is meaningless. John T eServices For You -----Original Message----- From: "Darin Cox" <[email protected]> Sent: Wednesday, April 1, 2015 5:26am To: [email protected] Subject: [MBF] Re: SPF Records SPF RecordsDave, that’s the problem. If they send through another server, they violate the SPF policy you have set up that says mail for the domain can only come from your server. So in that case Yahoo would see the SPF failure and block it. You either need to loosen your SPF policy to soft fail, or make sure your users always send outbound through your server(s). Darin. From: Dave Beckstrom Sent: Wednesday, April 01, 2015 7:25 AM To: [email protected] Subject: [MBF] Re: SPF Records Hi Andy, My users can only send email through our server if they smtp auth. Been that way since day one and never been an issue with anyone. If they send email through another ISP's email server they use replyto to direct their returns back to our email server. -------------------------------------------------------------------------------- From: [email protected] [mailto:[email protected]] On Behalf Of Andy Schmidt Sent: Tuesday, March 31, 2015 9:31 PM To: [email protected] Subject: [MBF] Re: SPF Records Hi Dave, We absolutely block on “-all” before we check anything else. And almost daily I encounter some third party mail server that rejects a “registration” email or a mailing list email form one of our clients, because the recipient is forwarding email between two email services. So there are countless servers like ours that are standards compliant. I have to assume that you’ve been extraordinary lucky with your circumstances until today. It’s possible that until now your end users haven’t been connecting through hotel room WiFi networks, or haven’t used greeting card sites etc etc. – or they always set up SMTP AUTH to connect to your MX while travelling. The whole IDEA behind SPF is that the domain owner can CHOOSE to add an SPF records, but if one exists, that it is the ultimate authority on how email should be handled. If you wanted your emails to be permitted from ANY server, then you have the option to forego an SPF record, or use the proper rule of: v=spf1 mx ~all <Flame on>Why on earth would anyone set up a rule that explicitly states that all email absolutely must come from their own MX and NEVER-EVER-EVER from another mail server, if they really don’t want the recipient to respect those very explicit instructions?</Flame Off> Best Regards, Andy From: [email protected] [mailto:[email protected]] On Behalf Of Dave Beckstrom Sent: Tuesday, March 31, 2015 6:54 PM To: [email protected] Subject: [MBF] SPF Records I received an email from a customer because an email he sent to someone in Canada was rejected due to SPF checking. Our DNS server automatically sets an SPF record for each domain with the value v=spf1 mx -all Been that way since SPF first became available and I've never had a problem. I'm curious if anyone here rejects (bounces) email strictly off of an SPF check? I think that's ridiculous. Moreover, I'm pretty certain our SPF record is correct. I'm thinking the yahoo's in Canada are the ones who don't know what they are doing. Thoughts? ############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]>. To unsubscribe, E-mail to: <[email protected]> To switch to the DIGEST mode, E-mail to <[email protected]> To switch to the INDEX mode, E-mail to <[email protected]> Send administrative queries to <[email protected]> ############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]>. To unsubscribe, E-mail to: <[email protected]> To switch to the DIGEST mode, E-mail to <[email protected]> To switch to the INDEX mode, E-mail to <[email protected]> Send administrative queries to <[email protected]> ############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]>. To unsubscribe, E-mail to: <[email protected]> To switch to the DIGEST mode, E-mail to <[email protected]> To switch to the INDEX mode, E-mail to <[email protected]> Send administrative queries to <[email protected]>
