Subject: draft-ietf-marid-core-02.txt

From: Tony Finch <[email-masked]>
Date: Sun, 25 Jul 2004 02:53:10 +0100

The abstract states:

   The specification is carefully tailored to ensure that the
   overwhelming majority of legitimate emailers, remailers and mailing
   list operators are already compliant.

Has anyone published a survey on this topic? Implementations that I know
are not compliant include:

	Sendmail (.forward and /etc/aliases)
	Exim (ditto)
	Cyrus (Sieve redirect)

Postfix and qmail typically add Delivered-To headers in the process of
alias-forwarding a message; however these are no longer part of the PRA
algorithm and can't be added without conflicting with the RFC 822
semantics of Resent- header fields.

The Introduction suggests: "an MDA might discard a message rather than
placing it into a mailbox". Recommending the silent discarding of email
that is likely to be legitimate is irresponsible.

Section 2.1 says "The mechanism of this document also seeks to
authenticate the mailbox associated with the MOST RECENT introduction
of a message into the mail delivery system." This protocol claims to
authenticate domains not mailboxes.

It goes on to say "However, in the case of a third-party mailer, a
forwarder or a mailing list server, the address being authenticated is
that of the third party, the forwarder or the mailing list." The
terminology here is rather imprecise. The document as a whole needs to be
much clearer about the difference between encapsulation-forwarding (for
which one might use the MIME type message/rfc822), alias-forwarding (via
the Sieve redirect command or the Unix /etc/aliases or .forward
mechanisms), and re-sending (which is similar in use to encapsulation-
forwarding except that the message is not encapsulated; it is what Resent-
header fields are for).

Section 4.

     6. The message is ill-formed, and it is impossible to determine a
        Purported Responsible Address.  MTAs performing the Sender ID
        check as part of receiving a message SHOULD reject that message
        with "550 5.1.7 Missing Purported Responsible Address".

I recently performed a practical experiment to check for well-formed
Sender: and/or From: header fields in messages passing through the
University of Cambridge's email system. It was rather short-lived because
of the large number of hopelessly malformed legitimate messages. Large
email systems will not be able to enforce RFC 2822 syntax as the above
paragraph suggests they should.

Section 7.2.

The recommendation in this section conflicts with the semantics for
Resent-From: defined in RFC 2822. In addition, this recommendation forces
email systems to de-optimise the delivery of messages with multiple
recipients that alias-forward on to the same external site, since it
requires that each alias-forwarding address adds a different header to the
message. This multiple copies of the message are sent on to the external
site instead of just one as at present.

Finally, I note that a typical academic site will have thousands of users
(on the order of 10% of the population) who alias-forward email to or from
an off-site email system. These users and their sites will be seriously
inconvenienced by the widespread implementation of this protocol. The
compatibility problems of are serious and still unresolved after getting
on for a year of concerted effort.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 2 OR 3 INCREASING 3 OR 4. FAIR.
GOOD. SLIGHT OR SMOOTH.

---

From: Tony Finch <[email-masked]>
Date: Sun, 25 Jul 2004 03:06:50 +0100

On Sun, 25 Jul 2004, Tony Finch wrote Re: draft-ietf-marid-core-02.txt
> site instead of just one as at present.

This also applies to section 5.2 of the SUBMITTER specification.

In addition, the suggested use of Resent-From: in section 5.4 is even
further from the RFC 2822 semantics.

Tony.