John , Nice to meet you :-)
Right. The only major mail system that pays attention to SPF is Hotmail, but there are enough small poorly run MTAs that use it that an SPF record which lists your outbounds and ~all (not -all) can be marginally useful to avoid bogus rejections of your mail.
For example : host -t TXT hotmail.com hotmail.com TXT "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" host -t TXT google.com : google.com TXT "v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all" host -t TXT amazon.com : amazon.com TXT "v=spf1 ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.193.0/24 ip4:72.21.196.0/22 ip4:72.21.208.0/24 ip4:72.21.205.0/24 ip4:72.21.209.0/24 ip4:194.154.193.200/28 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ~all" amazon.com TXT "spf2.0/pra ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.193.0/24 ip4:72.21.196.0/22 ip4:72.21.208.0/24 ip4:72.21.205.0/24 ip4:72.21.209.0/24 ip4:194.154.193.200/28 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ~all" host -t TXT ebay.de : ebay.de TXT "v=spf1 mx include:s._spf.ebay.com include:m._spf.ebay.com include:p._spf.ebay.com include:c._spf.ebay.com ~all" ebay.de TXT "spf2.0/pra mx include:s._sid.ebay.com include:m._sid.ebay.com include:p._sid.ebay.com include:c._sid.ebay.com ~all" host -t TXT 1und1.de : TXT "v=spf1 ip4:82.165.0.0/16 ip4:195.20.224.0/19 ip4:212.227.0.0/16 ip4:87.106.0.0/16 ip4:217.160.0.0/16 ip4:213.165.64.0/19 ip4:217.72.192.0/20 ip4:74.208.0.0/17 ip4:74.208.128.0/18 ip4:66.236.18.66 ip4:67.88.206.40 ip4:67.88.206.48 ~all" host -t TXT gmx.com : gmx.com TXT "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:74.208.122.0/26 -all" host -t TXT enterprisemail.de : enterprisemail.de TXT "v=spf1 a:mout.enterprisemail.de -all" etc
As everyone here should already know, the fundamental problem with SPF is that although it does an OK job of describing the mail sending patterns of dedicated bulk mail systems, it can't model the way that normal mail systems with human users work. But so deep is the faith of the SPF cult that they blame the world for not matching SPF rather than the other way around, believing that it prevent forgery, having redefined "forgery" as whatever it is that SPF prevents. As the operator of one of the world's more heavily forged domains (abuse.net) I can report that if you think it prevents forgery blowback, you are mistaken.
You do know that I love they way abuse.net flys: In mind of the following situation for instance a infection vector around millions of bots which are sending millions of forged mails within evil polymorphic files camouflage as your customers bills you will be glade to enforce the directive -all for a while . Sorry Im almost german : http://www.heise.de/security/meldung/1-1-warnt-Kunden-vor-gefaelschten-Rechn ungen-131420.html I know SPF is not the answer of all ....but sometimes it helps to secure a little bit of yours "critical customers infrastructure" and sometimes it helps to save your operative resources . I know there is a problem so far with forwarded emails but there is also a solution : The solution could be to rewrite the envelope from of all forwarded mail so that the given domain is a local domain with matching SPF records to the originating mail server (or no SPF records at all). You have to transform the original envelope from into a localpart and add some special local SRS domain to it. Find http://spf.pobox.com/srs.html <http://spf.pobox.com/srs.html> and http://www.libsrs2.org/ <http://www.libsrs2.org/> for a full description of SRS. In practice andre.engel@fhe3.com could receiving an email from misterX@google.com where andre.engel@fhe3.com could be forwarded to andre.engel@hotmail.de. Before forwarding the email to the hotmail server I could rewrite the envelope-from from misterX@google.com <mailto:misterX@google.com> to google.com=misterX@srs.enterprisemail.de srs.enterprisemail.de could be a valid domain for mails originating from our main mail clusters(enterprisemail) so possible SPF checks at hotmail would not bother. In case a bounce is generated at hotmail it could be delivered back to the SRS address, thus to our enterprisemail main mail cluster, where we would recognise the SRS scheme and "un-rewrite" it back to misterX@google.com and deliver the mail onward to the misterX@google.com mail system. But in the real world the rewriting isn't that simple as stated in the previous section. In fact you have to add some kind of checksum where the original mail address is mangled with a secret password, and a time stamp that makes the SRS address valid for some period of time. The mail address from above could look more like this: <SRS38=ldl23v=tz=google.com=MisterX@srs.enterprisemail.de> Every time a mail arrives that is an SRS address the password and timestamp could be checked, and faked or outdated recipients could be rejected. If you asked around drawbacks your right : SRS generates very long localparts. Mail servers should according to the RFC accept local parts with at least 63 characters. Most mail servers accept longer local parts, but unfortunately some won't. For those rare cases it is possible to configure a list of mail servers for which SRS won't be accomplished.
For rants about how badly the world and/or SPF stink, followups to Spam-L. For proposals about other anti-spam magic bullets, followups to ASRG.
Indeed Spam-L is the best place to talk about anti-spam . Indeed CII is the best place to talk about critical infrastructures ,indeed nanog is the best place to talk about networkstuff but we are mostly operators looking for a valuable , comfortable solution to protect and share information . I do not really know if this will be a little off topic . Cheers Andre -- Andre Engel Consulting Program Director, Email and Cyber Intelligence Services "..ehy my friend we seek the Grail!" FHE3 GmbH P: +49 721 869 5907 Scheffelstr. 17a M: +49 160 962 44476 76135 Karlsruhe andre.engel@fhe3.com http://www.fhe3.com/ Amtsgericht Mannheim, HRB 702495 Umsatzsteuer-Ident: DE254677931 Geschäftsführer: Peter Eisenhauer, Michael Feger, Dimitrij Hilt This message (including any attachments) is the property of FHE3 and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
-----Ursprüngliche Nachricht----- Von: John Levine [mailto:johnl@iecc.com] Gesendet: Freitag, 4. Dezember 2009 18:25 An: nanog@nanog.org Betreff: Re: SPF Configurations
If the customer insist on using their domain, then you would have to have the customer setup an SPF record within their domain that points to your email server IP blocks.
Right. The only major mail system that pays attention to SPF is Hotmail, but there are enough small poorly run MTAs that use it that an SPF record which lists your outbounds and ~all (not -all) can be marginally useful to avoid bogus rejections of your mail.
As everyone here should already know, the fundamental problem with SPF is that although it does an OK job of describing the mail sending patterns of dedicated bulk mail systems, it can't model the way that normal mail systems with human users work. But so deep is the faith of the SPF cult that they blame the world for not matching SPF rather than the other way around, believing that it prevent forgery, having redefined "forgery" as whatever it is that SPF prevents. As the operator of one of the world's more heavily forged domains (abuse.net) I can report that if you think it prevents forgery blowback, you are mistaken.
For rants about how badly the world and/or SPF stink, followups to Spam-L. For proposals about other anti-spam magic bullets, followups to ASRG.
R's, John