On Thu, 2004-08-19 at 11:13, Alan DeKok wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
I agree. It's only hop-by-hop accountability.
With Sender-ID, EHLO and MAIL FROM are ignored. Sender-ID has no
concept of the hop,
It's applied by MTA's, which do have the concept of a hop.
Perhaps one could describe the PRA algorithm as the MTA considering
prior hops, when the accountable identity is deciphered. If an
unchanged message is passed from MTA to MTA into a prescribed channel
(merged-open set), the evaluation of this identity may be promoted, as
Sender-ID does not consider messages passing through a chain of MTAs of
differing acceptance levels. With respect to Sender-ID, there is no
acceptance state at each hop being relayed. This information is being
With Sender-ID, the accountable entity is based solely upon RFC2822
message content, this may change at each hop when a header is added,
this entity may or not be checked against Sender-ID records at various
MTAs, and the accountable levels for the entity may erroneously
increase. Although there may be _some_ notion of a hop within
Sender-ID, Sender-ID seems to assume communications are end-to-end for
the purpose of reputation, with the exception of added sending headers.
With Sender-ID, the entity accountable for traffic emerging from a hop
is _not_ identified.
The PRA of the traffic is identified, who may not be the same as the
MTA client originating the traffic for the current SMTP session.
The PRA may have been outside the prescribed mail channel initially, but
this information is lost when transferring through a chain of MTAs. The
Purported Responsible Address offers no assurance nor tracks any level
of responsibility. This mnemonic should refer to Purported Recent
CSV, however, clearly identifies this entity and thus provides an
identity that may safely be held accountable.
It uses different fields to hold a different entity accountable for
CSV attempts to hold the accountable entity accountable for the mail
sent. There is nothing definite that could be said of Sender-ID. :)
CSV is very different from Sender-ID in that regard. It seems we agree
on major points, so I am confused how you can hold this view.
The paradigm change to hold entities responsible for SMTP traffic is
the same in both proposals. The fields they use, and the
Previously, recipient MTA's had to determine the responsible
entitity by making reasonable implications, which may or not not have
been correct. The proposals here in MARID allow entities to
explicitly state who is to be help accountable.
Sender-ID however does not offer an effective protection in this
area, while it breaks much of the current mail, hammers DNS, and
ignores UDP back-off requirements.
I'm not sure I agree with all that, but I do agree that other
systems within the MARID scope may achieve the MARID goals with less
I would be happy to review these other points. :)