ietf-mxcomp
[Top] [All Lists]

Applying LMAP info in any context

2004-04-24 11:30:34

"Olson, Margaret" <molson(_at_)constantcontact(_dot_)com> writes:

[...]                      In other words, there are domains that are
valid in the 2821 from but never valid in the 2822 from.

--wayne <wayne(_at_)midwestcs(_dot_)com> wrote:

So, it appears that you are saying that there is a need for a separate
policy document for RFC2821 and RFC2822 data.



Not necessarily... most senders in this situation could probably come up with a "complementary" policy that covers both cases.

Margaret's example:
 2821.MAIL FROM = in.constantcontact.com => permitted from trusted servers
 2822.From:     = in.constantcontact.com => not permitted

Slight variation
2821.MAIL FROM = in.constantcontact.com => permitted from trusted servers or not at all 2822.From: = in.constantcontact.com => permitted from trusted servers or not at all


Based on Margaret's messages (and John L. as well) I'm assuming that the whole thread about "Oh no, we have to be able to publish separate policies for the same name" is based on the following: 1. Wanting to control whether the receiver uses 2821, 2822 or both (even if the sending MTAs might be the same) 2. Confusing "I want two different domains per message" with "I want two policies for the same domain" I believe objections raised so far are NOT based on any actual need to state *different* LMAP info for the *same* domain.

I still think that it's important to state one policy for both for 99% of domains. In other words, for MY domain, I want ALL protection available, and I don't want to do extra steps to opt-in to MAIL FROM/HELO/Header checks.

So I propose the following (apologies if I'm repeating some of what Andy posted)

o "LMAP applies in all contexts" The LMAP information for a domain is a specification of which MTAs are allowed to use the name. It is *assumed* to apply to any of HELO, MAIL FROM, From:/Sender: as the receiver finds appropriate. It is not necessary to publish different policies for different functions. The LMAP information applies to a domain name, and *any* use of that name, not to a specific context.

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>