[Mimedefang] Integrating SPF...

[Kris Deugau]

James Ebright wrote:
> On Wed, 30 Mar 2005 16:46:22 -0500, Kris Deugau wrote
> >I think you meant "99.9% of those customers WILL fail SPF as they
> > are sending from an IP outside [their POP provider's] range but
> > using [their POP provider's] domain name".
> 
> Yes, that is exactly how I meant you. in the general sense.

Just making sure I'm arguing the right points.  <g>

I think we're talking at different angles here;  what I've written is
according to my understanding of SPF and how it's used and how it
relates to other technologies to make them more effective/useful.  (Or
how other technologies make SPF more useful.)

> > 1)  Misconfigured SPF record that doesn't include everything it
> > should.
> 
> No, you should never include DHCP roaming, shared IPs in your SPF
> record for your road warriors. This address space is not "yours" and
> is shared by many others, thus SPF is configured correctly.

Mmm.  If you *know* you'll have people sending mail using your domain,
through mail servers you don't control or trust, then SPF isn't going to
work well for you.

SPF records don't just include "your" address space;  they may specify
other IP addresses you trust to send mail with your domain.  For
instance, my own domain's SPF record specifies that my parent's ISP's
mail servers may also relay mail for my domain - that ISP doesn't
currently have an SPF record, AFAIK, but if they did my parents would be
able to use an email address at my domain with their ISP's mail server.

If you know your mobile users will be connecting from a specific,
limited number of other systems, you may be able to just add those
servers to your SPF record - there's nothing to stop you doing so.

> > 2)  SPF shouldn't even be used.  This is most likely;  if a company
> > explicitly does NOT know where their customers may be sending email
> > from, they can't usefully enforce any kind of sender policy!
> 
> I disagree, I know exactly where 90% of my customers are sending
> from..

But you DON'T know where 10% of your customers are sending from, and
therefore you have a choice of:

1) Set a restrictive SPF record, and penalize your more mobile customers
who don't relay through your servers for whatever reason, or

2) Set a loose SPF record or no record, and put up with the potential
hassles that may come with.  (Few to none, currently;  although I can
see that changing.)

> its again.. only the road warriors. I should mention though..
> most of my competitors in this area do not even have their own pop
> sites anymore.. effectively making ALL of their customer base fall
> under my "road warrior" category.

Those companies should either have no SPF record, or a really strict
record and provide authenticated SMTP to allow customers to relay
through their server according to their SPF policy.

> Not to mention even my road
> warriors send their outbound mail through my server (tls auth first
> to enable relay among other things) so the SPF failure will ONLY be
> occuring on my server(s).. thus it is manageable.

Er, if they're relaying through your server then SPF only becomes a
factor (for *other* systems rejecting mail *from* your customers) if you
managed to miss listing one of your servers in your SPF record.

IOW, you're enforcing use of your server to send mail with your domain
(or your customer's domain, if they're hosting a domain with you).  The
enforcement is *other* sites' SPF checks.  (Un?)fortunately this is a
voluntary check.

> Frankly I cannot think of a single legitimate reason for any ISP/WISP
> NOT to publish SPF.

Mmmm.  I'm on the fence on this one a bit.  On the one hand it makes it
simpler for third parties to tag/reject/delete mail not sent through the
Approved Relay, on the other hand it's truly a non-trivial task to get
customers to change their SMTP settings to support SMTP AUTH - even just
for those that would really need it because they're emailing on the
road. 

> > 3)  No provision for authenticated SMTP through their own servers,
> > which they can and do list properly in their SPF record.
> 
> SPF and sender auth are two different things and I believe I have
> mentioned this twice already.

Yes, they are different things.  But they are *also* related services! 
If you publish a very strict SPF record, you better be prepared to offer
SMTP AUTH for your road warriors unless you want other places to reject
those customers' email on the road!

Here's an example:  My domain has a very strict SPF record;  there are
only a VERY few specific systems "allowed" to send SMTP traffic using my
domain in the sender's email address - my server, those of a few
friends.  (I also include my parents' ISP's mail servers "just in
case".)  If, for some stupid reason, I try to send email from my domain
through my company's mail server (I work for an ISP, and my domain is on
my box colocated in the office I work in), *any system doing SMTP-level
SPF checks should reject that message*.

On the other hand, if I properly relay mail through my own mail server
(via TLS-wrapped SMTP AUTH), the message should receive an SPF "pass"
because it was sent in accordance with the email policy I have set for
my domain.

> We do both, if you authenticate I do not care about your
> connections SPF as you are already authenticated using one of my
> customers credentials. I see nothing to gain even examining SPF
> records for my own customers in the ISP sense, its just wasted cpu
> cycles to do so IMHO.

The problem is when you have a strict SPF record, but one of your
customers emails someone on a system that does strict SPF checks... and
does NOT use your SMTP to send that message.

-kgd
-- 
Get your mouse off of there!  You don't know where that email has been!