[Mimedefang] Integrating SPF...

[James Ebright]

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.


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

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

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

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

> Personally, I can't see using anything other than a soft-fail for SPF
> for ISP domains (at least for a few years...);  customers *will* do
> strange things like, oh, say, take the laptop on [vacation/business
> trip] and try to send through the hotel's provided (and enforced)
>  SMTP smarthost.

Softfail simply means the ISP does not have a SPF record published (most
likely) or you could not find one for them or some other temp fail or guess
type situation... or they have not tested their SPF implementation and have
the softfail all in their record.... which somewhat defeats the whole purpose
of even having a SPF record... /sigh.

As for the Smarthost proxy issue... well thats a bugger that will cause worse
issues than the one I mentioned above, as it grabs the entire smtp connection
transparently behind the scenes... thus all other servers world wide including
my customers own mail server will see SPF fails for this customer and I would
not have the authentication/envelope rewrite to fall back on to correct this.

Guess that is another thing to keep in mind!  :-)


PS, all yous and yours are in the general sense, It is nothing personal, I am
a lazy typist! ;-)

Jim
--
EsisNet.com Webmail Client