|
Re: towards a compromise
2004-04-22 22:50:00
Hi Margaret.
I think I agree with most of what you have said. But, I want to be quite
clear on this point, so I will ask explicitly: Did you *disagree* with
anything *I* said?
See below for comments and (mostly) requests for clarification...
--Margaret Olson <molson(_at_)roving(_dot_)com> wrote:
On 4/22/04 8:51 PM, "Greg Connor" <gconnor(_at_)nekodojo(_dot_)org> wrote:
So, the basic concept of "MTA X is authorized to use domain Y" could be
extended to cover all three of these cases.
Usually the HELO name is different from the domain in the MAIL FROM, and
usually the MAIL FROM is the same as From:/Sender:/misc 2822. So the
HELO case is pretty easy, it is a different domain so it can have a
different allow list (usually "MTA mail1.example.com is allowed to use
HELO name mail1.example.com"). If the same name is used in HELO and in
MAIL FROM (or From:) then it's probably a message generated by your mail
server and then it becomes pretty clear which MTA is authorized to send
the mail. :) But if other MTAs might also handle the DSN or other
server-generated message on the way out, just add them to the list like
you would for any other RHS domain argument.
The MAIL FROM is frequently not the same as the 2822 from for mail sent
via email service providers or mail generated by applications. In those
cases the 2821 MAIL FROM may be the application or service provider, which
programmatically handles bounces and other errors, while the 2822 from is
the person responsible for the content. This is not always the case; there
is a wide variety of approaches to setting the 2821 from, but it's
frequent enough that the word "usually" gives me pause.
The bit you quoted was all about HELO, but your reply here just mentions
MAIL FROM. So I'm assuming you are referring to the first sentence where I
used "usually" twice and not referring to HELO. Right?
Anyway I agree with your statement. The "often" or "typical" case of
personal email is that the return path and the From: address are the same.
There are enough cases where they are not the same to make it important to
deal with and one should not assume.
My point here was:
1. HELO names are USUALLY NOT in conflict with other domains in the
message
2. If there is going to be conflict (meaning two identities using the
same domain and expecting different treatment, it will probably be MAIL
FROM and From:/Sender:
So... that was what I was trying to focus on below... Since I think we are
in agreement here I will move on but let me know if I missed something
subtle (other than mild objection to the use of "usually" :)
Moving on to MAIL FROM vs. From:/Sender: IF the basic thing we're saying
is "MTA X is authorized to use domain Y", and the receiver may check
either MAIL FROM or From:/Sender: then this is where (you claim) there
might be different meanings to using the data in a 2821 or 2822 context.
So my questions in response to that are:
1. Are there really any situations where you want to use the *same*
domain name in both contexts AND you want to supply *different* data to
the 2821.MAIL FROM checker than to the 2822.From:/Sender: checker? Or
cases where you want either of 2821/2822 checking but not both, for the
same domain name?
......
3. If you can't come up with a complete list of all MTAs that *might* use
your same domain name, suitable for checking either MAIL FROM or
From:/Sender:, would you be content with a workaround of using different
domains in each context? (For example, if the From: is
something(_at_)jlc(_dot_)net
and the MAIL FROM is bounces.jlc.net, different sets of MTAs are
possible)
Domains are brands. You can create arbitrary sub-domains for purely
technical purposes, but creating them in a way that is visible to users
runs into all kinds of brand control issues. So I think here the answer
is yes, you can create a sub-domain for the 2821 from or the HELO. (Yes,
an end user can look at the 2821 if they know how, but most won't and it
will not be an issue).
Excellent! This is what I like to hear. I really believe that very very
few domain owners will want to assert different policies for the SAME
domain, depending on whether it is being used as a 2821.HELO, 2821.MAIL
FROM or 2822.From:/Sender: name. For those few cases where the domain
owner wants different policies, I hope that using different names is a
reasonably easy workaround.
What I am trying to steer away from is the need to state "Here is my 2821
info" and "Here is my 2822 info" (or even "Here is my HELO info" and
"Here is my MAIL FROM info") when 99% of the time they will be the same
list.
Which is why I'm asking for more info. Does "different domains will want
to signal different policies" also mean "The SAME domain will want to
signal two different policies"?
At some level the answer is yes, in that organizations that provide email
services today may use the same domain name for both corporate mail (2822)
and as part of the service (2821), and have different rules for each use
of the domain. Constantcontact.com does this to some degree, but I can't
think of a compelling reason to preserve this option. I have to think it
only affects people providing various kinds of email services, and a
subset of them at that, and this is a group that is not all that big and
plenty able to make this kind of minor change.
I don't quite understand the association you are making where corporate
mail is 2822 and part of a commercial service is 2821. Every message will
have a 2821 and 2822 parts. If they are different (like when a third party
sends in your name and processes the returns for you), having different
policies is no problem (so I kind of glossed over that case). If they are
the same, I still don't see why you would want to assert two different
policies for the same domain.
I'm not familiar with constantcontact.com, but the idea seems to be that
corporate mail (from employees sent individually) might take a different
path from service mail (sent by a server and not manually addressed by an
employee). But, here is the important thing: Some messages *WILL* have the
same domain mentioned in both 2821 and 2822 parts, so even if you've only
sent one message from one employee, you are already committed to having the
2821 and 2822 parts somewhat compatible. I truly cannot think of a reason
you would want to use a domain as ONLY a 2821 MAIL FROM for one message,
and then turn around and use it ONLY as a 2822 domain in a different
message.
Anyway... I think we are in agreement here, so I certainly don't mean this
as a challenge or attack... I am pleased to see feedback saying that if
there are conflicts, they should be got around easily.
I am not sure if the issue really is "They might not be the same list" or
if it really comes down to "I want to be able to keep the receiver from
checking one or the other".
I concur with Phill's assessment that the receiver is going to do what the
receiver is going to do. However, it is useful to tell the receiver what
the intended use of the domain is. It gives the receiver a strong hint
about what to check, and in and of itself communicates useful information.
Right. I guess that comes back to my point which was, the sender has total
control over when to use a domain in one context or the other. If the
domain owner wants to have a published policy used ONLY for 2821 or ONLY
for 2822, he is free to use the domain ONLY in MAIL FROM and not in the
headers, or vice versa.
If someone is *really* a control freak, and wants to be able to 100%
reliably steer the receiver in one direction or another, using two
different domains is really the way to go.
I can see that some members here *really* want to be able to include some
tags that say "Don't do 2821 checking" or "Don't do 2822 checking". I'm
not really against this, but I *STILL* have not seen a real-world example
of why this might be needed (or even a hypothetical example).
(Again, my guess is that 99% of people publishing their info want to 1.
protect their domain name in ANY context, and 2. use the same policy for
all checks. So my hope is that we can make things easiest for the 99%
case and a bit harder for the 1% case, rather than complicated all the
time.)
A large percentage commercial organizations, and here I'm including all
the pseudo-commercial organizations - non-profits and other associations
- use at least one sending service outside of their direct control. And
perhaps not intuitively, the smaller and less technically savvy they are
the more likely they are to have multiple, unrelated services each
providing some relatively narrow function. Imagine a small business with
a shopping cart with order confirmations from vendor a, email marketing
from vendor b, and corporate person to person mail from the local ISP.
I don't have a good feel for how widespread all the rich variations
possible on the use in 2821 and 2822 of the four domains in this scenario
is, but while it's probably correct to assume that most person to person
*email* has the same 2821 and 2822, it is pretty risky to assume that
most *domains* send only mail with the same value for 2821 and 2822.
All that being said, it should be possible to express "mail with a 2822
from of my domain comes only from my servers".
OK I think we are in agreement here too. Again, I am not objecting to
using the same domain for different purposes. What I'm really puzzled
about is why you would want to use the same domain for different purposes
AND expect different treatment for the same domain at different times. The
most reliable way to get different treatment is to use different domains.
In other words, I am certainly *NOT* assuming that domains will send only
mail with the same 2821 and 2822. If they are not the same domain, that's
great, we're home free. If they *DO* choose to use the same domain for
both 2821 and 2822, I expect them to make a policy statement for that
domain that can be used in both contexts.
Thanks,
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
|
|