I'm assuming that the random spaces in the middle of words like 'w orms'
in the first paragraph of the introduction are a systematic error due to
the way the text is edited and rendered into text form?
In §3.2 you suggest that if the the null key check indicates that all
legitimate messages are signed, "the verifying MTA SHOULD discard
unsigned messages. It MAY generate a "bounce" message when doing so."
I'd like to rephrase that. Let's not say that you "MAY" accept and
bounce, thereby almost certainly spamming innocent third parties with
your bounce to a faked message. Let's instead say that you "SHOULD NOT"
accept and bounce. That still leaves the same leeway for people who
really _want_ to make themselves part of the problem by implementing
accept-and-bounce to do so, while making it clear that they shouldn't.
I'd also like to change 'discard' to 'reject'. IMHO one should never
just discard mail. You do your utmost to _reject_ it if you don't like
it, and in exceptional circumstances you may only work that out later so
you may _occasionally_ need to accept-and-bounce. But neither 'discard'
nor 'bounce' are good suggestions in the general case.
Although you're quite specific about using quoted-printable, your
canonicalisation seems to make no mention of character sets. I would
suggest that you MUST convert all character sets in text parts
(including the headers) to UTF-8 before converting to QP and creating or
verifying a signature (although you don't have to _send_ as UTF-8).
Also, have you done any analysis of the cost of the 'body length count'
in practice? Given a length of N bytes, is the recipient expected to
perform a full cryptographic check on each range of N bytes within the
received email? I had assumed that a simpler rolling checksum would be
needed to locate potential matches in the larger text before the more
expensive check was done... was I being overly defensive in that?
In §5.2 you say "the From header MUST be included; the Sender header
MUST also be included [if appropriate]". You omit any reference to
Resent-From/Resent-Sender, which likewise MUST also be included, surely?
Although you sanely eschew wildcard DNS entries elsewhere, you suggest
their use in §6.1.3 for publishing a null key policy. This is a prime
example of why wildcard records are no use -- you'll only actually see
the record for any domain name which _doesn't_ have any other RRs....
i.e. you'll only be managing to publish your wildcard null key record
for those domain names which sane people wouldn't be accepting mail from
anyway, because they have no way of receiving mail by virtue of having
neither A, AAAA nor MX records.
In §6.2 you say that "If the verifying MTA is able to verify the public
key of the sender and check the signature on the message as the message
is received, the MTA MAY reject the message...". Since you've already
qualified it with "if the MTA is able..." I'd definitely want to see
that change to "SHOULD reject the message", or at least make it clear
that the MTA SHOULD NOT accept the message if it's going to be rejected
(and hence bounced) later.
You speak of the possibility of a message such as '4yx Unable to verify
signature - key registration server unavailable'. It occurs to me that
the process of trying to fetch a key may take a while, and it's done
after the DATA are sent and while the sender is waiting for our
acknowledgement. RFC2822 says we should be as quick as possible about
that... so have you considered an SMTP extension to provide the IIM key
as part of the MAIL FROM command, so it can be fetched in advance?
§7.4 isn't quite correct in its portrayal of RFC2822 requirements w.r.t
the Sender header, I think. It says that a forwarder MUST remove any
pre-existing Sender header, but if there's a Sender header and we
resubmit the message adding our own Resent-{From,Message-ID,To} headers,
we aren't obliged to remove the old Sender header are we? We should
leave it intact. In §7.4 you should discuss this type of 'forwarding'
also, and make it clear that a signature for the Resent-From: address
must be included.
In §7.6. 'Third-party Message Transmission.' you say that a verifying
MTA 'SHOULD' mangle the From field by including information from the
Sender field. Can we change that to 'MAY'? It's a hack to work around
what some MUAs currently display, and it's not something that should be
done in general. We should make that clear, surely? In fact it's phrased
a lot better in §4.6 already.
You should add a new subsection 9.1.5 to discuss the potential denial-
of-service attack posed by large messages with a bogus length count,
forcing the recipient to hunt for the signed part in the message.
--
dwmw2