Subject: [Asrg] Domain-Authorized SMTP Mail

From: David Green <[email-masked]>
Date: 18 Mar 2003 10:43:38 -0500

I posted this to the namedroppers list 1-Jun-2002. It describes a method
of ensuring that only the owner of a domain can authorize the use of
that domain for email purposes, without restricting those who do not
wish to comply. This is the first step in authenticating email without
the use of digital signatures.

June 1, 2002

                   Domain-Authorized SMTP Mail

Copyright Notice

   Copyright (C) David N. Green (2002).  All Rights Reserved.

Abstract

   This document describes when and how to specify Mail Transmitter (MT)
   resource records (RRs) in the Domain Name System (DNS), how to
   configure SMTP servers to query them effectively, and how to
   configure Mail User Agents (MUAs) to filter based on them.

1. Introduction

   Historically, Internet mail has been plagued by forgeries. This has
   become more problematic as the practice of sending Unsolicited
   Commericial Email (UCE) has gained popularity. The addition of MT
   RRs to DNS will solve the problem of forgery of domain, without
   placing undue burden on any Internet Service Provider. This allows
   the Internet Service Provider to begin the process of prevention
   of forgery of user. The use of MT RRs at any site is RECOMMENDED.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119.

2. Mail Transmitter Resource Records
   
   All hosts which are authorized transmitters of mail for a domain,
   including any authorized forwarders, SHOULD be designated as Mail 
   Transmitters through the use of an MT RR.

3. MT DNS queries and Authorized-By SMTP headers

   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.

   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.

4. Mail User Agent handling of Authorized-By headers

   Mail User Agents (MUAs) MAY allow the user to filter incoming
   messages based on the presence of an Authorized-By header.
   MUAs MAY allow the user to further filter authorized messages
   based on the domain of the From header.

5. Security Considerations

   If a user's ISP does not support at least the removal of
   Authorized-By headers as stated in section 3, incoming mail may
   be easily forged.

   Additionally, any host between the sender and recipient, or who
   can otherwise masquerade as the sender, can also masquerade
   as an authorized transmitter for the domain of the sender.

Author's Address

   David N. Green
   563 Bill Rutledge Rd
   Winder, GA 30680 USA

   Phone:   +1-770-868-0754 (w)
            +1-770-868-1572 (h)
   Fax      +1-770-220-1937
   EMail:   [email-masked]

---

From: [email-masked]
Date: Tue, 18 Mar 2003 11:33:22 -0500

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

That 'MAY be configurable' is a bug.  See below.

There's no hint of what an Authorized-By: header would look like.

What defense(s) does this protocol have against DNS cache poisoning?

Note that a large domain may have many MT records.  This will cause a dropback
to TCP if the DNS reply exceeds 512 bytes.  Take a look at the games that
AOL uses with round-robin on their MX listings so they can have
24 IP addresses listed and still get it to fit in a UDP packet (basically,
they have 4 advertised MX names that round-robin, and they only return
a set of 6 IP addresses for 1 or 2 of the MX's in the 'additional info'.
Hotmail does similar things.  And forcing a drop-back to TCP is *expensive*.
Figure out what's the minimum number of RTT's (including the 3-packet handshake
and FIN processing) needed to deliver a piece of mail, both with and without
SMTP PIPELINE.  Then add an RTT for a UDP lookup - and then figure out how
many MORE you add if that fails and DNS over TCP is needed....

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

You *DID* know that RFC822 and RFC2822 allow a From: to be a *LIST* of
addresses, right?  See section A.2 of RFC822 for several examples with
different semantics.

>    performing the MT authorization.

Combined with the above, you're left with only the last hop information.

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.

If you don't implement the 'MAY preserve' for mail coming from your MX,
then bad things happen:

1) You remove the Auth-by.
2) You look up the MT RR.
3) Your MX is certainly NOT listed in the MT.

Game Over.

Note that it's *quite* possible for mail to trickle through 3 or 4 MX servers
if there's a widespread net-burp.

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

---

