ietf-mailsig
[Top] [All Lists]

Re: DKIM: c=simple is aspirational

2005-07-17 21:03:49

On July 17, 2005 at 17:08, domainkeys-feedbackbase02(_at_)yahoo(_dot_)com wrote:

I don't know whether Ned is of the view that it *should* be excised or 
whether
it can be re-cast to alleviate his concerns in terms of defaults, advice 
to
implementers, nomenclature implications and so on.

I believe simple should be there, but it is too simplistic.
Line folding in headers and normalization of header field names
to lowercase should be done to preserve the semantics of RFC-2822.

Along with that, specific recommendations should be added when
"simple" is the choice algorithm.  For example, the message should
be formatted/encoded according to the MIME specification to insure
safe transport.  This includes converting all entities into
7bit, using quoted-printable and/or base64 to achieve this.

For entities where the original data contains trailing whitespace,
the entity should be converted to quoted-printable.  For example:

  Here is a line with some extra spaces at the end  =20

And lines that start with "From " should cause the entity to
be CTE'ed in quoted-printable:

  From=20 here to eternity.

To avoid the potential of intermediate systems from escaping
the "From " by prefixing it with a ">".


Perhaps it's my background in seeing the creativity and efforts of 
commercially
oriented abusers but I for one do not completely trust *any* wriggle-room 
in
content.

And nowsp provides too much wriggle room.

I understand the realities of the infrastructure, but 
nonetheless I
get very nervous about the overlap between survivability and risk. IOW, I 
don't
want a deployment that doesn't offer a no-risk option - even though it has
problems in the current infrastructure.

But you should not violate existing standards, unless you have a
strong argument to do so.

FWIW. What I've seen in the ten or so DK implementations, is that 
implementers
have had no trouble choosing between the two and in deployment the use of
c=simple has been very selective. On the receiving side, we simply 
haven't seen
a high rate of c=simple deployment which could incur the wide-scale
disappointment that Ned is worried about.

But who is doing the sending and the receiving?  What percentage of
that represents the entire email using community?

--ewh


<Prev in Thread] Current Thread [Next in Thread>