In the case of DSN the SPF lookup should be done on the domain in the HELO command.  I have not come up with a way to test this, so I thought I would just ask. Is this implemented in SpamFilter at this time?  Thanks!

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?

Sorry Dan. I'm referring to Delivery Status Notification (DSN)'s. 

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) :

"...

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.
..."

 

 

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.