From: David Walker <[email-masked]>
Date: Tue, 18 Mar 2003 10:38:55 -0600

I believe there are a number of us interested in this type of solution but for 
it to work we would have to distill the ideas together.  

Checking the from header has serious implications with mailing lists and I 
proposed that we do not check the from header but check the envelope from and 
require that MUAs expose the envelope from in the form of "from 'envelope 
from' on behalf of 'from header'"

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg01533.html

wayne wrote:
See:

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00001.html
RMX records
(Yes, this was the very first message to this mailing list)

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00048.html
domain specific DNS blacklists (or whitelists)

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00686.html
pros and cons of RMX (Re: [Asrg] Declaration to the world)

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: David Green <[email-masked]>
Date: 18 Mar 2003 11:48:17 -0500

> NOT be screwing around with the contents of the headers other than to add

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.

> because that's what many people put on their From:.

If the email is From: [email-masked], you would query the MT
for "bar.baz.biz.buz.co.uk". You would never drop any parts of the name.

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

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

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

> header, which almost certainly got wiped out by some host due to the first

Why? You couldn't trust it anyway. Just like Received lines.

David Green

---

From: David Green <[email-masked]>
Date: 18 Mar 2003 11:55:56 -0500

> from' on behalf of 'from header'"

Or the From: could be changed to the mailing list address and an
Originally-From: header could be added.

David Green

---

From: David Walker <[email-masked]>
Date: Tue, 18 Mar 2003 11:25:50 -0600

Your DNS request/reply need only contain the MT/RMX/MS record of the IP 
address that is connected to your mail server.  You should not need to 
transfer all MT/RMX/MS records.

On Tuesday 18 March 2003 10:33 am, [email-masked] wrote:
> Note that a large domain may have many MT records.  This will cause a
> dropback to TCP if the DNS reply exceeds 512 bytes.

---

From: [email-masked]
Date: Tue, 18 Mar 2003 14:07:03 -0500

> for "bar.baz.biz.buz.co.uk". You would never drop any parts of the name.

You got it backwards.  If the mail is 'From: [email-masked]', you need to
suck down all 200 or so MT entries in the vt.edu domain and see if my IP
is one of them.

And it's even more borked for mailing lists, because the From: and To:
don't have much to do with what's going on.  The mail server for couchpotato.net
would be looking at this message, and complaining because the ietf.org
mail server isn't an MT for the vt.edu in the From: field.

Oh, and this message is coming to you direct, and a cc: to the list - explain
how your scheme handles each of the copies that are arriving.

If you get it to work for mailing lists, run it again for the case of a
spammer making the spam LOOK like a mailing list posting (hint - they're
usually pretty similar already).

Looking at the MAIL FROM: in the envelope doesn't provide much more joy.

(As an aside to the person who suggested logging the MAIL FROM in the From:
field - did you really WANT it to look like:

From: bugtraq-return-8764-Valdis.Kletnieks=[email-masked] on behalf of  

From: [email-masked] on behalf ov

Yes - imagine that.  Some list management software encodes the destination
address in the envelope so it can identify a bounce even if the bounce is
misformatted, as long as it goes back to the RFC821 MAIL FROM like it's
supposed to.)

> the final hop to the recipient's MX must be listed as an MT for the

OK. So let's say this happens:

[email-masked] sends you mail.  Your server is down.  So he
sends it to mail.mx-are-us.com (your off-site MX service).  mx-are-us
sticks on a Auth-By: header.  Later on, your server comes up.  mx-are-us
sends you the mail.  Now let's say you do the totally legal thing of not
preserving the Auth-By, so you strip it off.  Now you're looking at mail
coming from mx-are-us, with 'From: [email-masked]'.  You look up the
MT list for non-spam.com, and get back 23 entries - and none of them are
mx-are-us.com.  Now what do you do?

The point is you need to tighten up the language about what to do if

> >    headers on incoming mail from a set of trusted servers.

is broken.  For it to be workable, you need to make it a 'MUST preserve'
for the case of mail coming from your MX'es.

