Re: towards a compromise

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