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>
|
|