2009/12/4 Bret Clark <bclark@spectraaccess.com>

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. I would just tell your customer that if they insist of using their FROM domain, to help get past someone's spamming system the customer is going to have to add the a SPF record to their domain similar to the following:

[customer domain].com. IN TXT "v=spf1 a mx ip4:[your IP block]

Putting an SPF record in your DNS record will have no affect on spamming software. SPF is basically another form of reverse DNS at the mail level.

Bret

The problem we face is that some people we work with can't do that, they can't even grasp what an SPF record is and so as far as our own spam filtering goes, we have filtered their emails to us sent with the FROM address being an @mysurname.com domain which doesn't exist and as a result we have filtered out their mails so we have had to lower our SPF checking slightly which is so annoying :S -- Regards, James ;) Charles de Gaulle<http://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html> - "The better I get to know men, the more I find myself loving dogs."

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

On Fri, 4 Dec 2009, John Levine wrote:

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.

Nothing can "prevent" forgery. The forgers are going to keep making them. You can only try to make forgery easier to detect. But you need other parties' cooperation to detect the forgery and react in some way. Even if you did stop one forger, i.e. prison; there will be plenty of up and coming forgers to keep making forgeries. SPF, DKIM, PGP, S/MIME, DNSSEC, BCP38, sBGP, DRM, special paper and printing, wax seals, handwriting analysis, and so on; help cooperating parties detect particular types of forgery. Assuming the cooperating parties actually want to. Adding even more complexity probably isn't going to improve the degree of cooperation of uncooperative parties. In practice, any security control will also affect something some "legitimate" party wants to do sometime. And likewise, any security control can be mis-implemented or mis-used. In particular, what anti-forgery/security controls should network operators implement and check; and what anti-forgery/security controls should network operators not implement or check? Are they better implemented and checked by the application/user instead? Just as many people seem to get mad at ISPs when they do something, as get mad at ISPs when they don't do something. And its often the same something.

On Sun, 6 Dec 2009, Bill Stewart wrote:

On Sun, Dec 6, 2009 at 2:56 PM, Sean Donelan <sean@donelan.com> wrote:

...

In particular, what anti-forgery/security controls should network operators implement and check; and what anti-forgery/security controls should network operators not implement or check?

Depends a bit on whether you're counting inbound-mail-service operators as network operators.

Because this is NANOG, I was scoping it to be just layer 0 to 4. Leaving the application and above layer discussions to other places. I would love to know how the marketplace wants to handle "Official Mail," but I'm not expecting useful answers here.

As an end user who doesn't have an account at Bank of America, I'd be happy if bankofamerica.com used SPF records so my mail system could discard forged spam from them; that's much different than the kind of forgery prevention I want for my actual bank. (And obviously SPF isn't going to stop mail from bank0vamer1ca.cm etc., but it can cut down some of the noise and leave the rest for Spamassassin.)

Like most things, scaling is the only problem. Your Bank is different from My Bank, and His Bank and Her Bank, and so on. Throw in multiple middle-parties, i.e. the NSP, ISP, MSP, ESP, etc; and the problem becomes very difficult. And that's before adding the problem the real Your Bank (or their marketing partners, or their compromised PCs) may also send stuff you don't want. Network operations probably aren't going to solve those problems. And lots of other places like to discuss them. So instead, what things should network operators be expected to solve? If you can't trust routing, can you trust DNS? If you can't trust DNS, can you trust things using DNS? If you can't trust ???, can you trust ???

The problem we face is that some people we work with can't do that

Then explain that client-side (their users, to whom they send mail) are probably using Hotmail, et.al. and SPF will simply not allow "spoofing" which is what they want to do, unless they either : A) add the SPF record as previously mentioned. It's a TXT record under their root and isn't hard at all. B) permit you to use a subdomain (like "user@theircompanymail.yourdomain.com"). A variant of (B) would be to ask them if you can register "theircompanymail.[com|net|..]" and send from that with proper SPF records. Most people won't notice the difference. We run into this all the time (a .edu) where users decide they want to use Yahoo for their email (we let them do that) .. but then configure their @edu address as the FROM and wonder why nobody gets their email. (we have to constantly explain how "NO, we won't add Yahoo's mail servers to our SPF record") Personally, I think SPF is a major PITA operations-wise .. but if you've ever had to fill out the form to get un-blacklisted at Yahoo/AOL, that's one of the first things they ask .. "do you have a spfv1 record defined?". As an aside, allowing your customers to forward @yourdomain to @otherdomain .. is a good way to get your own MXs blacklisted (this happens to us about once a month, then the "free whatever" adds blast our @edu addresses and a third of them go off to Yahoo .. our spam filters catch most of it, but then they miss a batch, we always have problems because of the forwards.) Regards, Michael Holstein Cleveland State University

