|
Re: towards a compromise
2004-04-22 17:51:31
--John Leslie <john(_at_)jlc(_dot_)net> wrote:
Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:
The current task of this working group is to pick the identity on which
^^^^^^^^
s/identity/identity or identities/
Refer to our charter if necessary:
http://www.ietf.org/html.charters/marid-charter.html
I agree, though the word "identity" is thrown around a lot and I don't
think in this context it means what everyone thinks it means.
For now I'm going to assume that "identity" means "data point" and not much
more.
There have been strong arguments for each of these and even arguments
for including all of them.
Indeed: I find the "all of them" arguments most convincing.
(Disclaimer: I wrote one of those myself.)
Yes. I am on board with the "all of them" idea as well.
o Since interpretation of the identity is up to the receiver, the
sender will not state the type of the identity.
This is a bad idea. (It makes it even more likely Andrew is proposing
something non-extensible.)
There are three very different meanings for authorizing the HELO, the
RFC2821-MAIL-FROM, and the various RFC2822 headers.
OK, I think I either disagree with this or I don't understand it well
enough. So, let me ask some leading questions and get your feedback.
My thought (which I touched on in a previous message) is this: The basic
unit of measurement, the fundamental unit of work that LMAP wants to get
done, is to establish a link between "your domain" and "MTAs authorized to
use the domain". The two items to be related are domain names, and MTAs
(IPs, in the simplest case) and the relationship is going to be something
like "MTA X is authorized to use domain Y".
This assumption is rather fundamental to the arguments I am making, so let
me know if there's something you don't agree with there... if so the rest
of this message may be moot.
Authorizing the HELO means that the domain (or ISP operating the
network) directly controls the particular MTA, and claims to respond
to reports of errors or misuse.
Authorizing the RFC2821-MAIL-FROM means that the operators of the
domain have taken reasonable precautions to ensure that this email
address -- when used in RFC2821-MAIL-FROM by the particular MTA --
accurately represents the proper bounce address; and that they claim
to respond to reports of its misuse.
Authorizing the RFC2822 headers is still a bit murky, and we haven't
fleshed out the exact meaning of that.
So, the basic concept of "MTA X is authorized to use domain Y" could be
extended to cover all three of these cases.
Usually the HELO name is different from the domain in the MAIL FROM, and
usually the MAIL FROM is the same as From:/Sender:/misc 2822. So the HELO
case is pretty easy, it is a different domain so it can have a different
allow list (usually "MTA mail1.example.com is allowed to use HELO name
mail1.example.com"). If the same name is used in HELO and in MAIL FROM (or
From:) then it's probably a message generated by your mail server and then
it becomes pretty clear which MTA is authorized to send the mail. :) But
if other MTAs might also handle the DSN or other server-generated message
on the way out, just add them to the list like you would for any other RHS
domain argument.
Moving on to MAIL FROM vs. From:/Sender: IF the basic thing we're saying
is "MTA X is authorized to use domain Y", and the receiver may check either
MAIL FROM or From:/Sender: then this is where (you claim) there might be
different meanings to using the data in a 2821 or 2822 context. So my
questions in response to that are:
1. Are there really any situations where you want to use the *same* domain
name in both contexts AND you want to supply *different* data to the
2821.MAIL FROM checker than to the 2822.From:/Sender: checker? Or cases
where you want either of 2821/2822 checking but not both, for the same
domain name?
2. For cases where you might use the same domain in different ways, and the
list of MTAs might be different for 2821 vs. 2822 checking, can you get
around this by listing a superset (all possible MTAs in both contexts) for
that domain? (What's a real-world example of when this wouldn't be
possible? Isn't this an extremely rare case to begin with?)
3. If you can't come up with a complete list of all MTAs that *might* use
your same domain name, suitable for checking either MAIL FROM or
From:/Sender:, would you be content with a workaround of using different
domains in each context? (For example, if the From: is something(_at_)jlc(_dot_)net
and the MAIL FROM is bounces.jlc.net, different sets of MTAs are possible)
The sender will simply state the identity, and the receiver will judge
it as 2821 or 2822 depending on need.
Aside: I fully admit the receiver is going to do whatever it wants
regardless of what we say. :^(
I know I have stated quite clearly that not every domain will want
to signal their policies on RFC2822 headers; and I sincerely hope it's
obvious that different domains will want to signal different policies.
What I am trying to steer away from is the need to state "Here is my 2821
info" and "Here is my 2822 info" (or even "Here is my HELO info" and "Here
is my MAIL FROM info") when 99% of the time they will be the same list.
Which is why I'm asking for more info. Does "different domains will want
to signal different policies" also mean "The SAME domain will want to
signal two different policies"?
I am not sure if the issue really is "They might not be the same list" or
if it really comes down to "I want to be able to keep the receiver from
checking one or the other".
<snip details>
o This does not preclude any other statements the sender may make
regarding the domain identity, such as 'noForwardingFromThisDomain'
etc..., nor make any assumptions regarding the format of the MARID RR.
This is more encouraging: Andrew is at least leaving room for
expansion.
(Indeed, if Andrew's proposal served to sneak this past Ted, we
could go ahead and define separate "extensions" for HELO, MAIL-FROM,
and each RFC2822 header to accomplish what we need. ;^)
That's actually a good suggestion for a possible alternative... If the 3+
different policies that you want to state are actually different, that's
harder... but if you just want to signal to receivers that you want to opt
out of one kind of checking or the other, a keyword or modifier could do
that.
(Again, my guess is that 99% of people publishing their info want to 1.
protect their domain name in ANY context, and 2. use the same policy for
all checks. So my hope is that we can make things easiest for the 99% case
and a bit harder for the 1% case, rather than complicated all the time.)
Operationally, we have a pressing need to know _whether_ the domain
or network intends to vouch for the RFC2821-MAIL-FROM bounce address.
We emphatically should not settle for ambiguity on that issue.
I agree with the need, but I can see how some domain owners might want to
use a "fallback to unknown" state (?all) especially for early adoption.
There is still some benefit to knowing the "known good" MTAs even if you
can't totally rule out all other MTAs as "known bad". The goal should be
to get everyone to either known good or known bad lists... eventually.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
|
|