Subject: Re: Regarding SMTP path length ...
From: Keith Moore <[email-masked]>
To: "dhananjay" <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Fri, 1 Aug 2003 00:05:14 -0400
List-Id: <ietf-822.imc.org>

>     I have a question regarding the maximum path length allowed in RCPT TO
> as well as MAIL FROM.
>     RFC 2821 says, this limit is 256 bytes.
> 
>     Now, does this limit include the escape characters specified in path ?
>     For e.g., if address is <a\@[email-masked]>, then
>     whether path length calculation should include "\" character ?

yes.

From: "dhananjay" <[email-masked]>
To: <[email-masked]>
Subject: Regarding SMTP path length ...
Date: Thu, 31 Jul 2003 20:45:42 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00F2_01C357A4.B56CB800
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
    I have a question regarding the maximum path length allowed in RCPT TO
as well as MAIL FROM.
    RFC 2821 says, this limit is 256 bytes.

    Now, does this limit include the escape characters specified in path ?
    For e.g., if address is <a\@[email-masked]>, then
    whether path length calculation should include "\" character ?

    I feel irrespective of any escape/special character present in path, the
path length is calculated on byte by byte basis. I just want to confirm
this.

Regards,
Dhananjay.

------=_NextPart_000_00F2_01C357A4.B56CB800
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I have a question =
regarding the=20
maximum path length allowed in RCPT TO as well as MAIL =
FROM.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; RFC 2821 says, this =
limit is 256=20
bytes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Now, does this limit =
include the=20
escape characters specified in path&nbsp;?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; For e.g., if address =
is=20
&lt;a\@[email-masked]&gt;,&nbsp;</FONT><FONT face=3DArial size=3D2>then =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; whether path length =
calculation=20
should include "\" character ? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I feel irrespective =
of any=20
escape/special character present in path, the path length&nbsp;is =
calculated on=20
byte by byte basis. I just want to confirm this.</FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>Regards,<BR>Dhananjay.</FONT></DIV></BODY></HTML>

------=_NextPart_000_00F2_01C357A4.B56CB800--

To: Randall Gellens <[email-masked]>
Cc: [email-masked]
Subject: Re: Format=Flowed/RFC 2646 Bis (-01)
From: Simon Josefsson <[email-masked]>
Date: Thu, 31 Jul 2003 19:42:21 +0200
Sender: [email-masked]

Something that came up here, which could be useful to discuss in the
security consideration: OpenPGP says that trailing white space on an
article is ignored when computing digest on a cleartext signed
message.  This means that someone can add, in transit, a format=flowed
header to a (regular, non-flowed) vanilla PGP (not PGP/MIME) signed
message and introduce arbitrary trailing SPC characters without being
detected.  This change the rendering of the article, if the client
support format=flowed, possibly even in a malicious way.

Consider someone sending:

My favorite letters, ordered by priority (letters on the same line
are of the same priority):
A Q
C
L O
X

that is (using the syntax of the draft)

A Q#
C#
L O#
X#

Someone could add a format=flowed header to the message, and add
trailing SPC to two of the lines, turning the message into

A Q*
C#
L O*
X#

which would still verify correctly, but be rendered by the client as

A Q C
L O X

together with a successful PGP verification, but the result has a
different meaning.

Section 5.6 of the document discusses digital signatures, but I'm not
convinced it covers for this problem.  OTOH, one could consider this a
bug in 2440; a message should not verify successfully if it isn't the
same as the one that was signed.

Thanks.

(Of course, the imaginative reader will realize similar problems in
other systems, that have this "canceling" property that format=flowed
together with OpenPGP exhibit in this example.)

Date: Thu, 24 Jul 2003 23:10:07 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: draft-moore-auto-email-response-01
Sender: [email-masked]

After over a year's delay, I've finally revised my recommendations for
automatic email responders.  I just sent them to the internet-draft
folks (in both text and PDF for the ASCII-impaired).   Or you can get
the preprint at any of:

http://www.cs.utk.edu/~moore/I-D/draft-moore-auto-email-response-01.txt
http://www.cs.utk.edu/~moore/I-D/draft-moore-auto-email-response-01.ps
http://www.cs.utk.edu/~moore/I-D/draft-moore-auto-email-response-01.pdf

I've tried to address the comments that were made when the -00 version
came out (well, those I didn't totally disagree with :), but the changes
are too numerous for me to summarize at this point.

Keith