On Mon, Dec 7, 2009 at 11:21 PM, Michael Holstein <michael.holstein@csuohio.edu> wrote:

Personally, I think SPF is a major PITA operations-wise .. but if you've ever had to fill out the form to get un-blacklisted at Yahoo/AOL, that's one of the first things they ask .. "do you have a spfv1 record defined?".

With yahoo and aol - they'd be just as satisfied if you used, say, DKIM. Hotmail's the only one that insists on sender-id (not spfv1 either) As for a university smarthost getting blocked you'd probably need to look at one of two things - 1. Forwarding users on your campus - with mailboxes that accept a lot of spam and then forward it over to student / alumni AOL, Comcast, Yahoo etc accounts 2. Spam generated by infected PCs / laptops, hacked machines etc on your campus LAN If you took steps to fix some of these - 1. Isolate your forwarding through a separate IP or subnet, filter it before forwarding on 2. Separate your outbound to another set of IPs, again filter and a few other things - related to this .. you'd get blocked far less. Joe St.Sauver of UOregon, being a maawg senior tech advisor and also active in EDUCAUSE etc, might have a white paper on this, like he does on most other security related issues under the sun :) -- Suresh Ramasubramanian (ops.lists@gmail.com)

Absolutely #3 - far more of a threat than #1 and #2. On Tue, Dec 8, 2009 at 10:09 PM, Tony Finch <dot@dotat.at> wrote:

Three :-)

...

1. Forwarding users on your campus - with mailboxes that accept a lot of spam and then forward it over to student / alumni AOL, Comcast, Yahoo etc accounts 2. Spam generated by infected PCs / laptops, hacked machines etc on your campus LAN

3. Spammers abusing your webmail and/or remote message submission service using phished credentials.

-- Suresh Ramasubramanian (ops.lists@gmail.com)

On Tue, 8 Dec 2009, Michael Holstein wrote:

...

3. Spammers abusing your webmail and/or remote message submission service using phished credentials.

I'll admit .. this has happened a few times too. Usually we see the incoming phish attempt and configure an outbound block for RE: (same subject) and it never fails .. we catch at least one person that responds. We've seriously considered sending our own phishing emails with a link that automatically disables anyone's account if they click it.

In addition to rate-limiting, you can get some assistance from the anti-phishing email reply blacklist (see http://code.google.com/p/anti-phishing-email-reply/) which is included in the Sanesecurity ClamAV add-on databases (see http://sanesecurity.co.uk/databases.htm). Even if it's too late to block the incoming phish it can be useful to block your users' replies. There's also "Kochi" which analyses email for phishing- related patterns, including detecting messages that contain users' passwords (see http://oss.lboro.ac.uk/kochi1.html). There's a fair amount of discussion of this kind of thing on the hied-emailadmin list (see https://listserv.nd.edu/cgi-bin/wa?A0=HIED-EMAILADMIN).

Our volume is 1.5-2m msg/day, and I'd say we catch ~95% of it .. but when a batch gets through and a third of our students have mail forwarded to Yahoo, from Yahoo's point-of-view, they just got 10,000 spam from our IPs.

Ah, you have rather more forwarding than we do.

Anyone know how to do this in Domino off-hand? (without sending IBM a fat check) .. if so, I'd love to hear about it so I can tell our Lotus admins.

Put a Unix mailer between it and the real world :-) I think Exim's rate limiting facility is excellent, but then I wrote it :-) Tony. -- <fanf@exim.org> <dot@dotat.at> http://dotat.at/ ${sg{\N${sg{\ N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\ \N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}

From talking to a few people so far it seems like it might be better to have the development team here alter our applications to use a separate Envelope From and friendly From. I can display the email address with the customers domain, but the mail will be coming from our address as the Envelope From. That way the customer is happy their end user is seeing the email coming from their domain, while the Envelope From shows an email address that matches our domain. Seems like a simpler solution.

Thank you all for your input, as I know this may be a bit off topic for this list. Jeffrey -----Original Message----- From: Graeme Fowler [mailto:graeme@graemef.net] Sent: Friday, December 04, 2009 1:59 PM To: NANOG Subject: RE: SPF Configurations On Fri, 2009-12-04 at 11:45 -0500, Jeffrey Negro wrote:

Thanks for your input on this. My main concern is mail filters at the end users side thinking that our mail servers are spoofing our customer's domain.

If you really feel that SPF is going to help, then keep all the mail in your domain's control by using VERP addresses as the envelope sender address (like most decent modern MLM packages do). That way you can have a "From: " header in the customer domain (or of your choosing), and the envelope sender in your own. The benefit here is that not only does it make the usage of SPF a lot less complex, but it also means that all bounces come back to the originating system and can be handled accordingly. Have a look at the headers of this message for a well-formed example. Of course, this does depend upon people believing that SPF is actually useful... Graeme