In <408EB02F(_dot_)1040409(_at_)solidmatrix(_dot_)com> Yakov Shafranovich
<research(_at_)solidmatrix(_dot_)com> writes:
Hallam-Baker, Phillip wrote:
MARID is an authentication system (title mistake aside).
Access Control = Authenctication + Authorization.
Right. There's no authorization mechanism available yet for
Caller-ID, which is what I meant when I said I didn't see the value.
MARID, SPF and CallerID are composed in two parts
NORMATIVE: Syntax for describing outgoing edge MTAs
SUGGESTIVE: Rules for senders to interpret above
I don't believe that this group has any business telling receivers
what to do with the bits they receive. Hence I make zero distinction
between MARID, SPF and CallerID at the normative level beyond syntax.
I believe that this is the same thing that Andy was proposing.
Andy talked about algorithms. Or, at least he talked about selecting
an algorithm for RFC2822 stuff and I'm guessing that one of the
(closely related) LMAP algorithms would be used for the RFC2821 data.
I realize that receivers will do whatever it is they want to do.
However, I think it is important for domain owner to be able to assert
how they intend the data to be used and to be able to disavow other
uses of the data.
How many domain owners are going to feel comfortable publish MARID
records, knowing that the information will be used to accept or
reject their email, and yet give people free reign to do whatever they
want with the data? Sure, there will be email receivers who do really
strange things like use C-ID data to reject email based on the HELO
domain, even when the C-ID data says it is for testing only, but I
doubt many people will feel such use is appropriate.
When you are trying to resolve email deliverability problems, it is
really useful for the domain owner to point to an RFC and say "you
should be rejecting my email just because the References: header has a
domain in it that fails MARID validation". Maybe the email receiver
will change, maybe they won't, but they can't use open-ended
interpretations of MARID data as a valid reason.
This comes back to the subject of publishers specifying the
identities. If, from reading Andy's "toward a compromise" post, we
are going to be selecting algorithms, I think it is very important for
domain owners to either be able to select the identities, or maybe
better, to select the algorithms that they want the MARID data to be
used for.
Say we select the "DPX" algorithm for RFC2821 data, but we know that
it has problems working correctly in the very early hours of Tuesday
mornings. For the RFC2822 data, we select the "S/Call-Keys"
algorithm, even though it has a problem when people send email wearing
a tee-shirt. Some domain owners will say "I can deal with the
problems with DPX by not sending email during a few hours a week, but
the S/Call-Keys system is unacceptable". Another domain may have a
dress code that makes wearing a tee-shirt while sending email a
non-issue, but must be able to send 24/78.
Again, I think it is very important for domain owners to be able to
say when and how their MARID data can be validly used.
-wayne