---

From: [email-masked]
Date: Tue, 18 Mar 2003 14:32:14 -0500

On Tue, 18 Mar 2003 14:18:19 EST, David Green said:

> The vt.edu domain certainly only has a few authorized outgoing smtp
> relays. I don't think they handle enough mail to justify a server farm
> of 200 servers just for their email.

The question is whether AOL.COM has few enough authorized outbound relays
that it fits in a single 512-byte UDP DNS query.  I know they can't fit
all their inbounds into one packet, so I suspect the outbounds don't either.

> > don't have much to do with what's going on.  The mail server for couchpot=
> ato.net
> Thats why the [email-masked] address would have to be used for
> authorization.

Hey, what do you know... [email-masked] isn't in the From: - in fact, if it's
bcc:ed it may not appear in the RFC822 headers *AT ALL*.

> The copy from you to me would be authorized as coming from you. The copy
> from you to the mailing list would be authorized by Majordomo to be
> coming from you.

Majordomo may not be able to authorize it - see my discussion about MX
handling, which also matters in case of firewalls and mail servers in the DMZ.

> When the mailing list resends the message, the message
> would be checked by each recipient's MX as coming from [email-masked]. As
> you see, the From: starts to have real meaning.

> If my MX trusted mail.mx-are-us.com, it would not strip the
> Authorized-By header.

But that's not what your draft said.  It said it *MAY* be configured to
do so.  MAY means its *optional*, not "you have to do it for it to work
the way you expect" - that's what MUST is for.

> >=20
> >=20
> Your MX's would be trusted servers.

Then fix your MAY.

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Mar 2003 14:46:49 -0500

> all their inbounds into one packet, so I suspect the outbounds don't either.

My tools show some providers with whole class C's virtually stuffed with 
"official" mail servers.  MSN/Hotmail is a good example - probably 
considerably more than 250 outbound servers in total (once you include 
all of the MSN/Hotmail mail servers plus all the webmail things that 
send directly) in various class Cs.

---

From: "Ronald F. Guilmette" <[email-masked]>
Date: Tue, 18 Mar 2003 11:46:29 -0800

In message <[email-masked]>, 
[email-masked] wrote:

>as that will piss the admins of 'co.uk' off quite thoroughly...

If anybody needs it, I have already developed a domain name ``splitter''
that splits any given domain into two parts, i.e.:

    1)	a prefix, and

    2)	a suffix consisting of (a) a domain name label belonging to
	some specific organization followed by (b) a reserved
	(geographically or otherwise) domain name.

Given an FQDN such as x.y.z.international-widgets.co.uk, the splitter
will split that as follows:

	x.y.z   international-widgets.co.uk

C source code is available here:

    ftp://ftp.monkeys.com/pub/dname-tools/c/orgd-1.0.tar.gz
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: David Green <[email-masked]>
Date: 18 Mar 2003 14:18:19 -0500

coming from you. When the mailing list resends the message, the message

> preserving the Auth-By, so you strip it off.

David Green

---

From: David Green <[email-masked]>
Date: 18 Mar 2003 16:03:47 -0500

> all their inbounds into one packet, so I suspect the outbounds don't either.

If the DNS system is broken, that is a subject for another list.

> bcc:ed it may not appear in the RFC822 headers *AT ALL*.

Majordomo masquerades as other people when it relays emails. This is
precisely what we want to prevent. The From: should be changed to the
name of the mailing list.

> handling, which also matters in case of firewalls and mail servers in the DMZ.

After leaving the public Internet, all internal mail servers should be
set to trust each other if they plan on relaying to each other.

> the way you expect" - that's what MUST is for.

I'll work on this.

David Green

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 18 Mar 2003 15:39:30 -0500

>from' on behalf of 'from header'"

Require in what sense?  The RFCs already require that it be put in 
Return-Path: by the delivery agent.  Is having the MUA display it 
really going to change anything?

