spf-discuss
[Top] [All Lists]

RE: Email Forwarder's Protocol ( EFP )

2005-02-22 22:18:03
You said:

"when the recipient hits a "Reject as Spam" button.  That reject should be
treated as a "bounce" and follow authenticated addresses all the way back to
its source."

 

I disagree!

I could create "reject as" buttons all day.  "Reject as I don't like you any
more".  Should this also be treated as a bounce?

What about "delete since it is spam", or "delete because I just don't want
to read it".  Should these be treated as a bounce?

 

If a user makes the decision, no bounce.  But I do understand that an
automated system should send a bounce, otherwise if it was not spam, a
valuable email could be lost.  But a user pressing spam, trash or delete
takes the risk of losing a valuable email.

 

The user could use the "reply" button if needed!

 

Guy

 

  _____  

From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of David 
MacQuigg
Sent: Tuesday, February 22, 2005 5:28 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Email Forwarder's Protocol ( EFP )

 

At 09:55 PM 2/22/2005 +0000, you wrote:





On Tue, 22 Feb 2005, David MacQuigg wrote:

How do you currently handle soft fails?

The information just gets added to the Received-SPF header; other than
that, I do nothing with it. I think TEMP-failing goes a bit too far; all
softfail really means is: "If I had my SPF records/setup in order, this
mail would probably have to be REJECT-ted; but since I am not done
configuring yet, please do not take this result too seriously." So, I
don't. :) As Stuart said, the Bayesian filter will then read and interpret
the Received-SPF header.


This will work, but perhaps with some difficulty.  As long as you pass on
the essential information in a header ( protocol, IP address, domain-name,
result ), the receiver can figure out where to send the bounce, the
forwarder that gets the bounce can dig deeper into the headers and figure
out where to forward the bounce, etc.  The difficulty comes when your
receiver does not understand the Received-SPF header, because it doesn't
implement SPF.  A header with the items essential for any protocol in a
standard format would allow any receiver that follows the standard to
generate a bounce.

Are we in agreement that bounces may come *after* a forwarder's SMTP session
is closed?  To repeat my earlier statement:  A bounce might come as late as
several hours, when the recipient hits a "Reject as Spam" button.  That
reject should be treated as a "bounce" and follow authenticated addresses
all the way back to its source.

-- Dave




*************************************************************     *
* David MacQuigg, PhD              * email:  dmq at gain.com      *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *

  _____  

Sender Policy Framework: http://spf.pobox.com/ Archives at
http://archives.listbox.com/spf-discuss/current/ Read the whitepaper!
http://spf.pobox.com/whitepaper.pdf To unsubscribe, change your address, or
temporarily deactivate your subscription, please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com