ietf-smtp
[Top] [All Lists]

Re: New Authenticated: header?

2005-03-09 16:25:35

At 04:18 PM 3/9/2005 -0500, John Leslie wrote:

David MacQuigg <dmq(_at_)gain(_dot_)com> wrote:
>
> See my "Spam Scenarios" at
> http://www.ece.arizona.edu/~edatools/etc/

   David introduces an interesting idea there: interspersing "Authenticated:"
headers among the "Received:" headers:
]
] Received: ( **SaniMail 47655 invoked from network** ); 28 Feb 2005
]         15:35:36 -0000
] Authenticated: 208.210.124.73 pobox.com SenderID PASS
] Received: from unknown (HELO gold.pobox.com) (208.210.124.73)
]         by mail5.mailsystem.us with SMTP; 28 Feb 2005 15:35:36 -0000

   I think it would work better as
"
" Authentication: <method> (<parameters>) = <result>

but it's the _idea_ that I find interesting, not the syntax.

Here is a better statement of the "idea" ( from http://www.ece.arizona.edu/~edatools/etc/Email%20Forwarding%20Protocol.htm ).
Fundamental Requirements:
5) If the message is forwarded, the results of authentication must be made
available to all subsequent receiving MTAs.  The format should be simple and
standardized to facilitate later blocking and filtering.

I don't want to get too far into the implementation suggestions until we have a consensus on the fundamental requirement.

If there were a header prepended at the time Authentication is done,
it would make it possible to use its result as input to (possibly
heuristic) filtering executed later; and _might_ open the door to a
future in which a limited trust could be given to Received: lines after
the first.

Exactly. Given the prevalence of forwarders, extending the "boundary of trust" by at least one hop will be essential to success of SPF. I'm surprised they haven't addressed this issue in their draft. SenderID probably has some patented way to do it. DomainKeys bypasses the problem by going end-to-end.

-- Dave


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