Re: SPF Configurations
On Tue, 8 Dec 2009, Suresh Ramasubramanian wrote: As for a university smarthost getting blocked you'd probably need to look at one of two things - 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. If your incoming spam blocks are effective then forwarding shouldn't be too much of a problem. For on-campus bots, block port 25 and ensure your MX servers can't be used as outgoing relays (i.e. put your outgoing relay service on a separate address). If you are lucky your colleagues chose a really obscure name (not mail.* or smtp.* etc.) for your outgoing relay service 20 years ago so spammers are less likely to guess it :-) To protect against phished accounts, apply rate-limits to outgoing email. If you have good on-campus security hygeine then you can be much less strict about the limits for on-campus connections. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: SPF Configurations
Absolutely #3 - far more of a threat than #1 and #2. On Tue, Dec 8, 2009 at 10:09 PM, Tony Finch d...@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.li...@gmail.com)
Re: SPF Configurations
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. If your incoming spam blocks are effective then forwarding shouldn't be too much of a problem. Never-ending game of cat mouse. 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. For on-campus bots, block port 25 and ensure your MX servers can't be used as outgoing relays We do that, as well as run daily reports on outbound ACL denies to see who's been compromised (or being naughty on purpose). (i.e. put your outgoing relay service on a separate address). If you are lucky your colleagues chose a really obscure name (not mail.* or smtp.* etc.) They did. To protect against phished accounts, apply rate-limits to outgoing email. If you have good on-campus security hygeine then you can be much less strict about the limits for on-campus connections. 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. Cheers, Michael Holstein Cleveland State University
Re: SPF Configurations
On Sun, 6 Dec 2009, Bill Stewart wrote: On Sun, Dec 6, 2009 at 2:56 PM, Sean Donelan s...@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 ???
Re: SPF Configurations
On Dec 7, 2009, at 9:51 AM, Michael Holstein wrote: 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. An authorization tied to a PRA or Mail From will not prevent spoofing, it just constrains the risks to those with access to a provider's service. A provider could insure a user controls the From email-address, but this would conflict with the IP path registration schemes. B) permit you to use a subdomain (like u...@theircompanymail.yourdomain.com). A provider can ensure any signed From email-address is controlled by its users by using ping-back email confirmations appended to user profiles. There is a proposal aimed at reducing DNS overhead and scalability issues associated with the all-inclusive IP address path registration scheme with its inability to cope with forwarded email: http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03 Use of this DKIM extension can safely accommodate a user's desire to authorize third-party signatures to protect acceptance of From headers within domains that differ from the DKIM signature. DKIM does not need to change. Once IPv6 and international TLDs come into the mix, having users vote (authorize) DKIM providers could better determine what new domains can be trusted, and help ensure users are allowed to utilize their own language and to seek assistance in obtaining acceptable IPv6 connectivity. -Doug
Re: SPF Configurations
On Mon, Dec 7, 2009 at 11:21 PM, Michael Holstein michael.holst...@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.li...@gmail.com)
Re: SPF Configurations
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.
Re: SPF Configurations
On Sun, Dec 6, 2009 at 2:56 PM, Sean Donelan s...@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. 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.) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
RE: SPF Configurations
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. I'll check into MAAWG as well Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 jne...@billtrust.com -Original Message- From: Joe St Sauver [mailto:j...@oregon.uoregon.edu] Sent: Friday, December 04, 2009 11:25 AM To: Jeffrey Negro Subject: Re: SPF Configurations #Some customers insist on #making the FROM address use their domain name, but the emails leave our #mail servers on our domain. Then your IPs or outbound mail servers should be listed on the customer's SPF record... assuming they also send their own mail, they obviously also want to list their own mail servers. #SPF seems to be the way we could possibly avoid more spam filters, SPF only provides a way of avoiding spoofing, it does not necessarily enhance your IP reputation or your domain reputation #and delivery rate is very important to our company. Are you involved with MAAWG? (see www.maawg.org) Regards, Joe
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. 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 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. I'll check into MAAWG as well Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 jne...@billtrust.com -Original Message- From: Joe St Sauver [mailto:j...@oregon.uoregon.edu] Sent: Friday, December 04, 2009 11:25 AM To: Jeffrey Negro Subject: Re: SPF Configurations #Some customers insist on #making the FROM address use their domain name, but the emails leave our #mail servers on our domain. Then your IPs or outbound mail servers should be listed on the customer's SPF record... assuming they also send their own mail, they obviously also want to list their own mail servers. #SPF seems to be the way we could possibly avoid more spam filters, SPF only provides a way of avoiding spoofing, it does not necessarily enhance your IP reputation or your domain reputation #and delivery rate is very important to our company. Are you involved with MAAWG? (see www.maawg.org) Regards, Joe
Re: SPF Configurations
2009/12/4 Bret Clark bcl...@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 Gaullehttp://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html - The better I get to know men, the more I find myself loving dogs.
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
RE: SPF Configurations
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:gra...@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
Re: SPF Configurations
On Fri, Dec 4, 2009 at 9:55 PM, Jeffrey Negro jne...@billtrust.com wrote: I'm wondering if a few DNS experts out there could give me some input on SPF record configuration. Our company sends out about 50k - 100k emails a day, and most emails are on behalf of customers to their end users at SPF records aren't going ot help as much as some list sending and deliverability best practices (feedback loops etc) are. Look at the MAAWG senders best practices document - www.maawg.org - Published Documents Other than delivery to hotmail, spf is a total waste of time - plus it plays russian roulette with whatever email you handle
Re: SPF Configurations
On 2009-12-4, at 7:25, John Levine wrote: The only major mail system that pays attention to SPF is Hotmail FWIW, GMX (pretty popular in Europe) does too. Lars smime.p7s Description: S/MIME cryptographic signature
Re: SPF Configurations
Jeffrey Negro wrote: SPF seems to be the way we could possibly avoid more spam filters, and delivery rate is very important to our company. You've seen the anti-SPF rants. At the least, they should make clear to you that you should use SPF only and exactly for specific destinations that you already know require it. If you have any doubts about the requirement, you'll try to verify it; otherwise assume SPF won't solve your problems. The other obvious mechanisms for validated identification to receiving operators is, of course, with DKIM. DKIM is entirely comfortable having a validated identifier (the d= parameter in the signature header field) be different than whatever is in the author header field (From:) But either way, that's just identification. As already noted on the thread, what matters most is the set of content and operations practices, to establish a rock solid reputation both of you and of your clients. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
