[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 18:10
> To: mimedefang at lists.roaringpenguin.com
> Subject: RE: [Mimedefang] Integrating SPF...
>
>
>
> On Thu, 31 Mar 2005 02:02:24 GMT, Mark wrote
>
> > 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).
>
> ...  In other words... softfail should not be a
> permanent situation, but in many cases I have seen, the
> response has remained a softfail return for over a year..... go figure.

I agree with you, here. "softfail" should really not be a permanent
solution. It is really meant to see whether you, the ISP, have perhaps
overlooked certain mailers or conditions (which may be quite possible, if
you're a large ISP).

> Also do not forget, if you do not rewrite your envelope for
> "road warrior" type consumers, whether they auth or not,

If you refer to SRS, yes.

> it will fail SPF (or softfail <grin>) for mail sent to another
> domain hosted elsewhere that also checks your SPF
> record. It will fail locally too but I would hope you do not
> care about SPF checks for your local consumers after they auth.

I care in the sense that a Received-SPF is added, in the form of:

Received-SPF: pass (asarian-host.net: 1.2.3.4
        is authenticated by a trusted mechanism)

Be it through SMTP AUTH / STARTTLS / DRAC, etc.

> > 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.
>
> Perhaps you misunderstand where the smarthost would come into
> play here, or perhaps you overestimate the hospice industry?
> The smarthost in question is not the ISPs but the one located
> behind the NAT at hotel XYZ.

I have never run into a hotel's smarthost for outgoing connections on port
587. For reasons outlined above. But since you do a (forced) authenticated
login to your mail server at port 587 anyway, the actual relay used is not
really relevant. Unless they blocked 587. But, like I said, there is no
reason for them to do that, as you really cannot send mail out to
arbitrary recipients in the world (for people to receive on port 25, that
is), except to a mail mail server under your control, with a valid
username + password.

> ... it all boils down to this.. how competent the
> consultant was when he setup and configured the proxy/nat/firewall.

Indeed. Likewise, there are still mail servers out there who do not
enforce an AUTH mechanism on port 587.

- Mark 
 
        System Administrator Asarian-host.org
 
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx