On Tue, 2004-09-07 at 09:38, Yakov Shafranovich wrote:
Tony Finch wrote:
On Tue, 7 Sep 2004, Yakov Shafranovich wrote:
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.
This is also true for the PRA, since no existing MTAs add Resent-From:
header fields when alias-forwarding.
I think we are going in circles. Validating the bounce address only
prevents false bounces but allows phishing, validating "Sender" does not
stop phishing but allows bounces plus does not take into account
forwarding, validating the "from" headers stops phishing but allows
bounces. Which one of these do we really want?
Sender-ID is selecting a Mailbox Domain from a series of headers
considered related to the most recent MTA outside of the recipients
administrative region. Sender-ID header selection prioritizes RFC2822
From as _last_ in the selection process. This selection process
attempts to reduce rejection rates, but is no better at stopping
phishing as a result. At least using MAIL FROM, there will be a better
understanding which header is being inspected.
Rather than devising a scheme that can safely treat a relationship of
the MTA to Mailbox Domains for From and MAIL FROM as nominal lists, the
attempt to use these lists to also authorize the MTA creates
incompatibility and vulnerability to attack. Although these Mailbox
Domain lists may color mail with respect to certainty, they will remain
at a weak level of certainty, even after removing Mailbox Domain
portability. Tony was right in that Sender-ID can not identify forged
messages, nor can Sender-ID reliably identify valid messages.
The MTA must be authenticated independent of these nominal Mailbox
Domain lists in order to establish a reliable name for reputation
assertions. Another major benefit in isolating MTA authentication from
Mailbox Domain relationships, is that this greatly simplifies
associating Mailbox Domains with MTA servers. With an MTA name, an MTA
address list is not needed. With an MTA name, a secondary lookup for
addresses is not needed to validate the Mailbox Domain. With an MTA
name, these Mailbox Domain relationships can be expressed within a
single DNS lookup without the use of a text script!
By making MTA authentication independent of the Mailbox Domain
relationships, those wishing to retain their freedom in the use of their
return mailbox address will not impact MTA authentication and reputation
checks. Those not declaring these nominative lists to be comprehensive,
do not offer an avenue where "open-ended" records become exploited by
spammers.
A real danger with Sender-ID, in addition to making the MTA prone to
attack, is created by false expectations the headers are reliably
checked. This will only lead spammers to exploit the many Sender-ID
weaknesses. What is needed is a lightweight method of authenticating
the MTA, where other relationships are then established upon this
relatively solid foundation. Sender-ID does not offer a suitable
foundation, as it is premised upon the integrity of the RFC2822
information which can not be verified. If there is a problem, Sender-ID
fails to isolate the source of the problem. If there is a problem,
Sender-ID may mis-identify the sender and cause serious harm.
-Doug