[Mimedefang] Integrating SPF...

[Mark]

> -----Original Message-----
> From: mimedefang-bounces at lists.roaringpenguin.com
> [mailto:mimedefang-bounces at lists.roaringpenguin.com] On
> Behalf Of James Ebright
> Sent: donderdag 31 maart 2005 0:55
> To: mimedefang at lists.roaringpenguin.com
> Subject: Re: [Mimedefang] Integrating SPF...
>
>
>
> 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".

POP is cute; but the relationship between a provider's POP space and their
designated sender IP space is weak at best -- if existing at all. For SPF,
only the sender IP space is relevant.

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

You are confusing a few things, I'm afraid. As per,

http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt

"softfail" holds the middle between a "fail" and "neutral". "softfail" is
typically used to indicate a transitional phase; it means something like:
"I am done configuring; I think I got it all set up correctly. The IP you
just checked is in all likelihood not authorized; but, please take the
'fail' with a grain of salt, as I may not have published a good enough SPF
record yet to cover all IP relevant sender IP space."

The case where "the ISP does not have an SPF record published" is "none",
not "softfail". And "some other temp fail or guess type situation" is not
covered by "softfail" either, but by "TempError (section 2.5.6). And if
you choose to REJECT based on TempError, a 451 reply code is warrented
(4.4.3 extended).

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

The whole smarthost issue does not exist. :) Seriously. Any ISP worth its
money should open port 587, and allow (SMTP AUTH only) submissions on it.
Hotels and such blocking/smarthosting port 587, to my knowledge, never
happens. And would be rather silly too, as submissions to port 587 are
authenticated-only.

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx