--Jon Kyme <jrk(_at_)merseymail(_dot_)com> wrote:
I can't see any sensible way of doing this without the publisher being
able to indicate the intended applicability of the record.
Hey John,
I think you said that before, but I posted my "suggested workarounds" and
nobody has responded to say why those wouldn't work. Do you have some
situations (real or hypothetical) that might demonstrate why this extra
"applicability info" would be needed, and why the workarounds I posted
wouldn't work?
I get the feeling that people are just replying "No it won't work" and
not
taking the time to read the suggestions I have made or respond to them.
So
far I haven't seen any specific reasons why the single-record-per-domain
wouldn't work, or why the workarounds suggested wouldn't work. This makes
me a little frustrated.
Yes, I appreciate that.
You propose that the default should be "all contexts".
"Context workaround 1" seems to be a requirement only to make the record
wide (enough).
I don't understand "workaround 2". It doesn't seem to add anything.
"Each context stands alone" seems to me to be what a recipient MUST do. It
seems clear that I (as a recipient) MUST NOT pick a domain from 2822 From
and evaluate the message as if I'd got the domain from 2821 MAIL FROM.
"Special cases modifiers" is, of course what I, and others, have suggested.
So, pending me figuring out what "workaround 2" means, and pending us
deciding what the default should be, what you propose is exactly equivalent
to what was suggested.
I think the important thing to be clear on is what the MARID record
actually is. One view is that it's a publishers statement of what
legitimate claims for the domain are allowed. Obviously, a little language
should be as little as possible, but it also needs needs to be powerful
enough to satisfy requirements. A publisher should be able to say what they
mean, explicitly. The advantage I see with "modifiers" over "widening" is
that it is more explicit. There's a small penalty in parsing I guess.
Rgds,
Jon Kyme
o "Context workaround 1" If the same domain might be used differently,
meaning different sets of MTAs are allowed to use the domain for MAIL FROM
than for From:/Sender:, the domain owner must ensure that the published
LMAP inforamtion is inclusive enough to allow ALL possible uses of that
domain. If a given MTA will use the domain in one context but not another,
domain owner will list it as "allowed" and work with the operator of that
MTA to make sure they use the domain in the desired way.
o "Context workaround 2" This policy does not preclude senders from
using different domains in MAIL FROM, HELO, or From:/Sender: -- in fact,
some senders may choose to use different domains (or subdomains) in MAIL
FROM and From:/Sender: in cases where they are not able to create one
specification that covers uses in all LMAP contexts. This is also the only
reliable way to "opt out" of checking in one context or another (i.e. by
using a protected domain in one context and an unprotected domain in
another).
o "Each context stands alone" Receivers SHOULD apply LMAP info for a
domain in the context where it is used, and MAY NOT apply LMAP info for
another domain when it is not used in that context. For example, if the
domain "bounces.example.com" is given in MAIL FROM, and "example.com" is
given as From: or Sender:, the receiver will check MAIL FROM against
bounces.example.com's listed info and From: or Sender: against
example.com's listed info, and is not allowed to apply either domain's info
against other places in the message where it is not actually used. (The
policy for a domain does not automatically apply to all its subdomains)
o "Special cases modifiers" IF there is a need for it we might
consider modifiers or keywords that the domain owner can set, to express a
preference for "opting out" of MAIL FROM, HELO, or From:/Sender: checks, or
to direct the receiver to a different LMAP info record for different types
of checks. We should ONLY go down this path if there is a REAL WORLD usage
case that is NOT covered by workaround 1 or 2.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>