On 5/12/04 at 2:21 PM -0400, John Leslie wrote:
MAIL-FROM does not mean that the email "purports to be from"
that domain.
As I said to Dave, I don't think it does and that was not the
intention. I will rewrite without using those words if folks continue
to find this too confusing.
I get confused by talk of Mail-From, to me that would logicaly be
2822-From.
2821 From is not seen by anything other than the mail infrastructure.
The meaning is given by the use made of it by applications. In
this case the meaning appears to be 'bounce mail to this address'.
I think it is a pretty good and pretty safe option to say, do not
bounce mail to a 2821-From address that fails MARID testing. Worst
case is some mail gets silently dropped, nothing new there. Bounces
have never been reliable indicators of non-delivery.
The meaning of 2822 from is completely different. It is seen by
real humans, not just applications and not just geeks. The meaning
of that header line should be made honest.
The DNS is not exactly set up to handle a tuple query (i.e., query a
domain-name/ip-address pair to get an answer). I'm suspicious about
whether this is workable.
The DNS can be abused in lots of ways. You can make any simple
round trip protocol to look like anything else. You could run
DNS over HTTP if you choose, or HTTP over DNS. That does not
make it a good choice to do so.
Ont of the two boundaries I think are important are the scope of
the typical DNS admininstrator's responsibilities. These tend to be
network oriented and only in small shops user/people oriented.
Trying to give DNS servers per-user responsibility that would
effectively turn them into an X.500 directory lite is a bad idea.
The other boundary is related, when we move from quasi-static to
fully dynamic data. It is easy to do a DNS 'name hack' on one server.
Distributing that data to a cluster or in the case of ATLAS a
constellation is a completely different matter.
We went through this with PKI and ideas about putting certs and
end user keys into the DNS. Much, much better to handle that type
of task by a dedicated lookup protocol that is DISCOVERED via
the DNS (i.e. NAPTR, SRV).
That particular type of hack is very different from protocol
related naming hacks as SRV uses. I think that the SRV 'name hack'
is exactly the right thing to do. I would like to use it even
if we end up with a separate record. This is because every time
we do a one off record for mail like MX we inevitably end up
writing another for general protocol use (SRV).
What we are writing here is directly equivalent to the
WS-SecurityPolicy layer of Web Services Security. Its the
way to obtain the security credentials of the thing you are
either connecting to or getting a connection request from.
Phill