On Mon, 2004-09-13 at 05:31 -0700, william(at)elan.net wrote:
Additionally Received header are specially designated to be trace fields,
so they are like a loggin info.
That's all they are here, surely? In a world where SenderID was
ubiquitous you'd have mail servers automatically rewriting RFC2821 and
RFC2822 identities on outgoing mail, and the SenderID validates _only_
that one hop; it's not end-to-end validation such as PGP, DomainKeys or
Signed Envelope Senders would offer.
You end up using a domain-based blacklist instead of the IP-address-
based blacklists which are already common, but other than that the
problem hasn't changed much. It's just a way of determining which are
legitimate mail servers, and which are not.
The information as to the 'purported responsible' domain in each hop
really is just trace info which is of little importance after the fact.
A sending mail server can choose any 'domain' it likes when modifying
the mail it sends, as long as its IP address is designed as one of the
permitted addresses for the 'domain'. The domain used doesn't have to be
the same for all outgoing mail, and doesn't have to bear any relation to
any domain name you'll actually see or use in your interaction with your
email client. It's _purely_ a lookup key for your trust database or
blacklist, and could be considered just that -- an arbitrary key. Mail
forwarded by pobox.com uses 'bounce2.pobox.com' for example.
Incidentally, once we realise that it's _just_ a single hop we're
validating, and that the key is essentially arbitrary, the whole problem
we're trying to solve can be seen in a different light.
All we're doing is offering a way for sending mail hosts to offer an
arbitrary 'trust key' of their choice, which the recipient can then look
up in a database.
As long as there's a way of checking that the host in question really is
an authorised user of that 'trust key' it doesn't matter _what_ it is.
For example, we could use signatures on TLS certificates. A listing in
the database could be keyed on the _signatures_ on the cert which is
presented by the sending mail host -- so the database lookup could
result in a trust level (or a blacklist/whitelist entry) for some
certificate related to 'infradead.org' and any mail server which
presents a cert signed by that certificate would be treated accordingly.
A trust scheme based on TLS certificates (or perhaps some other database
key which is easy to verify) could be introduced without all the
breakage at forwarding sites which would be caused by the proposed
'mailfrom' or 'pra' scopes of SenderID, and would achieve much the same
benefit, since SenderID does _not_ offer end-to-end validation but only
per-hop trust assessments of individual hosts.
Plus to that Received header is normally added by systems when it received
the message but Submitter information is added when message is being sent out.
Tony already pointed that out, and it is true -- so it seems a new
header does make more sense for purely practical reasons.
I have not seen any reason given for abusing the existing Resent-From:
header, nor do I understand why it is useful to do so instead of
introducing something new and unambiguous.
I completely agree. I'll be submitting proposal later this week on it.
OK, good.
--
dwmw2