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 ([EMAIL PROTECTED] and 64.12.138.200). >> >> In facts, I get >> >> # rfc1035/testspf [EMAIL PROTECTED] 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;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
