Re: SPF Configurations

[Tony Finch]

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.
-- 
  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}}

Re: SPF Configurations

[Michael Holstein]

> 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

[Suresh Ramasubramanian]

Absolutely #3 - far more of a threat than #1 and #2.

On Tue, Dec 8, 2009 at 10:09 PM, Tony Finch  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

[Tony Finch]

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.finchhttp://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Re: Official Mail, was SPF Configurations

[John Levine]

>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

Re: SPF Configurations

[Suresh Ramasubramanian]

On Mon, Dec 7, 2009 at 11:21 PM, Michael Holstein
 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

[Douglas Otis]

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

[Michael Holstein]

> 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
"u...@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

Re: SPF Configurations

[Sean Donelan]

On Sun, 6 Dec 2009, Bill Stewart wrote:

On Sun, Dec 6, 2009 at 2:56 PM, Sean Donelan  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

[Bill Stewart]

On Sun, Dec 6, 2009 at 2:56 PM, Sean Donelan  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

[Sean Donelan]

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.

AW: AW: SPF Configurations

[Andre Engel]

John,

> -Ursprüngliche Nachricht-
> Von: John R. Levine [mailto:jo...@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,
> 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.

Sure! Im here to learn *** .-)


Cheers

Andre 



 --
Andre Engel

Consulting Program Director, 
Email and Cyber Intelligence Services"..no space left on the
device/Kein Weltraum links auf dem Gerät"


FHE3 GmbHP: +49 721 869  5907
Scheffelstr. 17a M: +49 160 962 44476 
76135 Karlsruhe


andre.en...@fhe3.com
http://www.fhe3.com/

Amtsgericht Mannheim, HRB 702495
Umsatzsteuer-Ident: DE254677931
Geschäftsführer: Peter Eisenhauer, Michael Feger, Dimitrij Hilt

***
This email is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE ,...

Re: SPF Configurations

[Dave CROCKER]

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

Re: SPF Configurations

[Lars Eggert]

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: AW: SPF Configurations

[John R. Levine]

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.

Re: SPF Configurations

[Suresh Ramasubramanian]

On Fri, Dec 4, 2009 at 9:55 PM, Jeffrey Negro  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

AW: SPF Configurations

[Andre Engel]

 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:



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 GmbHP: +49 721 869  5907
Scheffelstr. 17a M: +49 160 962 44476 
76135 Karlsruhe


andre.en...@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:jo...@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
> 
> 

RE: SPF Configurations

[Jeffrey Negro]

>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

[Graeme Fowler]

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

[John Levine]

>> 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

Re: SPF Configurations

[James Bensley]

2009/12/4 Bret Clark 

> 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
- "The better I get to know men, the more I find myself loving dogs."

Re: SPF Configurations

[Bret Clark]

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

[Jeffrey Negro]

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

SPF Configurations

[Jeffrey Negro]

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
various domains (no, we're not spammers, these are email notifications
the end users have requested to receive).  Some customers insist on
making the FROM address use their domain name, but the emails leave our
mail servers on our domain.  SPF seems to be the way we could possibly
avoid more spam filters, and delivery rate is very important to our
company.

 

The server configuration consists of a mail server that sends outbound
only, out of a specific IP with proper MX, A, and PTR records.  This is
a sample of the SPF configuration I believe would be correct:

 

Our company (example.com) records:

 

IN   MX 10 mail.example.com

mailIN   A


example.com   IN   TXT "v=spf1 mx -all"

example.comIN   SPF "v=spf1 mx -all"

mailIN   TXT
"v=spf1 a -all"

mailIN   SPF
"v=spf1 a -all"

 

customer.com   IN   TXT "v=spf1
include:example.com -all"

customer.com   IN   SPF "v=spf1
include:example.com -all"

 

Our customer's (customer.com) records:

 

IN   MX
10 mail.customer.com

mailIN   A


customer.com   IN   TXT "v=spf1 mx -all"

customer.com   IN   SPF "v=spf1 mx -all"

mailIN   TXT
"v=spf1 a -all"

mailIN   SPF
"v=spf1 a -all"

 

customer.com   IN   TXT "v=spf1
include:example.com -all"

customer.com   IN   SPF "v=spf1
include:example.com -all"

 

I derived this from this tutorial:
http://www.zytrax.com/books/dns/ch9/spf.html . 

 

The other part of this that may be of importance would be the NATing.
The FQDN that the world sees for the outside address of the NAT is not
the same as the inside FQDN that Postfix is using internally.  Does this
cause any problems with SPF?

 

Any comments or suggestions would be great.  Thanks in advance!

 

Jeffrey