Re: towards a compromise
2004-04-21 21:17:42
--Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:
The MARID identity will be both a 2821 identity and a 2822 identity in
the following manner:
o Since interpretation of the identity is up to the receiver, the
sender will not state the type of the identity. The sender will simply
state the identity, and the receiver will judge it as 2821 or 2822
depending on need.
OK, some folks may see this as a weakness, but I see it as a strength. By
that I mean specifically that I want to protect my domain name when it is
used in MAIL FROM (to send me bounced-forged mail) AND when used in From:
or its relatives (to impersonate me and earn me negative replies from real
people). AND, I feel strongly that I should be using the same mechanism to
do it, rather than setting a 2821 and 2822 policy two different ways.
There have been objections similar to, "Oh my, but that means we don't know
if the receiver will check 2821 or 2822 and in general what they will do."
Let me say the following regarding this line of reasoning. Yes, you want
to be able to predict what the receiver will do, but in most cases I think
we will be able to predict it and deal with it.
Consider these cases:
1. Single domain, single policy
I want to protect my domain.
I use the domain as a 2821 return path and 2822 From: address.
My MTAs will be the same in 2821 and 2822 context.
I publish the LMAP info, and it can be used in either context.
2. Dual domain, dual policy
I want to protect my domain.
I use one domain as my 2821 return path and another as 2822: From address.
Sending MTAs are usually the same, but I may use different subsets for
different purposes. When I do, I will make sure the sending MTA of any
given message is permitted by both the 2821 return path domain and the 2822
From: address.
I publish LMAP info for any domain I use as 2821 or 2822, and receivers
will validate 2821 info against MAIL FROM and 2822 info against From:
3. Single domain, dual policy
I want to protect my domain.
I may want to use my domain in a 2821 or 2822 context, but my published
policy may be applicable to one and not the other.
I am a bit screwed because I don't know if the receiver will check 2821,
2822, both, or neither.
Domain owners in situation 3. have these choices: use the same (possibly
wider) policy for 2821 and 2822, switch to using different domains for
return path, or don't state a policy for that domain.
Frankly, I can't actually think of a case where you want to use the same
domain in 2821 and 2822 contexts, AND you have different policies for each
usage, AND you can't state that policy in a general way. Usually, in my
experience, a domain owner who is using the same domain in 2821 and 2822
identites is also using the same set of MTAs to send their messages (i.e.
you can't send a message with only 2821 identities and send the 2822
headers from another MTA :)
If you really want to force the receiver to use 2821 and not 2822 checking,
or vice versa, I think you could accomplish that by using two different
domains.
In other words, if we agree that both 2821 and 2822 are important, and that
most domain owners will publish near-identical policies for both, perhaps
we can optimize for that case, and domains that want to do something
strange can use two different names or opt out of any protection until they
can get things arranged.
o For 2821, we will either pick HELO or MAIL FROM, but not both as
they have different meaning. In the case of a null MAIL FROM, the
receiver has the choice to abandon the MARID check or drop back to 2822
checking.
This is a little odd, and I'm not sure if I understand it. But, I think
HELO and MAIL FROM checking are compatible with each other, for the same
reasons mentioned above... they just do two different things. (i.e.
usually the HELO name is different from the domain in the MAIL FROM
address, so again, each can be checked against its own DNS entry)
MAIL FROM checking is important so that I don't get bounces from mail I
didn't actually send. HELO checking is not as important, but some domain
owners don't want their domains used as fake HELO values and we can
accomplish that pretty easily.
So how about this proposed language to replace the above paragraph:
o For 2821, MAIL FROM will be checked against its domain. In the case
of MAIL FROM: <>, check the MTA authorization using the same logic as MAIL
FROM: <postmaster(_at_)HELO>. Because HELO name is used sometimes as a fallback
(i.e. for DSN messages) it is expected to have sensible LMAP info of its
own, and any name used as a HELO (usually the FQDN of your mail servers) is
either used consistently with its LMAP info or will have no LMAP info
associated with it. Some recipients may choose to check the HELO name all
the time, not just on MAIL FROM: <>.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
|
|