On Tue, 2003-03-18 at 11:33, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
On Tue, 18 Mar 2003 10:43:38 EST, David Green
<green(_at_)couchpotato(_dot_)net> said:
SMTP servers SHOULD remove any Authorized-By SMTP headers of
incoming mail. They MAY be configurable to preserve Authorized-By
headers on incoming mail from a set of trusted servers.
This goes against a long-standing design principle that SMTP servers should
NOT be screwing around with the contents of the headers other than to add
a Received: tag.
The fact that they add a Received tag means that modifying headers is
not against their design.
There's no hint of what an Authorized-By: header would look like.
Authorized-By: FQDN goes here
What defense(s) does this protocol have against DNS cache poisoning?
If DNS is broken, that needs to be addressed separately.
What domain do you do the query on? You can't just blindly go 2 levels,
as that will piss the admins of 'co.uk' off quite thoroughly. You may
have to go 3 levels in the US - we have departmental mail servers that
you'd have to look under some-dept.vt.edu to find an MT for, since they're
only "authorized" to send mail for their department... oh, and for vt.edu
because that's what many people put on their From:.
If the email is From:
foo(_at_)bar(_dot_)baz(_dot_)biz(_dot_)buz(_dot_)co(_dot_)uk, you would query
the MT
for "bar.baz.biz.buz.co.uk". You would never drop any parts of the name.
SMTP servers SHOULD perform an MT DNS query on the domain of
the From header. If the incoming mail was sent by a server returned
in the query, the SMTP server SHOULD attach an Authorized-By
header to the message, whose value is the hostname of the server
performing the MT authorization.
Combined with the above, you're left with only the last hop information.
That is all that matters. It will be up to your POP/IMAP server's SMTP
implementation to do the final checking, even if that checking simply
involves trusting another SMTP server.
Let's say the mail starts at a Unix workstation, which sends it to a mail
hub. The Auth-By: now lists the workstation. The hub tries to send it to
your server, fails, and sends it to your off-site backup MX service.
The MX nukes the previous AUth-by, and adds one pointing to the originating
mail hub. Your server comes up, the mail starts arriving.
Authorized-By would not list the workstation, as MUAs would not be
configured to add this header. If it did, the hub would remove it. The
only reason the MUA would be sending to the hub at all is if the MUA is
associated with that hub or if the hub is an open relay. Assuming the
prior, the hub must be a registered MT for the sender's domain, or it's
not compliant. The hub sends it to your server, fails, sends it to your
off-site backup MX service. The MX nukes any previous Authorized-By
header, checks an MT for the hub, finds one, and adds its own
Authorized-By header. Your server comes up, your MUA pops the mail, and
there's the Authorized-By header.
Note that it's *quite* possible for mail to trickle through 3 or 4 MX servers
if there's a widespread net-burp.
Every MX either sends to a server that trusts it (a relay), or to the
recipient's MX. The only restriction here is that the MX that initiates
the final hop to the recipient's MX must be listed as an MT for the
sender's domain.
Mail User Agents (MUAs) MAY allow the user to filter incoming
messages based on the presence of an Authorized-By header.
What would be *most* useful here is the *original* value of the Auth-by:
header, which almost certainly got wiped out by some host due to the first
part of section 3.
Why? You couldn't trust it anyway. Just like Received lines.
David Green
signature.asc
Description: This is a digitally signed message part