ietf-mxcomp
[Top] [All Lists]

Re: TECH OMISSION: Stronger checks against email forgery

2004-09-07 07:35:03


 "Yakov Shafranovich" commented:

Tony Finch wrote:

On Fri, 27 Aug 2004, Jim Lyon wrote:

I continue to disagree.  There are too many scenarios where the bounce
address is uncorrelated with the MTA that's delivering a message; this
means that any scheme that attempts to reject mail based on those two
inputs (bounce address and IP addr of sending MTA) will have too many
false rejections.


What makes the PRA different from the bounce address from this point of
view?


The PRA algorithm tries to guess the most recent "Sender" for the
message - i.e. the one that is being used for this SMTP hop. The bounce
address on the other hand originates from the original hop and stays
that way throughout multiple SMTP hops.

Two related points I want to stress as well:
1. The verification is no longer being done on bounce address, that
would mean that domains are not protected from bounces. In a case where
multiple SMTP hops take place with non-compliant MTAs, and the last hop
using a compliant MTA, the bounces will be directed to the original
domain, even though it is using Sender ID.


Or directed to whatever address was given in the Mail-From (which need not be
related to the actual origin of the message). It could be intended that the
bounce (perhaps with malicious content) be sent to the 'victim' identified in
the Mail-From, and an additional 'benefit' of the intentional bounce is that the
reputation of the 'final hop', Sender-ID-compliant node, or of the one before
it, might thereby be damaged.


2. The "Sender" header is being verified over the "From" header. While
according to the RFC that is the agent introducing the message into the
email system, the "Sender" header is not displayed in MUAs. Therefore,
in a compliant MTA but non-compliant MUA, it is still possible to fool
the system by using a valid "Sender" header with fake "From" headers.

Yakov




Chris Haynes