On Wed, 2004-11-03 at 16:44 -0800, Jim Fenton wrote:
The problem with 'reject' is that it will likely cause the preceding
MTA, which is likely to not be mailsig-aware. If we're really trying
to suppress bounces, you need to accept and silently discard.
You could apply the same argument when advocating that mail to unknown
addresses should be silently discarded instead of bounced. Seriously, we
_have_ to preserve the quality that mail will either be delivered or
bounced. If we make the system unreliable we are throwing the baby out
with the bathwater. I feel very strongly that we _must_ avoid just
discarding mail.
Most people are already coming to terms with the idea that backup MX
must be done selectively, with the same spam policies implemented on the
backups as on the primaries, and with some method for the backups to
know which are real addresses and which are unknown. This is precisely
to avoid the same kind of backscatter. There are also schemes such as
SES and BATV which allow the victim recipient of backscatter to reject
it.
Let's not advocate discarding mail just to avoid something which is an
already known and relatively limited problem. But if it's a concern,
let's say instead that if the primary MX host for a domain rejects mail
due to mailsig signature checking, then all backup MX hosts for that
domain SHOULD also reject with the same criteria, to prevent the system
as a whole from performing accept-and-bounce. Surely that should be
enough?
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).
I think the only place we explicitly require quoted-printable is with
respect to copied headers. But this should only be an issue if the
message coming in is not already RFC 2822 compliant, because the RFC
2047 encoding will ensure that there's nothing that we need to convert
(except equals signs and double quotes). I'm not sure about the
requirement to convert to UTF-8 first. Would it be better if we
require RFC 2047 encoding of the headers, and perform that encoding if
it's not already there?
That would make sense, yes. But I was really thinking of text parts of
the mail -- doesn't that often get charset-encoded in transit? Or am I
thinking just of conversion from 8-bit to QP or base64 for transmission
to non-8BITMIME SMTP servers? In which case, standardising the charset
probably isn't necessary. Does anyone have real statistics which cover
this?
The body length count always starts at the beginning of the body
(following canonicalization, if any). No matching is required. Is
that unclear from the spec?
Only in my head :) That's fine then -- sorry.
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?
I'm still lacking information on how and where
Resent-From/Resent-Sender are used, so I ignored them in the spec. If
we need support for them, then, yes, they also need to be included. I
don't see a lot of Resent-* in the messages I get; is this an
important case I'm ignoring? Or can we get users of Resent-* to also
set Sender?
If I ask pine to 'bounce' a message to you, or Evolution to 'redirect' a
message to you, as I just did to send your own message back to you,
they'll add 'Resent-...' headers in accordance with §3.6.6 of RFC2822.
This is a long-established practice, although many MUA users don't
actually _use_ it. I don't think it's wise for us to be trying to change
it.
In general, however, the message doesn't actually get mangled when it's
resent. So perhaps we could ignore it? I wouldn't be too adverse to
that, I suppose.
... 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?
If you don't mind, lets queue these ideas for later. There are some
more fundamental issues we need to deal with first.
Agreed.
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.
Where is it phrased better? I don't have a section 4.6.
Hm no I don't have a 4.6 either. I think I meant 5.4.
It's definitely a hack. I made it a SHOULD because IMO visibility of
the signing address to the end user is essential to the security of
email authentication. If the message has a From header of
<security(_at_)bigbank(_dot_)com> but has a Sender header of
biff(_at_)sdfcdnasdocnaspf(_dot_)com [some throwaway domain], the user really
needs to know that. Absent the security consideration, I would
definitely have made this a MAY.
I like it being a SHOULD in the MUA -- I agree with you there. But you
seem to make it a SHOULD in the MTA too, and that I don't like. I prefer
what you say in §5.4 -- an MUA SHOULD, and an MTA MAY if it has to deal
with MUAs which don't¹.
In fact I'd like to make it even more clear and say that an MTA MAY do
so on incoming messages but SHOULD NOT change the From header on
outgoing messages from its own site or messages which only pass through
the MTA in transit.
¹ (Actually you say 'if MTA implementations that highlight the signed
address are not available' where presumably you mean 'if MUA
implementations...'. I hadn't noticed that before.)
--
dwmw2