Re: [courier-users] Checking SPF source
On 09/Feb/11 05:13, Mark Constable wrote: On 09/02/11, Sam Varshavchik wrote: The only thing I can think of would be a transient DNS lookup failure for pobox.com. mailfromok is accepted only if the SPF lookup on the MAIL FROM resulted in pass. That may be possible because I'm in AU and a lookup I just did now from the same mailserver was... ~ dig txt pobox.com ;; Query time: 245 msec A transient DNS lookup failure results in an SPF softfail result, rather. Isn't it TempError? RFC 4408 says (sect. 4.4) If all DNS lookups that are made return a server failure (RCODE 2), or other error (RCODE other than 0 or 3), or time out, then check_host() exits immediately with the result TempError. and (sect. 5) Several mechanisms rely on information fetched from DNS. For these DNS queries, except where noted, if the DNS server returns an error (RCODE other than 0 or 3) or the query times out, the mechanism throws the exception TempError. If the server returns domain does not exist (RCODE 3), then evaluation of the mechanism continues as if the server returned no error (RCODE 0) and zero answer records. and in such cases (sect 2.5.6) A TempError result means that the SPF client encountered a transient error while performing the check. Checking software can choose to accept or temporarily reject the message. If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN code. I think this is probably wrong; mailfromok should be accepted if the SPF lookup resulted in softfail, as well... So courier is at fault in this particular corner case? Well, testing BOFHSPFFROM is obviously non-standard. For the TempError issue above, without looking at the code, I recall Courier passes the timeout tests (scenario 2) --according to the results I posted a couple of years ago: http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg33232.html -- -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Checking SPF source
Mark Constable writes:
On 09/02/11, Sam Varshavchik wrote:
The only thing I can think of would be a transient DNS lookup
failure for pobox.com. mailfromok is accepted only if the SPF
lookup on the MAIL FROM resulted in pass.
That may be possible because I'm in AU and a lookup I just did
now from the same mailserver was...
~ dig txt pobox.com
;; Query time: 245 msec
whereas the next attempt was 14 msec. This TXT record is rather
intense so I could well imagine DNS timing out trying to look
for a match through all of this gunk...
~ dig +short txt pobox.com
v=spf1 mx mx:fallback-relay.%{d} a:webmail.%{d} a:smtp.%{d}
a:outgoing.smtp.%{d} a:discard-reports.%{d} a:discards.%{d}
A transient DNS lookup failure results in an SPF softfail
result, rather. I think this is probably wrong; mailfromok
should be accepted if the SPF lookup resulted in softfail,
as well...
So courier is at fault in this particular corner case?
Yes. The corner needs to be rounded a bit.
pgpQuKNpxolw1.pgp
Description: PGP signature
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Checking SPF source
Mark Constable writes:
I've got this SPF rejection and I'm still confused as to exactly what
gets trigerred. Obviously the message is rejected before I get to see
any headers that would give me a better clue. The envelope sender domain
SPF does include this IP 64.74.157.52 but the From: domain does not so
I think my question is, that with my bofh SPF rules, how come
BOFHSPFMAILFROM didn't give me a pass?
Feb 9 07:47:38 mail courieresmtpd: error,relay=:::64.74.157.52,
from=SRS0=MnWw=VF=morningstar.com=help...@bounce2.pobox.com:
517 SPF fail help...@morningstar.com: Address does not pass the Sender Policy
Framework
courier-mta 0.60.0
opt BOFHSPFHELO=pass,none,neutral,softfail,unknown,error
opt BOFHSPFMAILFROM=pass,none,neutral,softfail,unknown,error
opt BOFHSPFFROM=pass,none,neutral,softfail,unknown,error,mailfromok
opt BOFHSPFTRUSTME=1
First the From: domain...
~ dig +short txt morningstar.com
v=spf1 a:spfmailer.morningstar.com -all
~ dig +short a spfmailer.morningstar.com
66.35.231.16
66.35.231.15
216.228.234.30
216.228.233.9
216.228.233.10
216.228.228.165
216.228.228.164
216.228.228.163
216.228.228.162
216.228.228.161
216.228.228.160
216.228.224.50
216.228.224.34
216.228.224.33
216.228.224.32
210.193.131.12
12.43.226.3
66.35.231.18
66.35.231.17
No 64.74.157.52 above. Then the sender envelope domain...
~ dig +short txt bounce2.pobox.com
v=spf1 redirect=pobox.com
I presume the above means to now look at the TXT record for pobox.com
~ dig +short txt pobox.com
v=spf1 mx mx:fallback-relay.%{d} a:webmail.%{d} a:smtp.%{d} a:outgoing.smtp.%{d}
a:discard-reports.%{d} a:discards.%{d}
~ dig +short mx pobox.com
10 mx-3.pobox.com.
10 mx-2.pobox.com.
10 mx-6.pobox.com.
10 mx-1.pobox.com.
10 mx-4.pobox.com.
10 mx-5.pobox.com.
10 mx-7.pobox.com.
10 mx-all.pobox.com.
And we have a winner!...
~ dig +short a mx-4.pobox.com
64.74.157.52
64.74.157.52
64.74.157.52
64.74.157.52
64.74.157.52
64.74.157.52
64.74.157.52
64.74.157.52
The only thing I can think of would be a transient DNS lookup failure for
pobox.com. mailfromok is accepted only if the SPF lookup on the MAIL FROM
resulted in pass.
A transient DNS lookup failure results in an SPF softfail result, rather. I
think this is probably wrong; mailfromok should be accepted if the SPF
lookup resulted in softfail, as well…
pgp9i5D6WX3Qi.pgp
Description: PGP signature
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Checking SPF source
On 09/02/11, Sam Varshavchik wrote:
The only thing I can think of would be a transient DNS lookup
failure for pobox.com. mailfromok is accepted only if the SPF
lookup on the MAIL FROM resulted in pass.
That may be possible because I'm in AU and a lookup I just did
now from the same mailserver was...
~ dig txt pobox.com
;; Query time: 245 msec
whereas the next attempt was 14 msec. This TXT record is rather
intense so I could well imagine DNS timing out trying to look
for a match through all of this gunk...
~ dig +short txt pobox.com
v=spf1 mx mx:fallback-relay.%{d} a:webmail.%{d} a:smtp.%{d}
a:outgoing.smtp.%{d} a:discard-reports.%{d} a:discards.%{d}
A transient DNS lookup failure results in an SPF softfail
result, rather. I think this is probably wrong; mailfromok
should be accepted if the SPF lookup resulted in softfail,
as well...
So courier is at fault in this particular corner case?
--markc
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
