ietf-mxcomp
[Top] [All Lists]

RE: TECH-ERROR/DOC-BUG: empty fields in -pra

2004-09-06 04:27:22

-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Graham 
Murray
Sent: Monday, September 06, 2004 12:51 AM
To: ietf-mxcomp(_at_)imc(_dot_)org
Subject: Re: TECH-ERROR/DOC-BUG: empty fields in -pra



Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> writes:

Graham Murray wrote:

Roy Badami <roy(_at_)gnomon(_dot_)org(_dot_)uk> writes:

The effect of this is that even if the users MUA is Sender
ID aware,
and displays the PRA, there's no guarantee it is
displaying the same
identity that was validated by the MTA.
Which is why it would be better for the MTA to create a header to
inform the MUA of the PRA and for the MUA to display that. If this
were done then it would be necessary to specify that the MTA MUST
remove any such headers already in the mail.


This would be a problem with multi-hop forwarders.

Why? Sender-ID only authenticates the last hop anyway, so the PRA
which the MUA would derive should always be the same as that derived
and validated by the last MTA handling the email.

The header fields are there for a reason, its an inline log of the email to 
assist mail
administrators to diagnose email issues (not just forgery/phishing, but also 
routing issues,
secondary MX issues, etc).  (Or allow skilled email users to analyze validity 
of incoming mail).

Suppressing this type of information is unacceptable to me, and my admins who 
are told to look at
the headers BEFORE calling support.

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
terry(_at_)greatgulfhomes(_dot_)com
Fax: (416) 441-9085