IMHO Mailinglists should (and do) always use their own mailfrom domain at the SMTP envelope level and absolutely not that one from the list member (for example this message should come from MBFs server with MAILFROM mailbestfriend.com and not limitis.com). Only the header fields can be the original senders one but that doesn't matter for incoming SPF verification.
The main problem with SPF records we can see is when some customer (having already SPF-records but not remembering avout it) does publish a new website somewhere else. Or when he does start some unprofessional email marketing campaign, that not checks or knows about existing SPF records. From what I can see on our gateways the catch rate for incoming messages not corresponding the existing SPF records is ok but not that high to call it significant. (green area below) [cid:[email protected]] In other words: most spammers take care about SPF-compliant mailfrom domains. So when talking about soft- or hard-fails we talk about these small part of incoming messages. And – at this point - we have to clarify how Declude itself does handle hard- and soft-fails. From what I can see SPFFAIL does only catch fails for –all records. At least I can’t find anyone who has actually failed on ~all Looking at the other side (messages corresponding the existing SPF) we can see that around 11 years after being introduced something around 60% of all incoming SMTP traffic has valid SPF-Records. Valid doesn’t mean that it’s HAM, it simply means that the messages comes from somewhere the SPF-record allows. [cid:[email protected]] The green area shows messages with a final weight that classifies the message as HAM. So a valid SPF for a valid message. The red area shows messages being classified in the weighting system as spam even if the SPF looks valid. From my point of view SPF cannot be considered as a reliable standalone test - neither for FAIL nor PASS. However it is great for a combination with other HAM indicators. Greetings from Italy Markus -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von John Tolmachoff Gesendet: Mittwoch, 1. April 2015 23:56 An: [email protected] Betreff: [MBF] Re: SPF Records 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]<mailto:[email protected]>> Sent: Wednesday, April 1, 2015 12:10pm To: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> Sent: Wednesday, April 1, 2015 5:26am To: [email protected]<mailto:[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]<mailto:[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]> [mailto:[email protected]] On Behalf Of Andy Schmidt Sent: Tuesday, March 31, 2015 9:31 PM To: [email protected]<mailto:[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]> [mailto:[email protected]] On Behalf Of Dave Beckstrom Sent: Tuesday, March 31, 2015 6:54 PM To: [email protected]<mailto:[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]<mailto:[email protected]>>. To unsubscribe, E-mail to: <[email protected]<mailto:[email protected]>> To switch to the DIGEST mode, E-mail to <[email protected]<mailto:[email protected]>> To switch to the INDEX mode, E-mail to <[email protected]<mailto:[email protected]>> Send administrative queries to <[email protected]<mailto:[email protected]>> ############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]<mailto:[email protected]>>. To unsubscribe, E-mail to: <[email protected]<mailto:[email protected]>> To switch to the DIGEST mode, E-mail to <[email protected]<mailto:[email protected]>> To switch to the INDEX mode, E-mail to <[email protected]<mailto:[email protected]>> Send administrative queries to <[email protected]<mailto:[email protected]>> ############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]<mailto:[email protected]>>. To unsubscribe, E-mail to: <[email protected]<mailto:[email protected]>> To switch to the DIGEST mode, E-mail to <[email protected]<mailto:[email protected]>> To switch to the INDEX mode, E-mail to <[email protected]<mailto:[email protected]>> Send administrative queries to <[email protected]<mailto:[email protected]>>
