Re: [courier-users] SPF tempfail

Joe Laffey wrote:
> On Wed, 30 Apr 2008, Alessandro Vesely wrote:
>
>> Joe Laffey wrote:
>>> opt BOFHSPFHARDERROR=fail
>>> [...]
>>> BOFHSPFHARDERROR=fail to remove the default softfail in that variable.
>>
>> Sounds slightly nonsensical, as a "~all" doesn't have a decent chance
>> to be amended within the few days that a temporary failure can keep a
>> given message in the remote host's queue.
>
> Ah, I see your point. But how to handle a softfail just once? By putting
> softfail in the list of BOFHSPFMAILFROM I am ignoring softfails, and
> passing them anyway... right?

Correct. That's the way they are supposed to work, much like neutrals.
However, SPF literature suggests the ~ qualifier is related to testing
or debugging. That would call for an option to send notifications to
the relevant site's postmaster whenever a messages passes because of a
softfail.

>>> Odd thing is that it is tempfailing on an address/ip combo that
>>> should be
>>> working (xxxx@aol.com and 64.12.138.200).
>>
>> In facts, I get
>>
>> # rfc1035/testspf xxxx@aol.com 64.12.138.200 ...
>> pass
>>
>> According to http://www.openspf.org/RFC_4408 , you can get a TempError
>> as a consequence of DNS lookup failures or timeouts.
>
> Yes. This was what I tested, and why I thought it was odd that this
> address/ip combination was tempfailing (4xxx error code).
>
> I added "error" to BOFHSPFMAILFROM and this seems to have fixed it.

Yes, if a domain's admins want you to block certain messages, they
have to say "fail" loud and clear.

> It would be very nice if the SPF checking code would log the type of
> failure (the SPF keyword, e.g. "pass", "fail", "softfail", "error") with
> each logged rejection. This would make it easier to tell what was
> happening.

Agreed. Currently you get a detailed log in the headers, but that can
only be viewed when the mail is accepted. However, I don't think that
enhancing SPF implementation is anywhere near the top of Courier's
priorities.

>>> Also is there a way to instruct courier to ignore SPF for certain
>>> domains?
>>
>> AFAIK no. That should be amended, to fix forwarding. (One should login
>> in order to submit mail without SPF checking. However, authenticated
>> hosts currently get full RELAYCLIENT permissions.)
>
> Would be nice for instances when some client "must" receive mail from
> somebody who has their SPF records set incorrectly (like they have them
> set conservatively and the sender is on the road using some other SMTP).

Actually, that could be done by setting a global filter that uses SPF
results from the headers and applies whatever options it likes. Doing
so for the envelope values (MAILFROM and HELO) defies SPF's ability to
reject invalid mail at the very beginning of a transaction. OTOH, it
is the only sensible way to use the FROM checking, because of
SPF-agnostic mailing lists (the sender-on-the-road should use port 587.)













































-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757...un.com/javaone
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/.../courier-users