One of the things I discovered, in my fight to keep people from 
putting [email-masked] in their address book, is that many 
people don't see the email address at all.  I don't know if this is 
because the UA doesn't show it, or because they just stop "seeing" 
it.  But I got so many "who the hell are you"  responses when I 
replied as "From: Kee Hinckley <[email-masked]>" that I had 
to change it to "From: [email-masked] Admin 
<[email-masked]>" so that they'd realize this was something 
they'd sent to.  (And even that didn't help, since in their address 
book it was usually there as "AAAA" so they would claim they didn't 
send me the email.  And their UA was hiding the address even when 
they sent--they only saw the AAAA.

The only chance you have of exposing the Return-Path so that people 
will see it is to have the MUA change the text of the from name to 
include the return-path if the return-path is different from the 
from.  E.g.

From: "Kee Hinckley via [email-masked] <[email-masked]>"

And they won't understand it.  I get so many people who don't 
understand that From: has no bearing on the person that sent the 
email that I have an auto-response for the problem.

But more to the point.  I don't think the IETF is in a position to be 
specifying proper user interface behavior.  Suggest perhaps, but I 
wouldn't depend on the results.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 18 Mar 2003 15:46:11 -0500

>Originally-From: header could be added.

One of the advantages of domain-based authentication is that it 
doesn't require MUA changes.  That change would break the behavior of 
MUAs with mailing lists.  Not a show-stopper perhaps, but worth 
noting.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: [email-masked]
Date: Tue, 18 Mar 2003 16:28:51 -0500

> If the DNS system is broken, that is a subject for another list.

Handwaving that way won't change the fact that your scheme would *double*
the effort required to accept mail from most of the largest providers - which
is where most of your mail will likely be *from*.

And there's lots of ugly scaling effects - double the load may require more
than double the hardware..

> name of the mailing list.

You really don't understand why lists work the day they do, do you?

There are reasons it is done the way it is.  In particular, if you change
the From: to the name of the list, where do we put the *POSTERS* name?
(Hint - if you're strictly RFC-compliant, it doesn't go in Sender:.  RFC822
overloads Sender: with 2 values, neither of which is correct semantics for
the person posting to the list).

This note would have appeared as:

From: [email-masked]
To:   [email-masked]

(You can't put individual recipient names in there, because then each message
body is different. Then you can't piggyback RCPT TO: - there's a *BIG*
performance difference between MajorDomo handing the MTA 1 piece of mail with
400 RCPT TO:, and 400 separate pieces of mail with 1 RCPT TO each.  This is
particularly obvious if you have 20,000 recipients and somebody posts a 500K
attachment (quite reasonable for some lists) - the one way you can do it using
500K of disk plus 1 list of addresses, the other way you just blew 10 gigabytes
of spool.  There's also the performance issues of having 20K messages to track
rather than just 1 (do an 'ls' in a directory with 1 file, and in one with 20K
files, and let me know what happens..)

And any sane citing software would have generated:

On Tue, 18 Mar 2003 16:03:47 EST, [email-masked] said:

Oh, and that renders 'reply to author' impossible.

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 18 Mar 2003 15:29:47 -0500

>mail hub.  Your server comes up, the mail starts arriving.

While you've got some good points I wouldn't pick on the MX issue 
particularly.  I think in this proposal was assuming (as a lot of 
anti-spam schemes do) that the MX server has to act like, and be 
treated like, the main server.  That's an issue, since small 
companies don't always have that level of MX control--but it is a 
necessary part of almost all proposals, not just that one.

---

From: Jim Littlefield <[email-masked]>
Date: Tue, 18 Mar 2003 16:51:06 -0500

> MUAs with mailing lists.  Not a show-stopper perhaps, but worth 

Deployment of *any* spam solution will be much easier at the MTA level.

-- 
Jim Littlefield             "All those who believe in psychokinesis
                             raise my hand." - Steven Wright
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Claus Assmann <[email-masked]>
Date: Tue, 18 Mar 2003 15:01:51 -0800

> not against their design.

It's trivial to add a header, it's harder to modify a header since it
requires parsing which I do not want to do in my MTA.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg