Matt,

I do not believe that is true.  Here is a quote from "pobox.com" tthe authority on SPF:

"SPF was designed to protect the envelope sender. That means the return-path that shows up in "MAIL FROM", and to a lesser extent the HELO argument that is supposed to be an FQDN"

Note that the ENVELOPE is what is actually the forgery that is being checked for.  Otherwise, most of my customers would have problems.

Another quote varifies this, unless I am reading it wrong:

" undefined" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - Does SPF break email forwarding?

So, your answer: SpamFilter does not do SPF checks on DSN's?  I get the part where you don't think it should not. 

I'm still not sure about that because NDR's should never be sent anonymously.  So there should always be some verifyable piece.  Not having thought this one through is why I put the question here.   Wouldn't you think the the DNS should include the original recipient which could be verified as the sender?

Matt,

First, I am a user, not with LogSat.  But ... When you are talking about "DSN"  do you mean DNS?

Have you tried looking at http://spf.pobox.com" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - http://spf.pobox.com" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - http://spf.pobox.com ?  I am not sure what you are wanting DNS to do.  All the SPF record is, is a TXT record in DNS that describes what IP's host names, ptrs (RDNS) or mail servers that are allowed to be the source of mail from that domain.  DNS doesn't know anything about NDR's, Original senders or anything at all about any particular message.

Or ... am I not understanding the question which is very possible.

Regards,

Dan S

OK ... Do back up a bit.  What do you feel that SpamFilter whould or should not be doing with the SPF record?  Because ... there IS a big issue with "Forwards".

Dan

Dan,

I'm not certain if this has to do with "forwards" or not.  I was just curious about DSN handling.

SPF classic specs specify "SMTP+SPF receivers MAY
   check the HELO argument and MUST check the return-path.  A single
   SMTP transaction may therefore trigger one or two SPF queries."

That lead me to the question of  how SpamFilter handle DSN's. Some DSN's have no return-path therefore in order to handle DSN's with blank return-paths SpamFilter would have to check the HELO argument.  The goal is to identify the "responsible sender", if possible.

My opinion would be to follow the optional HELO argument in establishing the responsible sender.

This the section I am referring to in the SPF Classic spec ( http://spf.pobox.com/spf-draft-200406.txt" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - http://spf.pobox.com/spf-draft-200406.txt" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - http://spf.pobox.com/spf-draft-200406.txt ) :

"...

2.2.1 Subject of SPF testing

   In an SMTP transaction, an SMTP client may provide FQDNs in the HELO
   argument and in the MAIL FROM return-path.  SMTP+SPF receivers MAY
   check the HELO argument and MUST check the return-path.  A single
   SMTP transaction may therefore trigger one or two SPF queries.

   Accordingly, the <responsible-sender> may be drawn from the HELO
   argument or from the "MAIL FROM" return-path.  This document
   sometimes refers to the <responsible-sender> as the "envelope
   sender".

   It is RECOMMENDED that SMTP+SPF receivers perform tests using the
   following algorithm.

     SMTP+SPF receivers MAY check the HELO argument.  In this mode, the
     <responsible-sender> comes from the HELO argument IF the HELO
     argument is a fully qualified domain name.  If the HELO argument
     is not an FQDN, there is nothing to check and the result is
     "unknown".  If the HELO test returns a "fail", the overall result
     for the envelope is "fail", and there is no need to test the
     return-path.

     SMTP+SPF receivers MUST check the return-path unless HELO testing
     produced a "fail".  In this mode, the <responsible-sender> comes
     from the domain name of the "MAIL FROM" return-path.  When the
     return-path has no domain, a client MUST use the HELO domain
     instead.  If the HELO argument does not provide an FQDN, SPF
     processing terminates with "unknown".

     If SPF processing occurs after SMTP time, the envelope sender may
     be obtained from the Return-Path header.  If the Return-Path header
     has no domain, a client MAY try to extract the HELO domain from the
     Received headers.  If the headers do not yield useful envelope
     information, SPF processing terminates with "unknown".

   SMTP+SPF receivers MAY test the domain given in the HELO argument
   whether or not the return-path contains a domain name.

   However, the <responsible-sender> address MAY be drawn from an
   alternative source.  For example, an MUA may find it more convenient
   to extract the <responsible-sender> from the Return-Path header or
   from the Sender: header.

   If the <responsible-sender> has no localpart, clients MUST
   substitute the string "postmaster" for the localpart.

   The <current-domain> is initially drawn from the
   <responsible-sender>.  Recursive mechanisms such as Include and
   Redirect replace the initial <current-domain> with another domain.
   However, they do not change the value of the <responsible-sender>.
   See sections 4.2, 3.3, and 8.4.
..."

I don't think that spamfilter worries about return paths in this case. If a spf lookup reveals a problem, spamfilter will receive the email (quarantine depending on your settings) and terminate the email transfer with an error. The error code and response is under the 'customized item' tab. I don’t think it ever actually sends a new email with an error to the sender....

I could be wrong....or this may not be what you are talking about at all.

Thanks. I'm only referring to DSN's generated by other servers that SpamFilter relays to our email servers and mailboxes.  I think it's pretty rare to get a bogus or fraudulent DNS, for example a non-delivery report.  Most of the time our users get NDR's that were the result of a fraudulent email and the NDR itself rarely was generated with fraudulent headers. Other DSN's would be out of office replies, and other delivery status notifications that are incoming bound for one of our mailboxes. 

First, I'm just curious if SpamFilter checks incoming DSN emails using SPF logic. 

Here's the food for thought:

There also may be a future opportunity to use SPF to verify the DSN and block DSN's that were generated as the "result" of fraud.  This is a big problem on the Internet but get's sticky because first SpamFilter would have to recognize the incoming email as a DSN and then dig into the headers and message body to locate the original sender that generated the DSN and validate using SPF.  This would be way beyond the specifications for SPF but I think a really cool feature setting SpamFilter apart from the other solutions.

Matt,

SpamFilter ISP extracts the domain portion of the MAIL FROM address and performs an SPF check on it. Should that address be blank or not contain a domain, then SpamFilter will perform an SPF check on the FQDN taken from the HELO command. This behavior should follow the following recommendation from section 2.2.1 of the proposed RFC:

========================
     SMTP+SPF receivers MUST check the return-path unless HELO testing
     produced a "fail".  In this mode, the <responsible-sender> comes
     from the domain name of the "MAIL FROM" return-path.  When the
     return-path has no domain, a client MUST use the HELO domain
     instead.  If the HELO argument does not provide an FQDN, SPF
     processing terminates with "unknown".
===============================

Roberto F.
LogSat Software