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
jnegro@billtrust.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
Jeffrey Negro wrote:
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
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
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
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
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 and
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
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 :
[ various large ISPs that publish SPF ]
Perhaps this is a language problem. In English, "publishes" is not a
synonym for "pays attention to." As I said, you need to publish SPF
to get mail into Hotmail. That's why people do it.
I know there is a problem so far with forwarded emails but there is also a
solution :
[ hoary SRS proposal to change every SMTP server in the world to make them
match what SPF does ]
Sigh.
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.
You might want to look at BATV, which has nothing to do with SPF, but
I have found is quite useful for recognizing spam blowback.
R's,
John
PS:
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.
Our policy is to send messages with confidentiality notices to all of
your competitors.
FWIW, GMX (pretty popular in Europe) does too.
Lars
John,
Von: John R. Levine [mailto:johnl@iecc.com]
Gesendet: Samstag, 5. Dezember 2009 01:54
An: Andre Engel
Cc: nanog@nanog.org
Betreff: Re: AW: SPF Configurations>> 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 :
> [ various large ISPs that publish SPF ]Perhaps this is a language problem. In English, "publishes" is not a
synonym for "pays attention to." As I said, you need to publish SPF
to get mail into Hotmail. That's why people do it.
As I said im almost german
Some major providers ,1&1 for example, assigned their customers the
"responsibility" to "pay attention on SPF" for getting mails into their
boxes.(decision between suspicious or not)
> I know there is a problem so far with forwarded emails but there is
also a
> solution :
> [ hoary SRS proposal to change every SMTP server in the world to make
them
> match what SPF does ]Sigh.
I do not want to change every SMTP servers in the world. I just gonna show
an useful option .-)
> 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.You might want to look at BATV, which has nothing to do with SPF, but
I have found is quite useful for recognizing spam blowback.
Sure ! For instance If your are providing an mail cluster for your customer
bills, a newsletter server or a cooperated
mail cluster and you know that you are sending emails only to receivers
email boxes BATV is indeed a awesome tool.
But if you are performing a shared mail cluster for your webhosting or your
Dial in customers which are using for instance some special kinds of mailing
lists maybe you need a additional solution.
From a reputation perspective Id like the idea to combine a set of anti spam
tools if it is useful.
Indeed MAAWG is not "the badest place" to learn about.
R's,
JohnPS:
> 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.Our policy is to send messages with confidentiality notices to all of
your competitors.
Sure! Im here to learn *** .-)
Cheers
Andre
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.
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.)
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 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
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 "user@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
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
I would love to know how the marketplace wants to handle "Official Mail,"
but I'm not expecting useful answers here.
The marketplace doesn't have a clue. We have a plenty of tools in the
toolbox, from heavyweight S/MIME to lighter weight DKIM+VBR to
proprietary Goodmail, but among the mailers with a stake in having a
reliable spoof-resistant channel I don't see much interest in doing
anything other than whatever they're doing now.
If it were up to me, I'd use per-recipient password-protected RSS or Atom
feeds with emailed notices that just say to check your feed, but that has
patent issues.
R's,
John
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.
Absolutely #3 - far more of a threat than #1 and #2.
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