On Wed, 2004-07-28 at 15:13, Andrew Newton wrote:
On Jul 28, 2004, at 5:47 PM, Alan DeKok wrote:
I think Doug's point is more that information necessary for the MX
to implement Sender-ID isn't distributed, but the incoming mail is.
I understand this point. I just don't think it is valid because it
assumes that the "To:" identity (either 2821 or 2822) is part of the
Sender-ID (or SPF) equation. Why does an MTA need to know the "To" in
order to check the "From"?
Sender-ID checks the Purported Responsible Address (PRA) and may not
include the RFC 2822 From. Sender-ID does not check the RFC 2821 RCPT
TO or the RFC 2822 To. Such checks are done independently.
The scenario described was to illustrate a generation of a bounce
(resending of the message to the RFC 2821 MAIL FROM) rather than an
immediate message rejection with a 5xx error. The bounce occurs, in
this case, when the mail is being relayed by an MTA that does not have a
list of valid users, but is only checking the right hand side of the RFC
2821 RCPT TO address. If the message is initially accepted and then the
user is later discovered not valid, the message becomes bounced.
Acceptance does not require a full rating from Sender-ID, and may not
include a full set of other checks at that time. Sender-ID acceptance
could be achieved using a domain with either none, open, owned, or
borrowed records. A relay MTA may also opt to turn off Sender-ID
channel checks. The bounce can emerge with a high Sender-ID rating
however. If just the RFC 2822 From is used in the spoof, then the
bouncer becomes the PRA. If the RFC 2821 is not null in the bounce,
then this would appear to originate from the bouncer. (Some virus
filters seemingly want to advertise their post acceptance detection and
put something in RFC 2821 MAIL FROM bounce. Bet such companies will use
'open' records. Often the virus reported is listed on their website as
known to spoof the RFC 2821 MAIL FROM, and so they pass it along, like a
cat showing their prey.)
The 'reverse path' declarations needed for Sender-ID are not always
comprehensive, due to the extremely large scope involved. There will
remain a population of 'open' records. With the expense of DNS
wrenches, as a defensive posture, such Sender-ID checks could be
postponed until it is determined the mail is for a valid user. Owing to
the overhead involved, Sender-ID checks could be reserved to benefit
just local users.
-Doug