Subject: Re: CRs in messages
From: Tony Hansen <[email-masked]>
To: [email-masked]
Date: Thu, 31 May 2001 10:38:47 -0400
List-Id: <ietf-822.imc.org>

No, there's no perfect solution for dealing with those broken MTAs. One
of the reason we chose to check for the bad terminator after timeout
was, if we didn't, the message would sit around in the other end's
queue, blocking other messages from flowing. This happened enough times
and we got enough complaints that we made this compromise. Our job was
to get the messages through, not interpreting was inside them. So the
fact that the receiving MUA might have difficulty was less of a concern
to us. Besides, if you get the data through, at least the end user has a
chance of seeing the data. If they don't get the mail, they have no
chance whatsoever. You have to make your choices; your decisions may be
different that ours were.

	Tony Hansen
	[email-masked]

Paul Smith wrote:
> ...
> I don't see that there's a 'perfect' solution to this, except for everyone
> doing everything totally according to the standards, and I don't think
> that'll ever happen...
> Checking for a CR.CR as the last data received at the point of a timeout is
> a possibility, but as I've said it will stop any 'intelligent' MUA
> behaviour such as MIME decoding/recoding on messages containing CR line
> terminators.
> If you always check for CRLF as the message terminator except at a timeout,
> but allow any line terminator in the body of a message, then, as well as
> introducing complexity, it means that message data may be 'corrupted' if
> there are bare CRs or LFs in the middle of a message.
> 
> Maybe the best thing to do is just to disobey the 'be flexible in what you
> receive' idea, and just reject anything which has incorrect line
> terminators - at least that might put pressure on people to use the proper
> ones... :-)
> 
> Paul                            VPOP3 - Internet Email Server/Gateway
> [email-masked]                 http://www.pscs.co.uk/

From: [email-masked]
Date: Tue, 29 May 2001 06:55:24 -0700 (PDT)
Subject: Re: limitation of the number of To: (and Cc:)
To: Kazu Yamamoto <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> From: [email-masked]
> Subject: Re: limitation of the number of To: (and Cc:)

> > Not necessarily; the agent is free to combine all the To: addresses
> > into a single To: field and all the Cc: addresses into a single Cc: field.
> > The user agents I am familiar with do this.

> The background of my question: my mail reader doesn't combile
> addresses even if there are multiple To: fields. I think this is
> conformant to RFC822.

Well, sort of. It says:

            This specification permits multiple  occurrences  of  most
            fields.   Except  as  noted,  their  interpretation is not
            specified here, and their use is discouraged.

> Reading RFC2822, I realized that I should modify my mail reader to
> combine addresses to a single To: field as you said, Ned.

I'd recommend it.

> I needed to know why RFC2822 made such a change before implementing
> it.

That's a somewhat different question than what you asked before. I believe the
answer is that since RFC 822 allowed multiple fields but didn't specify their
semantics, we've ended up with different and incompatible behavior in different
implementations. But one of the things we have to do when revising
specifications is to clear up ambiguities that lead to interoperability
problems. Failure to do so would lead to the specification not meeting the
requirements for standards track advancement.

> Personally, I feel that this requirement of RFC2822 should have be a
> "SHOULD", not a "MUST".

A SHOULD would not have solved the interoperability problem. The viable choices
here were to either allow multiple fields and require them to be handled in a
fashion that's no different than a single field or disallow multiple fields.
Given that RFC 822 discouraged the use of multiple fields it seems clear that
the latter is the way to go.

				Ned

From: [email-masked]
Date: Tue, 29 May 2001 06:40:17 -0700 (PDT)
Subject: Re: CRs in messages
To: Paul Smith <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > > I can't see how this can be worse than just expecting the standard line
> > > terminators all the time -

> > The altnerative that works better is to provide an option that lets you
> > unconditionally accept bare CR or LF as a terminator. Basing the decision on
> > what's used in commands offered no advantage over insisting on CRLF when I
> > tried it.

> I've just this minute seen a bad SMTP server response which makes me wonder
> about all this...

> I send a remote MTA a 'EHLO my.server.com' command and it responds with:

> 250-OK<CR><CR><LF>
> 250-SIZE 3072000<CR><CR><LF>
> 250 8BITMIME<CR><LF>

> Unsurprisingly this upsets things as <CR><CR><LF> isn't a line terminator
> our MTA recognises at the moment... (It sees <CR><CR> and says 'oh, this is
> an MTA which uses bare <CR>s as line terminators, so it has a blank line in
> the response). It's not consistent even then, because normal responses use
> <CR><LF> it only seems to be the multiline responses which use <CR><CR><LF>

Indeed, this is one of the cases I was thinking of when I suggested that
determining what terminators are active based on initial behavior isn't a good
idea.

> (The remote MTA is at mail.commerceqld.com.au if anyone wants to look..)

Yes, and at many other addresses as well. This is a *very* popular and widely
deployed server.

> I wonder how much time 'good' MTA developers put in around the world to be
> able to handle all the situations caused by 'bad' MTA developers..

If memory serves, I first spotted this one about two years ago. Several
things became clear almost immediately:

(a) The problem was going to be widespread.
(b) The problem wasn't going to be fixed in a timely fashion.
(c) It was limited to status responses.
(d) Changing more general line terminator settings to deal with it wasn't a
    great idea.

As a result I implemented a very specific fix to deal with this problem that
didn't change terminator handling in other cases. Sites could deal with this
problem while still, if they decided to, accepting bare CR, bare LF, or both as
terminators elsewhere. It only took a few minutes to implement.

Since then I've spent far more time talking about the problem than I ever did
analyzing it and fixing it.

				Ned

Date: Tue, 29 May 2001 11:06:15 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: CRs in messages
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

>>I can't see how this can be worse than just expecting the standard line
>>terminators all the time -
>
>The altnerative that works better is to provide an option that lets you
>unconditionally accept bare CR or LF as a terminator. Basing the decision on
>what's used in commands offered no advantage over insisting on CRLF when I
>tried it.

I've just this minute seen a bad SMTP server response which makes me wonder 
about all this...

I send a remote MTA a 'EHLO my.server.com' command and it responds with:

250-OK<CR><CR><LF>
250-SIZE 3072000<CR><CR><LF>
250 8BITMIME<CR><LF>

Unsurprisingly this upsets things as <CR><CR><LF> isn't a line terminator 
our MTA recognises at the moment... (It sees <CR><CR> and says 'oh, this is 
an MTA which uses bare <CR>s as line terminators, so it has a blank line in 
the response). It's not consistent even then, because normal responses use 
<CR><LF> it only seems to be the multiline responses which use <CR><CR><LF>

(The remote MTA is at mail.commerceqld.com.au if anyone wants to look..)

I wonder how much time 'good' MTA developers put in around the world to be 
able to handle all the situations caused by 'bad' MTA developers..

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Tue, 29 May 2001 10:36:02 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: CRs in messages
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

>>But surely, the thing is that if all the other MTA/MUAs are working
>>correctly, then they'll be sending the line terminators as CRLF, so if you
>>expect CRLF then you are obeying the standards. If the other MTA/MUAs
>>aren't working correctly, then they will either send commands with CR or LF
>>terminators in which case you can then set your MTA to expect ANY line
>>terminators, or it will send commands with a CRLF in which case you have
>>the fallback that you can point the finger at the other person's software
>>and say that it's not behaving correctly.
>
>>I can't see how this can be worse than just expecting the standard line
>>terminators all the time -
>
>The altnerative that works better is to provide an option that lets you
>unconditionally accept bare CR or LF as a terminator. Basing the decision on
>what's used in commands offered no advantage over insisting on CRLF when I
>tried it.

I think we're going to have 3 options - (a) be strict, (b) 'automatic' (the 
server tries to guess somehow), (c) be flexible. That should make everyone 
happy ;-)

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Mon, 28 May 2001 23:52:35 -0700
To: Kazu Yamamoto <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: limitation of the number of To: (and Cc:)
Cc: [email-masked]
Sender: [email-masked]

Yamamoto-san,

At 11:15 PM 5/28/2001, Kazu Yamamoto wrote:
>Reading RFC2822, I realized that I should modify my mail reader to
>combine addresses to a single To: field as you said, Ned.
>
>I needed to know why RFC2822 made such a change before implementing
>it.

Forgive me, but the discussion of the reason for a particular choice is 
entirely separate from the decision to implement a standard.  An 
implementor does not pick and choose the parts of a standard that they 
like.  Either they implement the standard or they do not.

However it is always helpful to understand reasons.  I'll offer my own 
understanding of the reason for this, specific choice:  RFC 822 stated that 
the interpretation of multiple address headers, of the same type.  Hence 
there has never been a 'standard' definition for the meaning of multiple 
headers.  This sort of flexibility in a standard invites differences in 
implementation behavior.  And THAT invites non-interoperability.

There is no real benefit in having this bit of flexibility, so it is better 
for interoperability to eliminate it.  The less choice a programmer has, 
the more likely their software will interwork with others.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Mon, 28 May 2001 23:32:14 -0700
To: Kazu Yamamoto <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: limitation of the number of To: (and Cc:)
Cc: [email-masked]
Sender: [email-masked]

At 10:22 PM 5/28/2001, Kazu Yamamoto wrote:
> > You say there are "many messages" with multiple To: and Cc: fields.
> > What clients are producing these?
>
>I can enumerate three types:

Yamamoto-san,

You enumerated theoretical possibilities.  There are many ways to generate 
multiple address fields. Shellscripts can be made to do any legal or 
illegal behavior.  They are not packaged user agents.

However the request was for the names of existing UAs that do this today.

The question is about user agent products (commercial or non-commercial).

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Tue, 29 May 2001 15:15:24 +0900 (JST)
To: [email-masked]
Subject: Re: limitation of the number of To: (and Cc:)
From: Kazu Yamamoto <[email-masked]>
Sender: [email-masked]

From: [email-masked]
Subject: Re: limitation of the number of To: (and Cc:)

> Not necessarily; the agent is free to combine all the To: addresses
> into a single To: field and all the Cc: addresses into a single Cc: field.
> The user agents I am familiar with do this.

The background of my question: my mail reader doesn't combile
addresses even if there are multiple To: fields. I think this is
conformant to RFC822.

Reading RFC2822, I realized that I should modify my mail reader to
combine addresses to a single To: field as you said, Ned.

I needed to know why RFC2822 made such a change before implementing
it.

Personally, I feel that this requirement of RFC2822 should have be a
"SHOULD", not a "MUST".

> Or perhaps you're confusing the idea of a multiple fields with multiple
> addresses? Multiple addresses in a single field are fine, multiple fields are
> not.

I think I'm not confusing.

--Kazu

From: [email-masked]
Date: Mon, 28 May 2001 22:57:55 -0700 (PDT)
Subject: Re: limitation of the number of To: (and Cc:)
To: Kazu Yamamoto <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> From: Pete Resnick <[email-masked]>
> Subject: Re: limitation of the number of To: (and Cc:)

> > You say there are "many messages" with multiple To: and Cc: fields.
> > What clients are producing these?

> I can enumerate three types:

> (1) Consider a UA which allows a user to set Cc: field optionally. A
>     user may always uses the option for backup. That is, all message
>     which he sends will come back to him thanks to Cc:.

>     Such a UA generates another Cc: field (and To: field) when
>     replying. Note the Cc: field above is optional.

Not necessarily; the agent is free to combine all the To: addresses
into a single To: field and all the Cc: addresses into a single Cc: field.
The user agents I am familiar with do this.

Or perhaps you're confusing the idea of a multiple fields with multiple
addresses? Multiple addresses in a single field are fine, multiple fields are
not.

> (2) Consider a UA which allows a user to edit the header of a draft
>     message. (UAs on Emacs, for example.) With such a UA, a user may
>     write multiple To:/Cc: fields.

Again, the multiple addresses can be combined onto single fields. And again the
user agents I'm familiar with do this.

> (3) Some shell scripts generate a message which contains multiple To:,
>     one address by one To: field.

I can see how a naive shell script might do this; the solution is not
to use such naive scripts.

				Ned

Date: Tue, 29 May 2001 14:22:24 +0900 (JST)
To: [email-masked]
Subject: Re: limitation of the number of To: (and Cc:)
From: Kazu Yamamoto <[email-masked]>
Sender: [email-masked]

From: Pete Resnick <[email-masked]>
Subject: Re: limitation of the number of To: (and Cc:)

> You say there are "many messages" with multiple To: and Cc: fields. 
> What clients are producing these?

I can enumerate three types:

(1) Consider a UA which allows a user to set Cc: field optionally. A
    user may always uses the option for backup. That is, all message
    which he sends will come back to him thanks to Cc:.

    Such a UA generates another Cc: field (and To: field) when
    replying. Note the Cc: field above is optional.

(2) Consider a UA which allows a user to edit the header of a draft
    message. (UAs on Emacs, for example.) With such a UA, a user may
    write multiple To:/Cc: fields.

(3) Some shell scripts generate a message which contains multiple To:,
    one address by one To: field.

--Kazu

From: [email-masked]
Date: Mon, 28 May 2001 18:19:36 -0700 (PDT)
Subject: Re: CRs in messages
To: Paul Smith <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > > > The MTA is one we wrote ourselves, so we'll add an option to it to either
> > > > accept ONLY CRLF as line terminators in messages (the new default) or
> > > > accept any combination of LF, CR, CRLF (or even LFCR which we've seen in
> > > > one instance from an MUA a couple of years ago..)
> > > >
> > > > We may make this a bit smarter in the future. One thing we've spotted in
> > > > this case is that the message header is all formatted correctly, but the
> > > > message body has bare CRs in it, so we may say that if the header is
> > > > correct then we'll assume the rest of the message should be, but if the
> > > > header uses just CRs or just LFs then we'll assume the rest of the
> > message
> > > > is the same as well.
> >
> > > One technique I've seen mentioned in a previous thread about this, and
> > > which at least looks as if it should work well, was to look at the SMTP
> > > commands the client sends.
> >
> >I've used this technique in the past. It did not work well in practice.
> >In many implementations message and command handling are largely divorced
> >from each other, and when one is broken it isn't predictable by looking
> >at the other.

> But surely, the thing is that if all the other MTA/MUAs are working
> correctly, then they'll be sending the line terminators as CRLF, so if you
> expect CRLF then you are obeying the standards. If the other MTA/MUAs
> aren't working correctly, then they will either send commands with CR or LF
> terminators in which case you can then set your MTA to expect ANY line
> terminators, or it will send commands with a CRLF in which case you have
> the fallback that you can point the finger at the other person's software
> and say that it's not behaving correctly.

> I can't see how this can be worse than just expecting the standard line
> terminators all the time -

The altnerative that works better is to provide an option that lets you
unconditionally accept bare CR or LF as a terminator. Basing the decision on
what's used in commands offered no advantage over insisting on CRLF when I
tried it.

> I don't see that there's a 'perfect' solution to this, except for everyone
> doing everything totally according to the standards, and I don't think
> that'll ever happen...

You're right, it won't. The only way I've found that works is to
provide an option that lets people configure what they want to allow.

> Maybe the best thing to do is just to disobey the 'be flexible in what you
> receive' idea, and just reject anything which has incorrect line
> terminators - at least that might put pressure on people to use the proper
> ones... :-)

Even this doesn't work well, since you can't find the end of a message
reliably to report the error.

				Ned

Date: Mon, 28 May 2001 23:49:33 +0100
To: [email-masked], [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: CRs in messages
Cc: [email-masked]
Sender: [email-masked]

> > > The MTA is one we wrote ourselves, so we'll add an option to it to either
> > > accept ONLY CRLF as line terminators in messages (the new default) or
> > > accept any combination of LF, CR, CRLF (or even LFCR which we've seen in
> > > one instance from an MUA a couple of years ago..)
> > >
> > > We may make this a bit smarter in the future. One thing we've spotted in
> > > this case is that the message header is all formatted correctly, but the
> > > message body has bare CRs in it, so we may say that if the header is
> > > correct then we'll assume the rest of the message should be, but if the
> > > header uses just CRs or just LFs then we'll assume the rest of the 
> message
> > > is the same as well.
>
> > One technique I've seen mentioned in a previous thread about this, and
> > which at least looks as if it should work well, was to look at the SMTP
> > commands the client sends.
>
>I've used this technique in the past. It did not work well in practice.
>In many implementations message and command handling are largely divorced
>from each other, and when one is broken it isn't predictable by looking
>at the other.

But surely, the thing is that if all the other MTA/MUAs are working 
correctly, then they'll be sending the line terminators as CRLF, so if you 
expect CRLF then you are obeying the standards. If the other MTA/MUAs 
aren't working correctly, then they will either send commands with CR or LF 
terminators in which case you can then set your MTA to expect ANY line 
terminators, or it will send commands with a CRLF in which case you have 
the fallback that you can point the finger at the other person's software 
and say that it's not behaving correctly.

I can't see how this can be worse than just expecting the standard line 
terminators all the time - except in the rare case when the other MTA/MUA 
will be sending incorrect line terminators to commands, correct line 
terminators in data AND the message contains raw LFs or CRs. In this case 
it's still the other person's software which is behaving incorrectly and 
your attempt to accept its incorrect data is just not catching every 
possibility. In my experience, most MTAs use the same terminators for 
commands and in the message data and for the message terminator.

I don't see that there's a 'perfect' solution to this, except for everyone 
doing everything totally according to the standards, and I don't think 
that'll ever happen...
Checking for a CR.CR as the last data received at the point of a timeout is 
a possibility, but as I've said it will stop any 'intelligent' MUA 
behaviour such as MIME decoding/recoding on messages containing CR line 
terminators.
If you always check for CRLF as the message terminator except at a timeout, 
but allow any line terminator in the body of a message, then, as well as 
introducing complexity, it means that message data may be 'corrupted' if 
there are bare CRs or LFs in the middle of a message.

Maybe the best thing to do is just to disobey the 'be flexible in what you 
receive' idea, and just reject anything which has incorrect line 
terminators - at least that might put pressure on people to use the proper 
ones... :-)

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: 27 May 2001 14:16:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Mailing list addition of resent headers
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

"Why MIME has a bad name":

[email-masked] (Jacob Palme)  wrote on 26.05.01 in <p05100309b7352e7bdd01@[130.237.150.141]>:

> Our mail system displays three radio buttons in the reply-writing
> window. The buttons are labelled "Reply to the forum", "Reply to all"
> and "Reply to author only". In addition, the user can specify explicitly
> exactly the recipients.
>
> See this picture of our user interface:
>
>
>
> The problem is that you have to have a default value, unless you
> force users to answer an extra question every time they enter
> a reply. And there is no good default value in this case.

No comment necessary, I think.

MfG Kai

Date: Sat, 26 May 2001 19:33:07 -0500
To: Kazu Yamamoto <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: limitation of the number of To: (and Cc:)
Cc: [email-masked]
Sender: [email-masked]

On 5/26/01 at 11:21 AM +0900, Kazu Yamamoto wrote:

>I have one question about RFC2822. It defines the number of To:
>(or Cc:) zero minimum, one maximum.
>
>In practice, there are so many messages which contains two or more To:
>(or Cc:).
>
>Could you tell me the background of this limitation?

1. It is unnecessary to have more than one To: or Cc: fields in a 
message since all addresses can be put into one. If the line is too 
long, folding can be used.

2. There are MUAs (I know of one particularly well!) which ignore 
multiple occurrences of these fields when using the "Reply to all" 
command or when doing filtering and do not recognize the addresses in 
the extra ones.

You say there are "many messages" with multiple To: and Cc: fields. 
What clients are producing these?

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: [email-masked]
Date: Sat, 26 May 2001 13:57:15 -0700 (PDT)
Subject: Re: CRs in messages
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> [email-masked] (Paul Smith)  wrote on 22.05.01 in <[email-masked]>:

> > The MTA is one we wrote ourselves, so we'll add an option to it to either
> > accept ONLY CRLF as line terminators in messages (the new default) or
> > accept any combination of LF, CR, CRLF (or even LFCR which we've seen in
> > one instance from an MUA a couple of years ago..)
> >
> > We may make this a bit smarter in the future. One thing we've spotted in
> > this case is that the message header is all formatted correctly, but the
> > message body has bare CRs in it, so we may say that if the header is
> > correct then we'll assume the rest of the message should be, but if the
> > header uses just CRs or just LFs then we'll assume the rest of the message
> > is the same as well.

> One technique I've seen mentioned in a previous thread about this, and
> which at least looks as if it should work well, was to look at the SMTP
> commands the client sends.

I've used this technique in the past. It did not work well in practice.
In many implementations message and command handling are largely divorced
from each other, and when one is broken it isn't predictable by looking
at the other.

				Ned

Date: Sat, 26 May 2001 12:03:21 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: Mailing list addition of resent headers
Sender: [email-masked]

--============_-1221250205==_mr============
Content-Type: multipart/alternative; boundary="============_-1221250205==_ma============"

--============_-1221250205==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 15.22 +0200 01-05-25, Kai Henningsen wrote:
>I still like my idea to give a labelled list of possible reply targets, 
>from which the user could select. Some of these might be standardized, 
>others might only make sense for a specific message.

Our mail system displays three radio buttons in the reply-writing
window. The buttons are labelled "Reply to the forum", "Reply to all"
and "Reply to author only". In addition, the user can specify explicitly
exactly the recipients.

See this picture of our user interface:

The problem is that you have to have a default value, unless you
force users to answer an extra question every time they enter
a reply. And there is no good default value in this case.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/
--============_-1221250205==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Mailing list addition of resent
headers</title></head><body>
<div>At 15.22 +0200 01-05-25, Kai Henningsen wrote:</div>
<blockquote type="cite" cite>I still like my idea to give a labelled
list of possible reply targets,&nbsp;<br>
from which the user could select. Some of these might be
standardized,&nbsp;<br>
others might only make sense for a specific message.</blockquote>
<div><br></div>
<div>Our mail system displays three radio buttons in the
reply-writing</div>
<div>window. The buttons are labelled &quot;Reply to the forum&quot;,
&quot;Reply to all&quot;</div>
<div>and &quot;Reply to author only&quot;. In addition, the user can
specify explicitly</div>
<div>exactly the recipients.</div>
<div><br></div>
<div>See this picture of our user interface:</div>
<div><br></div>
<div><img src="cid:p05100309b7352e7bdd01@[130.237.150.141].1.0"></div>
<div><br></div>
<div>The problem is that you have to have a default value, unless
you</div>
<div>force users to answer an extra question every time they
enter</div>
<div>a reply. And there is no good default value in this case.</div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div>Jacob Palme &lt;[email-masked]&gt; (Stockholm University and
KTH)<br>
for more info see URL: http://www.dsv.su.se/jpalme/</div>
</body>
</html>
--============_-1221250205==_ma============--
--============_-1221250205==_mr============
Content-Id: <p05100309b7352e7bdd01@[130.237.150.141].1.0>
Content-Type: image/gif; name="010526-reply.gif"
 ; x-mac-type="47494666"
 ; x-mac-creator="3842494D"
Content-Disposition: attachment; filename="010526-reply.gif"
Content-Transfer-Encoding: base64

--============_-1221250205==_mr============--

Date: Sat, 26 May 2001 11:21:07 +0900 (JST)
To: [email-masked]
Subject: limitation of the number of To: (and Cc:)
From: Kazu Yamamoto <[email-masked]>
Sender: [email-masked]

Hello,

I have one question about RFC2822. It defines the number of To:
(or Cc:) zero minimum, one maximum. 

In practice, there are so many messages which contains two or more To:
(or Cc:).

Could you tell me the background of this limitation?

--Kazu

From: Keith Moore <[email-masked]>
To: [email-masked] (Kai Henningsen)
cc: [email-masked]
Subject: Re: Mailing list addition of resent headers 
Date: Fri, 25 May 2001 14:26:00 -0400
Sender: [email-masked]

> I still like my idea to give a labelled list of possible reply targets,
> from which the user could select.

might be worth considering.  but the person composing the reply might 
still want to override the options presented by original author and/or
list.

Keith

Date: 25 May 2001 15:45:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
cc: [email-masked]
Subject: Re: CRs in messages
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Paul Smith)  wrote on 22.05.01 in <[email-masked]>:

> The MTA is one we wrote ourselves, so we'll add an option to it to either
> accept ONLY CRLF as line terminators in messages (the new default) or
> accept any combination of LF, CR, CRLF (or even LFCR which we've seen in
> one instance from an MUA a couple of years ago..)
>
> We may make this a bit smarter in the future. One thing we've spotted in
> this case is that the message header is all formatted correctly, but the
> message body has bare CRs in it, so we may say that if the header is
> correct then we'll assume the rest of the message should be, but if the
> header uses just CRs or just LFs then we'll assume the rest of the message
> is the same as well.

One technique I've seen mentioned in a previous thread about this, and  
which at least looks as if it should work well, was to look at the SMTP  
commands the client sends.

If those are terminated with CRLF, probably so will the rest of the  
exchange; similar for naked CR or LF. What's more, in this case you can  
argue that you *only* use the different behaviour after seeing clearly  
incorrect client behaviour, so a correct client can never run afoul of  
that behaviour.

You could even tell the client, so someone developing a new client will  
notice early he's doing something wrong. Maybe like this:

220 foo.com MTA here
HELO bad.client.org
250 I see you're using naked CRs, which is a bug; I'll try to compensate (but see RFC 2821!)

(Keep it on one line: buggy clients may have more than one bug, and  
another might be inability to cope with multiline respondes.)

MfG Kai

Date: 25 May 2001 15:22:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Mailing list addition of resent headers
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Keith Moore)  wrote on 22.05.01 in <[email-masked]>:

> > >there are lots of ways to describe the difficulty with getting a reply
> > >behavior that satisfies everybody.  for one thing, I don't think we've
> > >even come close to getting consensus on what is "proper", much less
> > >getting agreement on a protocol that encourages such behavior.
> >
> > most of the discussions have been limited to existing mechanisms.  that
> > will never be satisfactory.
>
> well, DRUMS was constrained by charter to only discuss existing mechanisms.
> I agree that we won't solve the list reply problem (or any of the other
> reply problems) in this way.
>
> a number of extension mechanisms have also been discussed, but most of them
> were overly simplistic.

I still like my idea to give a labelled list of possible reply targets,  
from which the user could select. Some of these might be standardized,  
others might only make sense for a specific message.

That's not a lot different from the mechanism some MUAs already use, which  
is to present some sort of list of all the addresses found in the header,  
plus one or two default choices (as in, "personal reply" and "reply to  
all").

One possibility to do that would be a Reply-Targets: header with a list of  
group addresses, like this:

Reply-Targets:
        list-submit:       [email-masked];
        list-bot:          [email-masked];
        list-owner:        [email-masked];
        conference-papers: [email-masked];
        list-abuse:        [email-masked];
        rfc-editor:        [email-masked];

MfG Kai

Date: Fri, 25 May 2001 10:06:09 +0100
From: leo vegoda <[email-masked]>
To: Jacob Palme <[email-masked]>
Cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: Use of List- headers in MUAs
Reply-To: leo vegoda <[email-masked]>
Organisation: Krill Protection League
Sender: [email-masked]

On Thu, May 24, 2001 at 06:30:54PM +0200, Jacob Palme ([email-masked]) wrote: Re: Use of List- headers in MUAs

[...]

> Here are my ideas on how a good MUA could interpret
> LIST-headers:
> 
> The MUA should keep a data base of all mailing lists,
> whose names have occurred in incoming List-headers.
> Possibly, there might be a procedure to remove old
> items which have not been seen recently from this
> list.
> 
> The MUA should in some way ask the user, whether the
> user wants to join mailing lists on this list.

I like the idea to an extent. I think it would be very important
that any standard requiring this of MUAs also guaranteed a way
to get an address removed from a List. 

I can already see abuse of the List header by advertisers. 
Coupled with a six year old that likes clicking on buttons in a 
GUI MUA you've got a recipe for disaster.

[...]

> The MUA should provide commands for joining and
> leaving mailing lists, based on the list of known

I've seen this feature in an MUA before. I agree that it is
an excellent idea. 

Regards,

-- 
leo vegoda
"One size never fits all"
RFC1925 - The Twelve Networking Truths

Date: Thu, 24 May 2001 14:27:35 -0500
To: Jacob Palme <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Use of List- headers in MUAs
Cc: IETF mailing list on MIME and e-mail  <[email-masked]>
Sender: [email-masked]

On 5/24/01 at 6:30 PM +0200, Jacob Palme wrote:

>At 15.27 -0700 01-05-22, Dave Crocker wrote:
>>GENERATING the headers is not the question.  Getting user agents to 
>>notice them and use them constructive is the challenge.
>
>A very important statement. Could we have some discussion
>of this? I know that UA behaviour is often not standardized
>by IETF, but in this case we might achieve better future
>mailers by discussing this.
>
>Here are my ideas on how a good MUA could interpret
>LIST-headers:

I am in the process of trying to convince the-powers-that-be to do a 
beta release of something we've had "on deck" for some period of 
time. It does all of these things.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 24 May 2001 14:12:13 -0500
To: Jacob Palme <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Mailing list addition of resent headers
Cc: ietf-822 <[email-masked]>
Sender: [email-masked]

On 5/24/01 at 6:42 PM +0200, Jacob Palme wrote:

>If an automatic user agent action could reintroduce a message 
>without its previous "Received" headers...

Who said anything about not preserving Received headers? They should 
always be preserved, by an automatic user agent or otherwise.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 24 May 2001 18:50:51 +0200
To: Keith Moore <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: what's a good format for sending messages to a moderator?
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 16.38 -0400 01-05-23, Keith Moore wrote:
>or, since my guess is that there isn't a way to do this that is supported
>by existing user agents,  perhaps a better question is this: would it
>be worthwhile to define a standard profile of MIME to be used when
>forwarding a message to a moderator for approval, and to send the message,
>once approved, back to the list?  would UA authors support such a thing?

For LISTSERV, the moderator just ignores the unacceptable
messages. For the acceptable messages, the moderator just
replies with a message with the single word "OK" in the
text. LISTSERV then gets the code of the transaction
from the subject.

This method in LISTSERV makes it easy for the moderator.
Any new standard for this should not make it more difficult.
And the new standard should work also for moderators, whose
MUA have not been adapted to the new standard.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 24 May 2001 18:42:48 +0200
To: Pete Resnick <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Mailing list addition of resent headers
Cc: ietf-822 <[email-masked]>
Sender: [email-masked]

At 09.40 -0500 01-05-23, Pete Resnick wrote:
>This probably confirms my above suspicion: Adding Received fields is 
>something that is done in the transport system (i.e., a 2821 
>operation). Yes, when you resend and add Resent-* fields, you then 
>introduce the message back into the transport system and it's going 
>to add Received fields. However, adding Received fields is not part 
>of "the process" of resending.
>
>The sematics of the Resent-* fields are: "I 
>(Resent-From/Resent-Sender) got this message and I am resending it 
>to you (Resent-To). I resent it at such-and-so-time (Resent-Date) 
>and I also sent copies of it some other people (Resent-Cc), even 
>some people I may not be telling you about (Resent-Bcc). An 
>identifier for the resending of this message is blah-blah-blah 
>(Resent-Message-ID). The message itself was sent by X (From) to Y 
>(To) and A, B, & C (Cc/Bcc) at some-time (Date)." If you can't 
>figure out who the "I" and the "you" are, chances are Resent-* 
>fields are not appropriate.

Some mailing lists used the "Received" headers to recognize and
stop loops. If an automatic user agent action could reintroduce
a message without its previous "Received" headers, then this
loop control mechanism would fail. There are other loop control
methods which would still work, such as keeping a history of
the Message-ID of recently expanded messages. Some advanced
mailing list servers also recognize the same message even
if its Message-ID has changed. My guess is that they employ
some kind of intelligent checksum on the content of expanded
messages in a data base.

This might be a reason to say that MUAs should not do any
automatic resends of this kind, and without preserving the
incoming "Received" headers.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 24 May 2001 18:48:15 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: what's a good format for sending messages to a moderator?
Sender: [email-masked]

At 16.38 -0400 01-05-23, Keith Moore wrote:
>the question is: what format for such messages is the most compatible
>with various user agents - to allow them to review the message and send
>it back to the list if approved?

The subject of the questionable message should be in the
subject of the message to the moderator. This is important,
because then the moderator can disapprove messages with
subjects such as "Get your Viagra Online Now !!!" or
"FREE SUNGLASSES as seen in McCall's Magazine" without
having to even open the message.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 24 May 2001 18:30:54 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Use of List- headers in MUAs
Sender: [email-masked]

At 15.27 -0700 01-05-22, Dave Crocker wrote:
>GENERATING the headers is not the question.  Getting user agents to 
>notice them and use them constructive is the challenge.

A very important statement. Could we have some discussion
of this? I know that UA behaviour is often not standardized
by IETF, but in this case we might achieve better future
mailers by discussing this.

Here are my ideas on how a good MUA could interpret
LIST-headers:

The MUA should keep a data base of all mailing lists,
whose names have occurred in incoming List-headers.
Possibly, there might be a procedure to remove old
items which have not been seen recently from this
list.

The MUA should in some way ask the user, whether the
user wants to join mailing lists on this list.
This can be done in different ways. One way would
be to do something similar to the list of new
newsgroups provided by News UAs. I.e. the MUA
might once a day send a message to its user,
listing new mailing lists and asking the user
whether to join them.

The MUA should provide commands for joining and
leaving mailing lists, based on the list of known
mailing lists described above. Possibly, such
a command might also be able to search for and
retrieve mailing list descriptions from the web.

When a user tells his MUA to join a mailing list,
the default behaviour of the MUA should be to set
up a separate folder for each mailing list, and
to set up a filter which filters incoming messages
from this list to that folder. (A user should
of course be able to override this if the user
prefers his personally managed set of filters.)
This is important, because many users who are
not mail experts find it difficult to set up
filters on their own.

Even more user-friendly might be if the MUA
allowed users to sort the list-connected folders
according to personal priority, and read commands
which makes it easy to browse new messages,
folder by folder in the order of priority chosen
by the user.

If we could persuade one of the major players
to implement this, I believe the others will
rapidly follow!
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 24 May 2001 11:23:51 -0400 (EDT)
From: James M Galvin <[email-masked]>
Subject: Re: what's a good format for sending messages to a moderator?
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Well, I don't know about good but I'll tell you what I do.  :-)

When a message needs to be approved for distribution, the message
remains in the email queue on my server.  Three reasons why I think this
is a good thing:

    1. Maintains the integrity of the original message.

    2. I can send warning/delayed messages while the message remains in
       the queue.  As an extension I can also return the message when it
       has been in the queue long enough.  This assume you have a queue
       where a message "sit" until it is released.

    3. I can send reminders to the moderator while the message remains
       in the queue.  As an extension, I can even change who the
       moderator is and start the process again.

What I send to the moderator is a message that is multipart/mixed.  The
first part begins with the command to release the message (but see
below), continues with an explanation of what is happening, and finishes
with the alternate commands (delete, reject, etc.).  The second part is
a copy of the message.  The message is setup so that the envelope from
is NULL and the message from points to where the command must go.  The
explanation includes a pointer to a "help desk."

Moderators typically need only "reply" to the message, make one change
to the command, and the message will be released.  Commands include an
internal identifier for the message and a one-time use token for a
modicum of security.

The change they have to make is change a keyword "no" to be "yes" in the
command.  The reason for this is it never ceases to amaze me the broken
things that mailers do.  I have had experiences where a moderator
message is returned, goes to the command server, but fortunately does no
harm since I require this change.

Jim

On Wed, 23 May 2001, Keith Moore wrote:

    Date: Wed, 23 May 2001 16:38:50 -0400
    From: Keith Moore <[email-masked]>
    To: [email-masked]
    Cc: [email-masked]
    Subject: what's a good format for sending messages to a moderator?
    
    I'm in the process of updating bulk_mailer, and the new version will have
    a lot more ability to redirect messages based on several criteria:
    whether the author is a subscriber, whether the author is on a list of
    people with permission to post, whether there are too many recipient
    addresses in the message header, whether the list address is in the
    message header, and so on.
    
    naturally, one of the options is to forward such messages to a moderator
    who can then decide whether they're really okay for the list.
    
    the question is: what format for such messages is the most compatible
    with various user agents - to allow them to review the message and send
    it back to the list if approved?
    
    or, since my guess is that there isn't a way to do this that is supported
    by existing user agents,  perhaps a better question is this: would it
    be worthwhile to define a standard profile of MIME to be used when
    forwarding a message to a moderator for approval, and to send the message,
    once approved, back to the list?  would UA authors support such a thing?
    
    Keith
    
    p.s. what I'm doing currently is quite simplistic: prepend an
    extra set of headers:
    
    -----------------------------------------------
    To: moderator
    Subject: listname: reason for forwarding to moderator
    Content-Type: message/rfc822
    
    forwarded message goes here
    -----------------------------------------------
    
    and then it's fairly simple for a shell script to strip off those
    headers and remail it back to the list.  but I'm using MH.
    I suspect most folks aren't using an interface that is so easily scripted...

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: "Keith Moore" <[email-masked]>, [email-masked]
Subject: Re: what's a good format for sending messages to a moderator? 
Date: Thu, 24 May 2001 11:03:30 -0400
Sender: [email-masked]

> Best would be if your bulk mailer program maintained a copy of the message
> itself in a unique filename.  Then send a message to the moderator or
> moderators, which has a unique Subject line that includes a unique string.

yes, I'd thought about having bulk_mailer generate a web page for each
such message, and send the moderator a URL of that web page with 
'approve' or 'reject; buttons.

however I'd like to avoid having the mailer keep additional state;
right now it's just a sendmail alias.

From: "Dan Wing" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: what's a good format for sending messages to a moderator?
Date: Thu, 24 May 2001 11:57:51 +0100
Importance: Normal
Sender: [email-masked]

Best would be if your bulk mailer program maintained a copy of the message
itself in a unique filename.  Then send a message to the moderator or 
moderators, which has a unique Subject line that includes a unique string.

Every MUA supports a reply function which preserves the subject line 
(sometimes with a certain limit).

The bulk mailer program can use the subject line to locate the copy of
the original message and inject it to the mailing list if the moderator
approves it.  If the moderator explicitly rejects it, the bulk mailer
program can generate the 'your message was rejected by the moderator'
message.  And if a message isn't accepted or rejected in NNN hours the
bulk mailer could decide to simply forward the message to the mailing
list (under the assumption the moderator is on vacation or otherwise
unavailable).

This works with all UAs, doesn't worry about addition of ">" or 
forwarding headers, etc., and avoids problems with the moderator
censoring a portion of a message, munging which interferes with poorly-
encoded MIME, yadda yadda yadda.

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Keith Moore
> Sent: Wednesday, May 23, 2001 9:39 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: what's a good format for sending messages to a moderator?
> 
> 
> I'm in the process of updating bulk_mailer, and the new version will have
> a lot more ability to redirect messages based on several criteria:
> whether the author is a subscriber, whether the author is on a list of
> people with permission to post, whether there are too many recipient
> addresses in the message header, whether the list address is in the
> message header, and so on.
> 
> naturally, one of the options is to forward such messages to a moderator
> who can then decide whether they're really okay for the list.
> 
> the question is: what format for such messages is the most compatible
> with various user agents - to allow them to review the message and send
> it back to the list if approved?
> 
> or, since my guess is that there isn't a way to do this that is supported
> by existing user agents,  perhaps a better question is this: would it
> be worthwhile to define a standard profile of MIME to be used when
> forwarding a message to a moderator for approval, and to send the message,
> once approved, back to the list?  would UA authors support such a thing?
> 
> Keith
> 
> p.s. what I'm doing currently is quite simplistic: prepend an
> extra set of headers:
> 
> -----------------------------------------------
> To: moderator
> Subject: listname: reason for forwarding to moderator
> Content-Type: message/rfc822
> 
> forwarded message goes here
> -----------------------------------------------
> 
> and then it's fairly simple for a shell script to strip off those
> headers and remail it back to the list.  but I'm using MH.
> I suspect most folks aren't using an interface that is so easily 
> scripted...

Date: Wed, 23 May 2001 17:29:38 -0400
To: [email-masked]
From: Vince Sabio <[email-masked]>
Subject: Re: Resource Records for RFC2919
Sender: [email-masked]

** Sometime around 15:48 -0400 05/13/01, Vince Sabio said:

>I received a question about RFC2919 from a friend of mine who works 
>for a list hosting site. His question is:
>
>>I spoke to the mail guys about implementing RFC2919 compliant header
>>stripping and insertion and they said it would be really easy to do (read:
>>no code change necessary).  The difficult part, however, is the part of
>>the RFC where it talks about extending DNS as the namespace for managing
>>unique list-ids.
>>
>>The RFC doesn't give any specific recommendations about how to implement
>>the resolution of list-ids through DNS.  Do you think that they were
>>envisioning list-id resolution through DNS by smart MUAs?
>>
>>If so, do you have any notion of what type of RR we would use for
>>list-ids?  Should *.list-id.DOMAIN.com be A records with associated MXs?

I went to the RFC authors with this question, and wanted to follow up 
here with their response in case there's interest in application of 
2919:

Date: Mon, 21 May 2001 10:05:49 -0400
To: "Vince Sabio" <[email-masked]>, [email-masked]
From: Rob Chandhok <[email-masked]>
Subject: Re: Resource Records for RFC2919

Vince,

The thrust of RFC2919 was to define the namespace.  We specifically 
did NOT address the use of DNS records for any specific purpose in 
order to get the simple namespace definition through the standards 
process.

It's not clear to me that the right implementation would be an A/MX 
records pair or if there would be some other preferred implementation 
of a "smart list resolver".  For now, I wouldn't even put DNS records 
in place for *.list-id.DOMAIN.

Hope this helps.
Rob

________________________________________________________________________
Vince Sabio                                               [email-masked]

To: [email-masked]
Subject: what's a good format for sending messages to a moderator?
cc: [email-masked]
From: Keith Moore <[email-masked]>
Date: Wed, 23 May 2001 16:38:50 -0400
Sender: [email-masked]

I'm in the process of updating bulk_mailer, and the new version will have
a lot more ability to redirect messages based on several criteria:
whether the author is a subscriber, whether the author is on a list of
people with permission to post, whether there are too many recipient
addresses in the message header, whether the list address is in the
message header, and so on.

naturally, one of the options is to forward such messages to a moderator
who can then decide whether they're really okay for the list.

the question is: what format for such messages is the most compatible
with various user agents - to allow them to review the message and send
it back to the list if approved?

or, since my guess is that there isn't a way to do this that is supported
by existing user agents,  perhaps a better question is this: would it
be worthwhile to define a standard profile of MIME to be used when
forwarding a message to a moderator for approval, and to send the message,
once approved, back to the list?  would UA authors support such a thing?

Keith

p.s. what I'm doing currently is quite simplistic: prepend an
extra set of headers:

-----------------------------------------------
To: moderator
Subject: listname: reason for forwarding to moderator
Content-Type: message/rfc822

forwarded message goes here
-----------------------------------------------

and then it's fairly simple for a shell script to strip off those
headers and remail it back to the list.  but I'm using MH.
I suspect most folks aren't using an interface that is so easily scripted...

Date: Wed, 23 May 2001 10:35:17 -0700
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: Mailing list addition of resent headers
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

At 09:50 AM 5/23/2001, [email-masked] wrote:

>What's the fundamental distinction between an agent redistributing mail
>to a list and another agent forwarding mail to, say, a new email address
>given in a .forward file?  Is it only that the list redistribution
>rewrites the Return-Path: whereas .forward processing doesn't?  Is this
>why you see list redistribution as more of a MUA function than an MTA
>one?

Part of the difficulty of this type of discussion is that there are two, 
very different levels to discuss it at.  One is the low-level machine 
behaviors, such as you are using.  The other is the more architectural 
and/or human/group level.  I prefer the latter because it provides 
conceptual insight and, often, directs a choice more easily and definitively.

If the .forward is simply to get your mail to the "correct" place, making 
the original and final addresses essentially synonyms, then it is more at 
the MTA level.  If the mechanism is used to dispatch mail to someone who is 
my agent, then it will might be more of an MUA-level function, in that the 
intermediary address needs to be noted, long term.

For mailist lists, I think we need to talk in terms of principal 
participants and who (or what) is an explicit part of the public exchange, 
versus who (or what) is a conceptually lower-level connector that should 
best be invisible to the larger process.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Wed, 23 May 2001 12:30:28 -0500
To: ietf-822 <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Fwd: Re: Mailing list addition of resent headers
Sender: [email-masked]

Forwarded with permission. (I would have resent it, but then replies 
wouldn't have gone to the list.)

--- begin forwarded text

Date: Wed, 23 May 2001 09:52:15 +0100 (BST)
From: Charles Lindsey <[email-masked]>
Reply-To: Charles Lindsey <[email-masked]>
Subject: Re: Mailing list addition of resent headers
To: [email-masked]

	On Tue, 22 May 2001 11:17:12 -0500
	Pete Resnick <[email-masked]> said...

>
>  On 5/22/01 at 9:28 AM +0100, Charles Lindsey wrote:
>
>  >OK, so if I go on vacation, and instruct my machine to send my mail
>  >to myself@some-other-domain (I think the sendmail /etc/aliases file
>  >would do it) then the Resent-* fields could be used.
>
>  Well, maybe, but I'm pretty sure no. Ask yourself: What address would
>  go into Resent-From:? Who's doing the resending?

Well it would be [email-masked] if it were done that
way. But I just did a little experiment, and it seems that sendmail
regards itself and its alias file (also any .forward files) as a part of
the transport system, so it just adds appropriate Received headers and
sends it on its way.
>
>  Resent-* fields are really intended for mail that has come out of the
>  transport system and is then re-introduced back into the transport
>  system. That's why they have to be marked with a new originator
>  address (Resent-From), originator date (Resent-Date), etc.

OK, so if it is the user's mail agent (as opposed to the MTA) that has
been instructed to redirect his mail (e.g. it has already been pulled
out of his POP mailbox on some server and arrived on his PC) then the
use of the Resent fields is in order. This does seem to me to be taking
different courses of action, for what the user will perceive as the same
situation, just because of the different ways the mail system has been
implemented/configured.
>
>
>  >So far so good, but I still don't see why mailing list expanders are
>  >forbidden to do this. After all, they do not alter the message in
>  >anyway. There is no "Fwd" in the Subject; the From and To remain the
>  >same (just the envelope that is altered for each recipient).
>
>  Right, it is just the envelope that is changing, and its changing
>  more-or-less mid-transport. Again, since the message isn't being
>  taken and out of the transport system and then put back in, it's
>  probably not appropriate to use Resent-* fields in this case.

But this I do not understand. Surely, mail sent to a majordomo list
manager HAS been taken out of the transport system. Majordomo will
regularly look inside a message, decide whether that particular sender
is allowed to post to the list, decide whether that particular sender
has to have his message reviewed by a moderator, decide whether that (or
all) messages are to have some standard disclaimer added, and so on.
None of that is a usual feature of the transport system.

So clearly Resent could be properly used than, although if there is
some alternative set of List-* headers for the purpose, then that would
be OK too. Problem is that those List-* headers are hidden away in a
not-so-easy-to-find RFC, whereas the Resent-* headers are visible in the
most conspicuous RFC of the lot!

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

--- end forwarded text

-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Mailing list addition of resent headers 
Date: Wed, 23 May 2001 13:19:42 -0400
Sender: [email-masked]

> What's the fundamental distinction between an agent redistributing mail
> to a list and another agent forwarding mail to, say, a new email address
> given in a .forward file?  Is it only that the list redistribution
> rewrites the Return-Path: whereas .forward processing doesn't?  Is this
> why you see list redistribution as more of a MUA function than an MTA
> one?

I don't know whether it is a fundamental distinction, we just recognize
that there's a place for each.  Offhand, I would suggest that

- forwarding is appropriate for a very small # of addresses,
  list handling is more appropriate for a larger number
  (so that for instance the sender of a message to a list doesn't
  get a bounce message for every list member whose mail delivery fails)

- forwarding is appropriate when the relevant addresses are all
  under control of the same person (or of a small # of people)
  (so that changing the destination of error reports is not 
  so much of an issue)

- forwarding is more appropriate for private redistribution than
  for public lists to which anyone may subscribe.

as for the MUA/MTA distinction - many public lists do things like 
munging headers, interpreting message content, and/or filtering 
message content, all of which are arguably UA functions.

Keith

Date: Wed, 23 May 2001 13:14:31 -0400 (EDT)
From: [email-masked]
To: [email-masked]
Subject: Re: Mailing list addition of resent headers
Sender: [email-masked]

Excerpts from transarc.system.ietf-822: 22-May-01 Re: Mailing list
addition o.. Dave Crocker@brandenburg (2337*)

> At 12:57 PM 5/22/2001, Keith Moore wrote:
> > > With respect to mailing lists, I'll partially disagree with Keith.  For
> > > most mailing lists, the list agent is best thought of as a user, in terms
> > > of MTA behavior.
> >
> >treating lists as either "users" or "MTA" inevitably leads to confusion.
> >it's more realistic to say that they are somewhere in between, acting
> >as users at some times and as MTAs in others.

> Hmmm.  Thought my statements were rather more clear than your response 
> indicates:

> With respect to MTAs, a sender and the list represent source and 
> destination points.  Both are user agents, representing the beginning and 
> ending of an MTA sequence.  The same for List and recipients, with the list 
> this time acting as source and recipients acting as, well, recipients.

> Hence, a mailing list distribution causes two, discrete MTA 
> post-transfer-deliver sequences.

> However there is a higher-level process at work, between the original 
> sender and the final recipients.  At this level there is a single 
> transaction, covering the two list-mechanism subordinate transactions.

> The difficulty with creating proper Reply behavior is that our standards 
> mechanism were not designed for this higher-level construct.  It's a bit 
like trying to represent 3 dimensions in 2.

What's the fundamental distinction between an agent redistributing mail
to a list and another agent forwarding mail to, say, a new email address
given in a .forward file?  Is it only that the list redistribution
rewrites the Return-Path: whereas .forward processing doesn't?  Is this
why you see list redistribution as more of a MUA function than an MTA
one?

		Regards,
		Craig

Date: Wed, 23 May 2001 09:40:11 -0500
To: ietf-822 <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Mailing list addition of resent headers
Sender: [email-masked]

[I accidentally sent this directly to Charles. Here it is for the 
rest of the list:]

On 5/22/01 at 9:28 AM +0100, Charles Lindsey wrote:

>OK, so if I go on vacation, and instruct my machine to send my mail 
>to myself@some-other-domain (I think the sendmail /etc/aliases file 
>would do it) then the Resent-* fields could be used.

Well, maybe, but I'm pretty sure no. Ask yourself: What address would 
go into Resent-From:? Who's doing the resending?

Resent-* fields are really intended for mail that has come out of the 
transport system and is then re-introduced back into the transport 
system. That's why they have to be marked with a new originator 
address (Resent-From), originator date (Resent-Date), etc.

What I think you're doing when you use /etc/aliases or a .forward 
file is to simply rewrite the envelope address and send the mail on 
to someplace else without actually taking that message of the 
transport system. That is to say, you're doing a 2821 operation, not 
a 2822 operation. (For example, you're probably *not* going to put on 
the Return-Path field at this point; you're going to wait until final 
delivery.)

>  Presumably each message would also acquire additional Received 
>headers in the process.

This probably confirms my above suspicion: Adding Received fields is 
something that is done in the transport system (i.e., a 2821 
operation). Yes, when you resend and add Resent-* fields, you then 
introduce the message back into the transport system and it's going 
to add Received fields. However, adding Received fields is not part 
of "the process" of resending.

The sematics of the Resent-* fields are: "I 
(Resent-From/Resent-Sender) got this message and I am resending it to 
you (Resent-To). I resent it at such-and-so-time (Resent-Date) and I 
also sent copies of it some other people (Resent-Cc), even some 
people I may not be telling you about (Resent-Bcc). An identifier for 
the resending of this message is blah-blah-blah (Resent-Message-ID). 
The message itself was sent by X (From) to Y (To) and A, B, & C 
(Cc/Bcc) at some-time (Date)." If you can't figure out who the "I" 
and the "you" are, chances are Resent-* fields are not appropriate.

>So far so good, but I still don't see why mailing list expanders are 
>forbidden to do this. After all, they do not alter the message in 
>anyway. There is no "Fwd" in the Subject; the From and To remain the 
>same (just the envelope that is altered for each recipient).

Right, it is just the envelope that is changing, and its changing 
more-or-less mid-transport. Again, since the message isn't being 
taken and out of the transport system and then put back in, it's 
probably not appropriate to use Resent-* fields in this case.

>Certainly I see nothing in RFC2822 to imply this is wrong.

2822 is purposely silent on the issue of mailing lists in general 
because they do all sorts of things that don't fit the standard 
model. (For example, they don't seem to take things out of the 
transport system, yet they introduce things like List-* fields and 
other stuff into the message body.) I agree with Keith that Resent-* 
fields are more appropriate for a user operation and mailing lists 
should do something different if they want to add identifying 
information to message headers.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 23 May 2001 05:18:15 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Mailing list addition of resent headers
Sender: [email-masked]

At 18.23 -0400 01-05-22, Keith Moore wrote:
>no disagreement with any of the above.  I was just saying that the
>generalization "lists are users" has often led to incorrect conclusions,
>even if a list is closer to an MUA than to an MTA.

The problem is that IETF has never made any complete standard
for mailing list behaviour. Some details are mentioned in
some places:

"-request" convention in RFC 2142
"List-" headers in RFC 2369 and RFC 2919
Loop control in RFC 2821
MAIL FROM in RFC 1123

I wrote, two years ago, a document summarizing some commonly
agreed ideas about how mailing lists should work. I have
just written a new version of it and submitted it to IETF
drafts. It has not been announced yet, but you can download
it from http://dsv.su.se/jpalme/ietf/mailing-list-behaviour.txt

This document contains things which cannot go into a standard,
so it could become an informational RFC or a BCP RFC.

I wrote this document mainly as part of an effort to persuade
the developers of FirstClass to modify FirstClass to behave
more in accordance with standards and generally agreed
ideas how things should work. My experience is that
groupware products, like FirstClass, for which e-mail is
not the primary goal of the products, tend more often than
pure e-mail software to do things the wrong way.

In particular, FirstClass converts incoming mail to its
own internal format, and then when the message is sent
out to mail, converts it back to mail format again.
This results in a lot of "header munging", for example
the outgoing message has a FirstClass internal Message-ID
instead of the Message-ID of the incoming message.

The proper way to do this, which we have done in our
own system, is to store the original incoming e-mail.
Even if you show your own users the converted version,
you use the stored, original incoming e-mail as a
basis when sending it out again, and modify this only
in accepted ways (adding "Received" and "List-" headers
when it is sent out to e-mail members of a meeting
in the groupware system, which properly should act
as mailing lists, when seen from Internet mail.)
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, Jacob Palme <[email-masked]>, [email-masked]
Subject: Re: Mailing list addition of resent headers 
Date: Tue, 22 May 2001 18:34:18 -0400
Sender: [email-masked]

> >there are lots of ways to describe the difficulty with getting a reply
> >behavior that satisfies everybody.  for one thing, I don't think we've
> >even come close to getting consensus on what is "proper", much less
> >getting agreement on a protocol that encourages such behavior.
> 
> most of the discussions have been limited to existing mechanisms.  that
> will never be satisfactory.

well, DRUMS was constrained by charter to only discuss existing mechanisms.
I agree that we won't solve the list reply problem (or any of the other
reply problems) in this way.

a number of extension mechanisms have also been discussed, but most of them
were overly simplistic.

hmmm... wonder if I can find my "list of problems with reply" notes...

Keith

Date: Tue, 22 May 2001 15:27:19 -0700
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Mailing list addition of resent headers 
Cc: Keith Moore <[email-masked]>, Jacob Palme <[email-masked]>, [email-masked]
Sender: [email-masked]

At 03:23 PM 5/22/2001, Keith Moore wrote:
>there are lots of ways to describe the difficulty with getting a reply
>behavior that satisfies everybody.  for one thing, I don't think we've
>even come close to getting consensus on what is "proper", much less
>getting agreement on a protocol that encourages such behavior.

most of the discussions have been limited to existing mechanisms.  that 
will never be satisfactory.

> > >there are better ways to do this, such as the List-* fields which are
> > >unambiguously for use by lists.
> >
> > Well, yes, it is always cleaner to invent tailored mechanisms, but they 
> are
> > only practical if the community will use them.  So far, they won't.
>
>I see some adoption of the List-* headers, though not as much as I would like.
>what can we do to encourage them?

GENERATING the headers is not the question.  Getting user agents to notice 
them and use them constructive is the challenge.

Given how few major UA players there are, this should not be that difficult.

Yet it is...

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, Jacob Palme <[email-masked]>, [email-masked]
Subject: Re: Mailing list addition of resent headers 
Date: Tue, 22 May 2001 18:23:23 -0400
Sender: [email-masked]

> At 12:57 PM 5/22/2001, Keith Moore wrote:
> > > With respect to mailing lists, I'll partially disagree with Keith.  For
> > > most mailing lists, the list agent is best thought of as a user, in terms
> > > of MTA behavior.
> >
> >treating lists as either "users" or "MTA" inevitably leads to confusion.
> >it's more realistic to say that they are somewhere in between, acting
> >as users at some times and as MTAs in others.
> 
> Hmmm.  Thought my statements were rather more clear than your response 
> indicates:
> 
> With respect to MTAs, a sender and the list represent source and 
> destination points.  Both are user agents, representing the beginning and 
> ending of an MTA sequence.  The same for List and recipients, with the list 
> this time acting as source and recipients acting as, well, recipients.
> 
> Hence, a mailing list distribution causes two, discrete MTA 
> post-transfer-deliver sequences.
> 
> However there is a higher-level process at work, between the original 
> sender and the final recipients.  At this level there is a single 
> transaction, covering the two list-mechanism subordinate transactions.

no disagreement with any of the above.  I was just saying that the 
generalization "lists are users" has often led to incorrect conclusions, 
even if a list is closer to an MUA than to an MTA.

> The difficulty with creating proper Reply behavior is that our standards 
> mechanism were not designed for this higher-level construct.  It's a bit 
> like trying to represent 3 dimensions in 2.

there are lots of ways to describe the difficulty with getting a reply 
behavior that satisfies everybody.  for one thing, I don't think we've 
even come close to getting consensus on what is "proper", much less
getting agreement on a protocol that encourages such behavior.

> >there are better ways to do this, such as the List-* fields which are
> >unambiguously for use by lists.
> 
> Well, yes, it is always cleaner to invent tailored mechanisms, but they are 
> only practical if the community will use them.  So far, they won't.

I see some adoption of the List-* headers, though not as much as I would like.
what can we do to encourage them?

Keith

Date: Tue, 22 May 2001 14:29:22 -0700
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Mailing list addition of resent headers 
Cc: Jacob Palme <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:57 PM 5/22/2001, Keith Moore wrote:
> > With respect to mailing lists, I'll partially disagree with Keith.  For
> > most mailing lists, the list agent is best thought of as a user, in terms
> > of MTA behavior.
>
>treating lists as either "users" or "MTA" inevitably leads to confusion.
>it's more realistic to say that they are somewhere in between, acting
>as users at some times and as MTAs in others.

Hmmm.  Thought my statements were rather more clear than your response 
indicates:

With respect to MTAs, a sender and the list represent source and 
destination points.  Both are user agents, representing the beginning and 
ending of an MTA sequence.  The same for List and recipients, with the list 
this time acting as source and recipients acting as, well, recipients.

Hence, a mailing list distribution causes two, discrete MTA 
post-transfer-deliver sequences.

However there is a higher-level process at work, between the original 
sender and the final recipients.  At this level there is a single 
transaction, covering the two list-mechanism subordinate transactions.

The difficulty with creating proper Reply behavior is that our standards 
mechanism were not designed for this higher-level construct.  It's a bit 
like trying to represent 3 dimensions in 2.

> > The problem is that the reply behavior violates this, seeming instead to be
> > like forwarding:  replies should go to the list.
>
>replies should go to where the person sending the reply wants them to go.

Ahh, yes.  Thank you for requiring that I be entirely precise:  The 
discussion about replies was about the original sender's preferences and, 
maybe, the the mailing list policy for preferred reply behavior.

Obviously a recipient is always free to ignore the preferences of others 
participating in an exchange.

> > At any rate it might have helped distinguish mailing lists postings from
> > individual postings.
>
>there are better ways to do this, such as the List-* fields which are
>unambiguously for use by lists.

Well, yes, it is always cleaner to invent tailored mechanisms, but they are 
only practical if the community will use them.  So far, they won't.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Jacob Palme <[email-masked]>, [email-masked]
Subject: Re: Mailing list addition of resent headers 
Date: Tue, 22 May 2001 15:57:50 -0400
Sender: [email-masked]

> With respect to mailing lists, I'll partially disagree with Keith.  For
> most mailing lists, the list agent is best thought of as a user, in terms
> of MTA behavior. 

treating lists as either "users" or "MTA" inevitably leads to confusion.  
it's more realistic to say that they are somewhere in between, acting 
as users at some times and as MTAs in others.

> My posting to the list terminates at the list agent, as
> far as the transport service is concerned.  As far as the user-level,
> "human" model, of course the list agent is just an intermediary between the
> author and all the list members.  The members must receive mail that
> appears to be from the author, not from the list.
> 
> The problem is that the reply behavior violates this, seeming instead to be
> like forwarding:  replies should go to the list.

replies should go to where the person sending the reply wants them to go.
this might be any subset of: the author of the subject message, the
reply recipients named by the author of the subject message, the recipients 
named in the header of the subject message, or the list from which the 
message was received.

> At any rate it might have helped distinguish mailing lists postings from
> individual postings.  

there are better ways to do this, such as the List-* fields which are
unambiguously for use by lists.

Keith

Date: Tue, 22 May 2001 20:49:37 +0100
To: Keith Moore <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: CRs in messages
Cc: [email-masked]
Sender: [email-masked]

> > Is it our MTA which is incorrect by interpreting <CR>.<CR> as the same as
> > <CR><LF>.<CR><LF>
> > or is it the sending MTA/MUA which is incorrect by creating a message with
> > <CR>s in it and then not padding the '.'. (Surely if it really wants <CR>
> > characters rather than <CR><LF> line terminators, it should use
> > Quoted-Printable or Base64 encoding, not just put them in there as ASCII
> > 0x0d characters)
>
>your MTA is making a too-liberal application of the "be liberal in what you
>accept" principle.  unfortunately there used to be a lot of MTAs (mostly
>misconfigured sendmails) that would send <LF>.<LF> (not sure about <CR>.<CR>)
>rather than <CR><LF>.<CR><LF>, to terminate the message.  many MTAs adapted
>by accepting any of  <CR> <LF> or <CR><LF> as line terminators.
>
>the sending MUA probably shouldn't be putting bare <CR>s in the message 
>either.
>however, this is perfectly legal in RFC 822.

Thanks to everyone for the feedback.

The MTA is one we wrote ourselves, so we'll add an option to it to either 
accept ONLY CRLF as line terminators in messages (the new default) or 
accept any combination of LF, CR, CRLF (or even LFCR which we've seen in 
one instance from an MUA a couple of years ago..)

We may make this a bit smarter in the future. One thing we've spotted in 
this case is that the message header is all formatted correctly, but the 
message body has bare CRs in it, so we may say that if the header is 
correct then we'll assume the rest of the message should be, but if the 
header uses just CRs or just LFs then we'll assume the rest of the message 
is the same as well.

Thanks

Paul

Date: Tue, 22 May 2001 11:28:06 -0700
To: Jacob Palme <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Mailing list addition of resent headers
Cc: [email-masked]
Sender: [email-masked]

At 02:55 AM 5/22/2001, Jacob Palme wrote:
>One could summarize that if you want people who get the
>forwarded message to respond to you, then use a forward
>facility, including the incoming message in the body of
>a new message. (For some reason, text inclusion is

I believe Ned responded to the "For some reason" statement.

With respect to the initial part of your summary, I believe you have stated 
it correctly.

The difference between Forward and Resend is determined by desired Reply 
behavior.  (More formally, it is determined by who you want the recipient 
to perceive as the author, but thinking in terms of Reply is simple and 
pragmatic.)  Am I communicating to you, but attaching someone else's note, 
for reference.  Or am I merely acting as a connector between that someone 
else and you?

With respect to mailing lists, I'll partially disagree with Keith.  For 
most mailing lists, the list agent is best thought of as a user, in terms 
of MTA behavior. My posting to the list terminates at the list agent, as 
far as the transport service is concerned.  As far as the user-level, 
"human" model, of course the list agent is just an intermediary between the 
author and all the list members.  The members must receive mail that 
appears to be from the author, not from the list.

The problem is that the reply behavior violates this, seeming instead to be 
like forwarding:  replies should go to the list.

So, one could reasonably argue that mailing list agent software should 
use  Resent-, I believe, except that reply behavior still would not be 
correct, some of the time.

At any rate it might have helped distinguish mailing lists postings from 
individual postings.  However support for Resent has tended to be marginal.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: [email-masked]
Date: Tue, 22 May 2001 10:59:42 -0700 (PDT)
Subject: Re: Mailing list addition of resent headers
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> One could summarize that if you want people who get the
> forwarded message to respond to you, then use a forward
> facility, including the incoming message in the body of
> a new message. (For some reason, text inclusion is
> most common, inclusing as a message/rfc822 body part
> is not so common.)

This has not been my experience. I receive roughly the same number of MIME
encapsulated messages as I do text-encapsulated messages. Indeed, I routinely
receive mail that has been MIME forwarded multiple times, and I've seen
real-world cases of messages nested almost a thousand levels deep.

But both of these tend to be overused. In particular, they are often used
when resending would have been a better choice.

				Ned

From: [email-masked]
Date: Tue, 22 May 2001 10:51:24 -0700 (PDT)
Subject: Re: Mailing list addition of resent headers
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> > Then could someone please give an example of a genuine and proper use of
> > the Resent headers that does not amount to "forwarding"?

> 1) I frequently get messages that are intended for someone else.
> There was only one Moore in our department when I started here;
> now there are three Moores in my immediate work group, and people
> often send mail to "moore" without thinking.

> If I forward such a misdirected message to the correct recipient,
> and that person replies,  the reply goes back to me.

> If I resend the message, any reply to that message goes to the
> addresses in the header of the original message.

More generally, cases arise all the time where I get a message I want someone
else to deal with, and when they reply I want the replies to be directed as if
I wasn't involved. Resend works perfectly in such cases. I use this at least
once or twice a week at a minimum and I routinely receive mail from others that
has been resent in this way with this intention.

Of course you have to use a client that provides this capability. It is one of
my absolute client requirements.

> 2) I also get messages that are intended for a mail robot.
> (people sometimes send messages to the list maintainer rather than to
> the list robot).  resend forwards the message to the robot with
> the other headers intact, so the robot does the right thing.

Unfortunately, some robots pay attention to resent- headers when they
shouldn't, so this doesn't work as well as one might hope. Hopefully RFC 2822's
new language describing resent- fields will rectify this.

				Ned

From: [email-masked]
Date: Tue, 22 May 2001 10:21:18 -0700 (PDT)
Subject: Re: CRs in messages
To: Pete Resnick <[email-masked]>
Cc: Keith Moore <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Sender: [email-masked]

> On 5/22/01 at 11:57 AM -0400, Keith Moore wrote:

> >the sending MUA probably shouldn't be putting bare <CR>s in the
> >message either.
> >however, this is perfectly legal in RFC 822.

> And perfectly illegal to send in RFC 2822. They must however be
> interpreted correctly according to section 4.1, and that means not
> interpreting bare CRs as line endings.

A good point I neglected to mention. I brought up MIME primarily to show that
this isn't a prohibition that started with the recent publication of RFC 2822.

				Ned

From: [email-masked]
Date: Tue, 22 May 2001 09:27:29 -0700 (PDT)
Subject: Re: CRs in messages
To: Keith Moore <[email-masked]>
Cc: Paul Smith <[email-masked]>, [email-masked]
Sender: [email-masked]

> > Is it our MTA which is incorrect by interpreting <CR>.<CR> as the same as
> > <CR><LF>.<CR><LF>
> > or is it the sending MTA/MUA which is incorrect by creating a message with
> > <CR>s in it and then not padding the '.'. (Surely if it really wants <CR>
> > characters rather than <CR><LF> line terminators, it should use
> > Quoted-Printable or Base64 encoding, not just put them in there as ASCII
> > 0x0d characters)

> your MTA is making a too-liberal application of the "be liberal in what you
> accept" principle.  unfortunately there used to be a lot of MTAs (mostly
> misconfigured sendmails) that would send <LF>.<LF> (not sure about <CR>.<CR>)
> rather than <CR><LF>.<CR><LF>, to terminate the message.  many MTAs adapted
> by accepting any of  <CR> <LF> or <CR><LF> as line terminators.

I still see <LF>.<LF> on occasion; it used to be extremely common. I've only
seen <CR>.<CR> a couple of times, I think it originated from some fairly
obscure Mac mail systems. I suspect <CR>.<CR> is dead at this point, but of
course there's no way ever to be sure about this stuff.

> the sending MUA probably shouldn't be putting bare <CR>s in the message either.
> however, this is perfectly legal in RFC 822.

But not legal MIME. See RFC 2045, sections 2.7 and 2.8. And while it is true
that MIME is intentionally constructed to be subset of what's allowed by RFC
822, violating it in this way isn't a good idea, regardless of whether or not
you're sending MIME messages.

				Ned

Date: Tue, 22 May 2001 11:29:38 -0500
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: CRs in messages
Cc: Paul Smith <[email-masked]>, [email-masked]
Sender: [email-masked]

On 5/22/01 at 11:57 AM -0400, Keith Moore wrote:

>the sending MUA probably shouldn't be putting bare <CR>s in the 
>message either.
>however, this is perfectly legal in RFC 822.

And perfectly illegal to send in RFC 2822. They must however be 
interpreted correctly according to section 4.1, and that means not 
interpreting bare CRs as line endings.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Keith Moore <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: CRs in messages 
Date: Tue, 22 May 2001 11:57:52 -0400
Sender: [email-masked]

> Is it our MTA which is incorrect by interpreting <CR>.<CR> as the same as
> <CR><LF>.<CR><LF>
> or is it the sending MTA/MUA which is incorrect by creating a message with
> <CR>s in it and then not padding the '.'. (Surely if it really wants <CR>
> characters rather than <CR><LF> line terminators, it should use
> Quoted-Printable or Base64 encoding, not just put them in there as ASCII
> 0x0d characters)

your MTA is making a too-liberal application of the "be liberal in what you
accept" principle.  unfortunately there used to be a lot of MTAs (mostly
misconfigured sendmails) that would send <LF>.<LF> (not sure about <CR>.<CR>) 
rather than <CR><LF>.<CR><LF>, to terminate the message.  many MTAs adapted 
by accepting any of  <CR> <LF> or <CR><LF> as line terminators.

the sending MUA probably shouldn't be putting bare <CR>s in the message either.
however, this is perfectly legal in RFC 822.

Keith

Date: Tue, 22 May 2001 10:19:02 -0400
From: Tony Hansen <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: Re: CRs in messages
Sender: [email-masked]

The simple answer is "your MTA is wrong, but...".

RFC 2822 says only CRLF.CRLF should be accepted as the end of the
message. But some servers in the past would incorrectly use CR.CR or
LF.LF. So you can either refuse to accept their mail or do a workaround.

One of the servers I worked on in the past made the compromise by only
looking for such non-standard termination sequences after the read times
out. In other words, "we're just about to throw the message away because
we timed out without getting the CRLF.CRLF, so let's see if the other
side is screwed up and sending us the wrong termination sequence."

	Tony Hansen
	[email-masked]

Paul Smith wrote:
> 
> I've recently had a problem with our MTA where a message line was received as
> 
> some text<CR><CR><CR>.<CR><CR>
> some more text
> 
> (where the <CR>s are ASCII 0x0d, not '<CR>')
> 
> Our MTA interpreted the <CR>.<CR> as a message terminator, as it assumed
> that the sending MTA was incorrectly using <CR> line terminators instead of
> <CR><LF>. (We've seen some cases where they do that)
> 
> Comments please?
> Is it our MTA which is incorrect by interpreting <CR>.<CR> as the same as
> <CR><LF>.<CR><LF>
> or is it the sending MTA/MUA which is incorrect by creating a message with
> <CR>s in it and then not padding the '.'. (Surely if it really wants <CR>
> characters rather than <CR><LF> line terminators, it should use
> Quoted-Printable or Base64 encoding, not just put them in there as ASCII
> 0x0d characters)
> 
> Paul Smith

From: [email-masked]
Date: Tue, 22 May 2001 06:28:29 -0700 (PDT)
Subject: Re: CRs in messages
To: Paul Smith <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> I've recently had a problem with our MTA where a message line was received as

> some text<CR><CR><CR>.<CR><CR>
> some more text

> (where the <CR>s are ASCII 0x0d, not '<CR>')

> Our MTA interpreted the <CR>.<CR> as a message terminator, as it assumed
> that the sending MTA was incorrectly using <CR> line terminators instead of
> <CR><LF>. (We've seen some cases where they do that)

> Comments please?

> Is it our MTA which is incorrect by interpreting <CR>.<CR> as the same as
> <CR><LF>.<CR><LF>

According to RFC 2822, the answer is yes, your MTA should not be doing this. It
was probably done to interoperate with some broken client in the past. But most
MTAs that do this have controls to adjust the interpretation of bare CRs and
LFs. I suggest you check the documentation for your MTA and see if its
behavior can be adjusted.

> or is it the sending MTA/MUA which is incorrect by creating a message with
> <CR>s in it and then not padding the '.'. (Surely if it really wants <CR>
> characters rather than <CR><LF> line terminators, it should use
> Quoted-Printable or Base64 encoding, not just put them in there as ASCII
> 0x0d characters)

This is also quite true. If you want to use bare CRs you need to encode the
material containing them. Depending on how unencoded text is canonicalized for
local storage you are likely to either lose the CRs completely or have
them converted into CRLFs. So even if the message is successfully received
in its entirety it is likely to be damaged at some point.

				Ned

Date: Tue, 22 May 2001 11:14:22 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: CRs in messages
Sender: [email-masked]

I've recently had a problem with our MTA where a message line was received as

some text<CR><CR><CR>.<CR><CR>
some more text

(where the <CR>s are ASCII 0x0d, not '<CR>')

Our MTA interpreted the <CR>.<CR> as a message terminator, as it assumed 
that the sending MTA was incorrectly using <CR> line terminators instead of 
<CR><LF>. (We've seen some cases where they do that)

Comments please?
Is it our MTA which is incorrect by interpreting <CR>.<CR> as the same as 
<CR><LF>.<CR><LF>
or is it the sending MTA/MUA which is incorrect by creating a message with 
<CR>s in it and then not padding the '.'. (Surely if it really wants <CR> 
characters rather than <CR><LF> line terminators, it should use 
Quoted-Printable or Base64 encoding, not just put them in there as ASCII 
0x0d characters)

Paul Smith

Date: Tue, 22 May 2001 11:55:24 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: Mailing list addition of resent headers
Sender: [email-masked]

One could summarize that if you want people who get the
forwarded message to respond to you, then use a forward
facility, including the incoming message in the body of
a new message. (For some reason, text inclusion is
most common, inclusing as a message/rfc822 body part
is not so common.)

If you want people who get the forwarded message to
respond to the original author, then use Resent-headers.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Mailing list addition of resent headers 
Date: Mon, 21 May 2001 23:41:10 -0400
Sender: [email-masked]

> Then could someone please give an example of a genuine and proper use of
> the Resent headers that does not amount to "forwarding"?

1) I frequently get messages that are intended for someone else.
There was only one Moore in our department when I started here;
now there are three Moores in my immediate work group, and people
often send mail to "moore" without thinking.

If I forward such a misdirected message to the correct recipient, 
and that person replies,  the reply goes back to me.

If I resend the message, any reply to that message goes to the 
addresses in the header of the original message.  

2) I also get messages that are intended for a mail robot.
(people sometimes send messages to the list maintainer rather than to 
the list robot).  resend forwards the message to the robot with
the other headers intact, so the robot does the right thing.

Keith

Date: Mon, 21 May 2001 22:09:51 -0500
To: [email-masked] (Charles Lindsey)
From: Pete Resnick <[email-masked]>
Subject: Re: Mailing list addition of resent headers
Cc: [email-masked]
Sender: [email-masked]

On 5/21/01 at 11:37 AM +0000, Charles Lindsey wrote:

>Then could someone please give an example of a genuine and proper use of
>the Resent headers that does not amount to "forwarding"?

Yes. If Eudora did the right thing, Resent-* fields would be used for 
the "Redirect" command, but not the "Forward" command.

Forwarding creates a new message where the From: field contains the 
person who is doing the forwarding and the To: field is the person 
who gets the forwarded message, the Date: fields is the date the 
message was forwarded, perhaps even the Subject: field starts with 
"Fwd:", etc.. Likely the body of the message contains (at least some) 
of the header fields of the original message.

Resending (where Resent-* fields are used) is when the From:, To:, 
Date:, etc. fields of the resent message all contain what the 
original message contained. The body is the same as the original 
message. What's different is that the resent message doesn't go to 
the person in the To: field, but instead goes to the person in the 
Resent-To: field. That way, replies to the message (if done by most 
MUAs) go to the original author, *not* the resender of the message.

See the difference?

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked]
Xref: clerew local.mime:626
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Mailing list addition of resent headers
Date: Mon, 21 May 2001 11:37:56 GMT
Lines: 19
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>Mailing lists are not "users" and shoudl not add resent-* headers.
>List-* headers exist for mailing lists, but they are defined elsewhere.

Then could someone please give an example of a genuine and proper use of
the Resent headers that does not amount to "forwarding"?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: Mailing list addition of resent headers 
Date: Fri, 18 May 2001 08:31:07 -0400
Sender: [email-masked]

Mailing lists are not "users" and shoudl not add resent-* headers.
List-* headers exist for mailing lists, but they are defined elsewhere.

Date: Fri, 18 May 2001 06:09:15 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Mailing list addition of resent headers
Sender: [email-masked]

RFC2822 says:

    Resent fields are used to identify a message as having been
    reintroduced into the transport system by a user.  The purpose of
    using resent fields is to have the message appear to the final
    recipient as if it were sent directly by the original sender, with
    all of the original fields remaining the same.  Each set of resent
    fields correspond to a particular resending event.  That is, if a
    message is resent multiple times, each set of resent fields gives
    identifying information for each individual time.  Resent fields are
    strictly informational.  They MUST NOT be used in the normal
    processing of replies or other such automatic actions on messages.

    Note: Reintroducing a message into the transport system and using
    resent fields is a different operation from "forwarding".
    "Forwarding" has two meanings: One sense of forwarding is that a mail
    reading program can be told by a user to forward a copy of a message
    to another person, making the forwarded message the body of the new
    message.  A forwarded message in this sense does not appear to have
    come from the original sender, but is an entirely new message from
    the forwarder of the message.  On the other hand, forwarding is also
    used to mean when a mail transport program gets a message and
    forwards it on to a different destination for final delivery.  Resent
    header fields are not intended for use with either type of
    forwarding.

    The resent originator fields indicate the mailbox of the person(s) or
    system(s) that resent the message.  As with the regular originator
    fields, there are two forms: a simple "Resent-From:" form which
    contains the mailbox of the individual doing the resending, and the
    more complex form, when one individual (identified in the
    "Resent-Sender:" field) resends a message on behalf of one or more
    others (identified in the "Resent-From:" field).

    Note: When replying to a resent message, replies behave just as they
    would with any other message, using the original "From:",

Question 1: Does this mean that maling list expanders should,
or should not, add resent-headers? Or does the text allow
either alternative?

Question 2: In case the text allows either alternative, which
is the proper way for a mailing list handled to do? Should it
add resent-headers or not?

From: [email-masked]
Date: Mon, 14 May 2001 13:28:40 -0700 (PDT)
Subject: Re: Is 8BIT ESTMP really needed
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> The mailbot has sddenly stopped accepting posts to the list. This is a
> repost.

> > In <[email-masked]> [email-masked] writes:

> > > What about them? AFAIK there has never been an application type defined which
> > > specified that some sort of line ending canonicalization is to be performed.

> > Or not performed.

> > Surely there are plenty of application types which simply say "this data
> > consists of lines of text in the following format" with the expectation
> > that machines will be able to act on it, and that they will know what the
> > end of a line looks like when they see one (there is a general expectation
> > in the Unix world that lines of text will be terminated by NL, and in the
> > DOS world that they will be terminated by CRLF).

Of course there are, but this doesn't mean that canonicalization rules have
been defined for such types. Lacking such canonicalization rules (or
alternately lacking knowledge of such rules), application content encoded as
quoted-printable or base64 has to be treated as binary; just because you might
be able to switch CR or LF or whatever doesn't mean you're allowed to.

> > Indeed, we defined three such application types in the USEFOR draft with
> > the expectation that the "system" would ensure they went out on the wire
> > with CRLF on them as part of its normal operation (the usual encoding
> > being 8bit). Should we have said more?

No. When you send out something with an encoding of 8bit, you're asserting that
the canonical form of the material is lines terminated by CRLFs. That's all
that's needed -- the correct way to encode this into quoted-printable or base64
is obvious. Now, once you're there you're basically stuck with it when you're
an application type. As I said before, upconversion to 7bit or 8bit is more or
less restricted to text types. (And the concerns that drive the desire
to upconvert only apply to text anyway...)

> > > PDF is pure binary material. There are no line endings in it that
> > > can be safely canonicalized. The same is true of Postscript -- if you
> > > try and canonicalize the line endings in Postscript often as not you'll
> > > break it.

> > As a matter of interest, I checked what Ghostscript did, and it accepted
> > naked CR, naked LF or naked CRLF as the end of a line (which is consistent
> > with the spec. in the Red Book).

You need to read the specifications more carefully before drawing such
conclusions. While it true that trivial programs won't be sensitive to the line
terminator you use (in fact they won't care if you no use no terinators at
all), there are operators that are sensitive to line terminators, either
because they involve character counts or else because they process binary
material. The readstring operator is one such but there are others.

				Ned

Date: Sun, 13 May 2001 15:48:57 -0400
To: [email-masked]
From: Vince Sabio <[email-masked]>
Subject: Resource Records for RFC2919
Sender: [email-masked]

I received a question about RFC2919 from a friend of mine who works 
for a list hosting site. His question is:

>I spoke to the mail guys about implementing RFC2919 compliant header
>stripping and insertion and they said it would be really easy to do (read:
>no code change necessary).  The difficult part, however, is the part of
>the RFC where it talks about extending DNS as the namespace for managing
>unique list-ids.
>
>The RFC doesn't give any specific recommendations about how to implement
>the resolution of list-ids through DNS.  Do you think that they were
>envisioning list-id resolution through DNS by smart MUAs?
>
>If so, do you have any notion of what type of RR we would use for
>list-ids?  Should *.list-id.DOMAIN.com be A records with associated MXs?

I'm going on memory for 2919 (I'm on the road at the moment, with 
only e-mail and WAP access), but I don't recall anything that 
discussed this issue directly. Can anyone comment on this? I'm also 
curious for my own mailing lists, as we are planning to implement 
RFC2919-compliant headers on all the lists.

Thanks,
Vince

Date: Sun, 13 May 2001 15:50:24 +0100 (BST)
From: Charles Lindsey <[email-masked]>
Reply-To: Charles Lindsey <[email-masked]>
Subject: Re: Is 8BIT ESTMP really needed
To: [email-masked]
Content-MD5: Hy04bTH1xr1Q3lwtrP9MRw==
Sender: [email-masked]

The mailbot has sddenly stopped accepting posts to the list. This is a
repost.

>
>In <[email-masked]> [email-masked] writes:
>
>>What about them? AFAIK there has never been an application type defined which
>>specified that some sort of line ending canonicalization is to be performed.
>
>Or not performed.
>
>Surely there are plenty of application types which simply say "this data
>consists of lines of text in the following format" with the expectation
>that machines will be able to act on it, and that they will know what the
>end of a line looks like when they see one (there is a general expectation
>in the Unix world that lines of text will be terminated by NL, and in the
>DOS world that they will be terminated by CRLF).
>
>Indeed, we defined three such application types in the USEFOR draft with
>the expectation that the "system" would ensure they went out on the wire
>with CRLF on them as part of its normal operation (the usual encoding
>being 8bit). Should we have said more?
>
>
>>PDF is pure binary material. There are no line endings in it that 
>>can be safely
>>canonicalized. The same is true of Postscript -- if you try and canonicalize
>>the line endings in Postscript often as not you'll break it.
>
>As a matter of interest, I checked what Ghostscript did, and it accepted
>naked CR, naked LF or naked CRLF as the end of a line (which is consistent
>with the spec. in the Red Book).
>

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: [email-masked]
Date: Thu, 10 May 2001 17:05:02 -0700 (PDT)
Subject: Re: Is 8BIT ESTMP really needed
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> [email-masked] writes:

> > Thus far in this conversation we have one anecdotal report that
> > there may be some systems that botch this, and which may well refer
> > to some long-vanished implementation from the early days of MIME.

> Link to one discussion mentions MUAs but not MTAs:

> http://www.gnus.org/list-archives/ding/199907/msg00657.html

> I don't know if it really was a MUA issue.

According to the discussion it was a issue with Netscape on Windows. But this
is easily verified. I mailed a ~1Mb PDF with embedded color pictures and such
using quoted-printable. I also peeked at the content -- nasty! I then read it
using Netscape 4.77 on a Windows 98 system. It worked fine.

For good measure I tried it using Netscape 4.76 on Mac and Outlook Express 5.02
on Mac. They worked flawlessly as well. I would have tried it with Outlook on
Windows too but I could not figure out how to easily redirect it to a different
mail account.

So either the report was wrong in its particulars or else it is a problem that
has since been fixed. Regardless, the bottom line is that I cannot substantiate
the claim that this is actually a problem.

				Ned

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Is 8BIT ESTMP really needed
From: Simon Josefsson <[email-masked]>
Date: 10 May 2001 19:42:23 +0200
Lines: 13
Sender: [email-masked]

[email-masked] writes:

> Thus far in this conversation we have one anecdotal report that
> there may be some systems that botch this, and which may well refer
> to some long-vanished implementation from the early days of MIME.

Link to one discussion mentions MUAs but not MTAs:

http://www.gnus.org/list-archives/ding/199907/msg00657.html

I don't know if it really was a MUA issue.  I have not seen this
frequently, but I remember similar discussions.  Sorry for not
providing anything more substantial.

From: [email-masked]
Date: Thu, 10 May 2001 09:46:42 -0700 (PDT)
Subject: Re: Is 8BIT ESTMP really needed
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> > The gateways I've worked on that did up/down conversion were very
> > careful to differentiate between QP conversions in text/* parts and
> > anything/else parts. Text parts can make all sorts of assumptions about
> > CRs and LFs, but anything/else parts cannot. For example, the QP that I
> > generate for anything/else parts always uses =0D or =0A for CRs and LFs,
> > and uses soft newlines (=CRLF) after such CRs, LFs or CRLFs (and for
> > splitting apart long lines). This preserves the CRs and LFs while still
> > breaking the lines at the same locations within the attachment.

> OK, it looks as though the "best" servers do it properly, which is good.
> But there is nothing in the RFCs to say it SHOULD be done that way,

On the contrary, the MIME RFCs clearly distinguish between how text and
non-text are encoded in quoted-printable. And while it is true that the RFCs
don't come out and say "don't do things that will obviously completely trash
all sorts of content", it isn't reasonable for standards to try and prohibit
every possible idiotic thing that software could try and do.

As the MIME specifications have been revised over the years various explicit
prohibitions have been added to make it clear that certain types of bogus
behavior are in fact bogus. But such text has only been added when there is
evidence from the field that significant bad things have happened. No such
evidence of bad QP handling or anything similar was reported prior to previous
MIME revisions, so there isn't a specific prohibition against this sort of
idiocy. Simple as that.

Thus far in this conversation we have one anecdotal report that there may be
some systems that botch this, and which may well refer to some long-vanished
implementation from the early days of MIME. We also have at least three reports
from implementors who got it right. Lacking further reports of actual problems,
I believe your concerns qualify as purely academic.

> so I
> daresay there are many servers that won't. I will have to look at what the
> Perl Mail package does.

I suspect that you will find that the practice of upconverting isn't all that
widespread, and that most implementations that do it only do it with text.
Remember, the primary justification for upconversion is to make something
readable on non-MIME enabled software. And such considerations only apply to
text (in fact they likely only apply to text/plain).

				Ned

From: [email-masked]
Date: Thu, 10 May 2001 08:34:37 -0700 (PDT)
Subject: Re: Is 8BIT ESTMP really needed
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> [email-masked] (Charles Lindsey) writes:

> > Suppose your message has Content-Type: application/foo (there is never any
> > problem with text/plain). The body of the message is
> > 	fooCRbarLFbazCRLF
> > (the naked CR and LF are a 'feature' os the application/foo protocol).
> > Suppose you decide to encode it in QP (maybe not the wisest choice, but
> > legal).

> Just a note that there are real examples of this out there:

> Gnus used to (or maybe it still does) encode binary attachments as
> QP/B64 depending on which resulted in the smallest size.  As it
> happened, PDF files often contain lots of ASCII and only a little
> binary data, so it would often be encoded as QP.

And this is an entirely reasonable thing to do.

> In addition of causing problems with QP-encoded binary contents in
> some clients, up/down-conversion of the PDF file sometimes caused the
> content to be unreadable.

Then that's a problem with the conversion. Just because it is encoded using
QP doesn't mean it is text. And you'll find precious little support for any
such view in the MIME RFCs.

> So it's not only an issue of MD5 or digital
> signatures, but of actually being able to transfer the data.  So in
> practice QP seem to be "for text only".

I have not found this to be the case. If anything I've found that the
assumption has been anything encoded cannot be assumed to be text even if the
content type says it is. This can be annoying but doesn't cause problems in
practice.

Now, in the early days of MIME there were a variety of problems with various
encoders and decoders. For example, there was a popular base64 encoder that did
the 3-in-4 thing backwards from everyone else's. I don't recall bogus
upconversion of QP being a problem specifically, but anything is possible. But
most of these early problems have long since been fixed.

Of course it is impossible to prove a negative. And the Internet is so large
that it is quite possible for there to be aberrant behavior in various places
that few if any of us are aware of. But I can say that software I've written
uses exactly the same approach as what you say Gnus uses, that software is in
widespread use, I've personally seen every problem report ever sent to the
vendor regarding this software, and I don't recall any reports of this sort of
problem.

				Ned

From: [email-masked]
Date: Thu, 10 May 2001 07:31:40 -0700 (PDT)
Subject: Re: Is 8BIT ESTMP really needed
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> In <[email-masked]> Keith Moore <[email-masked]> writes:

> >actually I think it's clear (or should be) that the MD5 computation
> >should be completely independent of canonicalization.

> That was the intention of RFC 1864, but unfortunately it does not deliver,
> as its text is written. It provides for all "line endings" to be
> canonicalized into CRLF before computing the hash, but it does not define
> what is or is not a "line ending". For text/* types, that is no problem,
> of course, but what about random application types?

What about them? AFAIK there has never been an application type defined which
specified that some sort of line ending canonicalization is to be performed.

If you're dealing with application data encoded as QP or base64 you can only
upconvert it to binary. If it starts out as 7bit or 8bit you can downconvert to
QP or base64, but once there it isn't going back.

> For some of them, the
> concept of "line ending" is perfectly clear. For others it is not (someone
> mentioned PDF).

PDF is pure binary material. There are no line endings in it that can be safely
canonicalized. The same is true of Postscript -- if you try and canonicalize
the line endings in Postscript often as not you'll break it.

> > that is, even if the canonicalization was done improperly, the MD5 needs
> > to be computed over the form of the body part that exists *after*
> > canonicalization and *prior* to any content-transfer-encoding.

> Yes, but the content-transfer-encoding provides a second opportunity to
> canonicalize LF into CRLF (the encoding engine is likely separate from the
> Copntent-MD5 engine) and so may introduce some CRLFs not appropriate for
> that application type, and strange things may then arise upon upcoding.

No it doesn't. The steps are clear: First canonicalize, then hash, then encode.
Subsequent reencoding can not and in practice does not involve
recanonicalization.

> I think the only safe way is to encode all CRLF in application types as
> =0D=0A, giving
> 	foo=0Dbar=0Abax=0D=0A=CRLF
> thus not relying on the CRLF at the end of the CTE lines for any meaning.

Sure, and this is exactly what implementations do in practice.

> But encoding engines do not currently work this way :-( .

In my experience they most certainly do work this way. The only funkiness I've
ever seen with QP in practice is that sometimes you get text that's encoded
using =0D=0A=CRLF. This isn't by the book, but it doesn't break hashes and
decodes correctly, so why worry about it?

> So it seems to
> me that a Content-MD5 engine (assuming it has no opportunity to alter the
> document, or to influence the encoding) is forced to try and 2nd guess
> what the encoding is going to do (or has already done).

I have seen no need to do this in practice. I check content-md5 hashes all the
time and on the rare occasions when they don't match it is due to something
silly like trailing spaces being removed from text.

				Ned

From: [email-masked]
Date: Thu, 10 May 2001 07:20:55 -0700 (PDT)
Subject: Re: Interpretation of 2822 needed
To: Vince Sabio <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Quick question on RFC2822. Sect. 3.4.1 on address formats states:

>     3.4.1. Addr-spec specification

>     An addr-spec is a specific Internet identifier that contains a
>     locally interpreted string followed by the at-sign character ("@",
>     ASCII value 64) followed by an Internet domain.  The locally
>     interpreted string is either a quoted-string or a dot-atom.  If the
>     string can be represented as a dot-atom (that is, it contains no
>     characters other than atext characters or "." surrounded by atext
>     characters), then the dot-atom form SHOULD be used and the
>     quoted-string form SHOULD NOT be used. Comments and folding white
>     space SHOULD NOT be used around the "@" in the addr-spec.

> To me, this means that the local-part of an address may either be
> quoted or may contain dot-atoms, but may not contain embedded quoted
> substrings.

Correct. Addresses with multiple quoted strings in the local part have proved
to be both useless and an operational nightmare so they are no longer
considered to be valid.

> For example, consider the following address local-parts:

> VALID: vince.sabio

Yes.

> VALID: "vince sabio" (deprecated, but nonetheless valid)

This is valid. But while it may not be an especially good idea to use such
address formats, section 3.4.1 doesn't deprecate them. What's valid but
deprecated is:

  "vince.sabio"

> NOT VALID: vince."human mail server".sabio

Yes, this is no longer valid. (Thank goodness.)

				Ned

Date: Thu, 10 May 2001 08:04:21 -0500
To: Vince Sabio <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Interpretation of 2822 needed
Cc: [email-masked]
Sender: [email-masked]

On 5/10/01 at 2:48 AM -0400, Vince Sabio wrote:

>** Sometime around 19:47 -0500 05/09/01, Pete Resnick sent us:
>>obs-local-part  =       word *("." word)
>>
>>where "word" is defined as atom or quoted-string. So an 
>>implementation must be able to handle your third example even 
>>though it must not be generated in new implementations.
>
>This raises a final (I hope) question. If I understand this 
>correctly, the following local-part would not be valid either for 
>generating or receiving (i.e., this would not be considered a valid 
>local-part):
>
>vince"local part"sabio
>
>...since the dot-atoms are missing the dots.

Well, it's not valid because obs-local-part is defined as a word or 
two or more dot-separated words, and that's not such a thing. Of 
course, I would take the Note at the beginning of section 4 quite 
seriously:

    Note: This section identifies syntactic forms that any implementation
    MUST reasonably interpret.  However, there are certainly Internet
    messages which do not conform to even the additional syntax given in
    this section.  The fact that a particular form does not appear in any
    section of this document is not justification for computer programs
    to crash or for malformed data to be irretrievably lost by any
    implementation.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked]
Xref: clerew local.mime:609
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Is 8BIT ESTMP really needed
Date: Thu, 10 May 2001 09:11:24 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Tony Hansen <[email-masked]> writes:

>The gateways I've worked on that did up/down conversion were very
>careful to differentiate between QP conversions in text/* parts and
>anything/else parts. Text parts can make all sorts of assumptions about
>CRs and LFs, but anything/else parts cannot. For example, the QP that I
>generate for anything/else parts always uses =0D or =0A for CRs and LFs,
>and uses soft newlines (=CRLF) after such CRs, LFs or CRLFs (and for
>splitting apart long lines). This preserves the CRs and LFs while still
>breaking the lines at the same locations within the attachment.

OK, it looks as though the "best" servers do it properly, which is good.
But there is nothing in the RFCs to say it SHOULD be done that way, so I
daresay there are many servers that won't. I will have to look at what the
Perl Mail package does.

But it will certainly remove all uncertainty from computing the
Content-Md5 - until it comes across a server that upconverts followed by
another that downconverts again :-( .

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Thu, 10 May 2001 02:48:46 -0400
To: [email-masked]
From: Vince Sabio <[email-masked]>
Subject: Re: Interpretation of 2822 needed
Sender: [email-masked]

** Sometime around 19:47 -0500 05/09/01, Pete Resnick sent us:
>On 5/9/01 at 7:44 PM -0400, Vince Sabio wrote:
>
>>To me, this means that the local-part of an address may either be 
>>quoted or may contain dot-atoms, but may not contain embedded 
>>quoted substrings. For example, consider the following address 
>>local-parts:
>>
>>VALID: vince.sabio
>>VALID: "vince sabio" (deprecated, but nonetheless valid)
>>NOT VALID: vince."human mail server".sabio
>>
>>Is my interpretation of 3.4.1 correct, or am I reading something wrong here?
>
>This is correct for the *generate* syntax. Do note however that it 
>is legal in the obsolete (i.e., interpreting) syntax.

Ah, yes. Thank you for the distinction; it's relevant for what we're doing.

>In 3.4.1 you have:
>
>addr-spec       =       local-part "@" domain
>
>local-part      =       dot-atom / quoted-string / obs-local-part
>
>and in 4.4 you have:
>
>obs-local-part  =       word *("." word)
>
>where "word" is defined as atom or quoted-string. So an 
>implementation must be able to handle your third example even though 
>it must not be generated in new implementations.

This raises a final (I hope) question. If I understand this 
correctly, the following local-part would not be valid either for 
generating or receiving (i.e., this would not be considered a valid 
local-part):

vince"local part"sabio

...since the dot-atoms are missing the dots.

Many thanks for all of the responses/clarifications I have received 
on this thread.

________________________________________________________________________
Vince Sabio                                               [email-masked]

From: "Howard Swinehart" <[email-masked]>
To: <[email-masked]>
Subject: Re: Interpretation of 2822 needed
Date: Thu, 10 May 2001 00:09:49 -0400
Sender: [email-masked]

From: "Vince Sabio" <[email-masked]>
> To me, this means that the local-part of an address may either be
> quoted or may contain dot-atoms, but may not contain embedded quoted
> substrings. For example, consider the following address local-parts:
>
> VALID: vince.sabio
> VALID: "vince sabio" (deprecated, but nonetheless valid)
> NOT VALID: vince."human mail server".sabio
>
> Is my interpretation of 3.4.1 correct, or am I reading something
> wrong here?

That's how I interpret both the text and the ABNF of 3.4.1.

If you want to put quotation marks in the local-part, you have to use a
quoted-string containing quoted-pairs:

VALID: "vince.\"human mail server\".sabio"
NOT VALID: vince."human mail server".sabio

From: Keith Moore <[email-masked]>
To: Vince Sabio <[email-masked]>
cc: [email-masked]
Subject: Re: Interpretation of 2822 needed 
Date: Wed, 09 May 2001 23:25:02 -0400
Sender: [email-masked]

> To me, this means that the local-part of an address may either be
> quoted or may contain dot-atoms, but may not contain embedded quoted
> substrings. 

right.  another thing that it means is if the local-part would be valid
without quotes, the quotes shouldn't be included.  

so it should be [email-masked] rather than "keith.moore"@cs.utk.edu

Keith

Date: Wed, 9 May 2001 19:47:44 -0500
To: Vince Sabio <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Interpretation of 2822 needed
Cc: [email-masked]
Sender: [email-masked]

On 5/9/01 at 7:44 PM -0400, Vince Sabio wrote:

>To me, this means that the local-part of an address may either be 
>quoted or may contain dot-atoms, but may not contain embedded quoted 
>substrings. For example, consider the following address local-parts:
>
>VALID: vince.sabio
>VALID: "vince sabio" (deprecated, but nonetheless valid)
>NOT VALID: vince."human mail server".sabio
>
>Is my interpretation of 3.4.1 correct, or am I reading something wrong here?

This is correct for the *generate* syntax. Do note however that it is 
legal in the obsolete (i.e., interpreting) syntax. In 3.4.1 you have:

addr-spec       =       local-part "@" domain

local-part      =       dot-atom / quoted-string / obs-local-part

and in 4.4 you have:

obs-local-part  =       word *("." word)

where "word" is defined as atom or quoted-string. So an 
implementation must be able to handle your third example even though 
it must not be generated in new implementations.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 9 May 2001 19:44:01 -0400
To: [email-masked]
From: Vince Sabio <[email-masked]>
Subject: Interpretation of 2822 needed
Sender: [email-masked]

Hi folks,

Quick question on RFC2822. Sect. 3.4.1 on address formats states:

    3.4.1. Addr-spec specification

    An addr-spec is a specific Internet identifier that contains a
    locally interpreted string followed by the at-sign character ("@",
    ASCII value 64) followed by an Internet domain.  The locally
    interpreted string is either a quoted-string or a dot-atom.  If the
    string can be represented as a dot-atom (that is, it contains no
    characters other than atext characters or "." surrounded by atext
    characters), then the dot-atom form SHOULD be used and the
    quoted-string form SHOULD NOT be used. Comments and folding white
    space SHOULD NOT be used around the "@" in the addr-spec.

To me, this means that the local-part of an address may either be 
quoted or may contain dot-atoms, but may not contain embedded quoted 
substrings. For example, consider the following address local-parts:

VALID: vince.sabio
VALID: "vince sabio" (deprecated, but nonetheless valid)
NOT VALID: vince."human mail server".sabio

Is my interpretation of 3.4.1 correct, or am I reading something wrong here?

BTW, congrats all around on RFCs 2821/2!

Thanks,
Vince

From: Keith Moore <[email-masked]>
To: Tony Hansen <[email-masked]>
cc: Mariano Absatz <[email-masked]>, Charles Lindsey <[email-masked]>, RFC 822 list <[email-masked]>
Subject: Re: Is 8BIT ESTMP really needed 
Date: Wed, 09 May 2001 19:21:04 -0400
Sender: [email-masked]

> > Do you mean doing this for EVERY time you use CTE=QP or only for Content-
> > MD5?
> 
> This should not be done for CTE=QP for text/* content types.
> 
> This >>SHOULD<< be done EVERY TIME for CTE=QP for all anything/else
> (non-text/*) content types.

True, but it shouldn't matter except for readability on non-MIME readers.
A properly functioning MIME UA should decode either one in exactly the
same way.

Keith

Date: Wed, 09 May 2001 17:44:42 -0400
From: Tony Hansen <[email-masked]>
To: Mariano Absatz <[email-masked]>
CC: Charles Lindsey <[email-masked]>, RFC 822 list <[email-masked]>
Subject: Re: Is 8BIT ESTMP really needed
Sender: [email-masked]

see below

Mariano Absatz wrote:
> 
> El 9 May 2001, a las 9:51, Charles Lindsey escribió:
> 
> <SNIP>
> > >  that is, even
> > >if the canonicalization was done improperly, the MD5 needs to be
> > >computed over the form of the body part that exists *after*
> > >canonicalization and *prior* to any content-transfer-encoding.
> >
> > Yes, but the content-transfer-encoding provides a second opportunity to
> > canonicalize LF into CRLF (the encoding engine is likely separate from the
> > Copntent-MD5 engine) and so may introduce some CRLFs not appropriate for
> > that application type, and strange things may then arise upon upcoding.
> >
> > I think the only safe way is to encode all CRLF in application types as
> > =0D=0A, giving
> >       foo=0Dbar=0Abax=0D=0A=CRLF
> Do you mean doing this for EVERY time you use CTE=QP or only for Content-
> MD5?

This should not be done for CTE=QP for text/* content types.

This >>SHOULD<< be done EVERY TIME for CTE=QP for all anything/else
(non-text/*) content types.

	Tony Hansen
	[email-masked]

From: "Mariano Absatz" <[email-masked]>
To: [email-masked] (Charles Lindsey)
Date: 	Wed, 9 May 2001 16:10:54 -0300
Subject: Re: Is 8BIT ESTMP really needed
CC: RFC 822 list <[email-masked]>
Sender: [email-masked]

El 9 May 2001, a las 9:51, Charles Lindsey escribió:

<SNIP>
> >  that is, even
> >if the canonicalization was done improperly, the MD5 needs to be
> >computed over the form of the body part that exists *after* 
> >canonicalization and *prior* to any content-transfer-encoding.
> 
> Yes, but the content-transfer-encoding provides a second opportunity to
> canonicalize LF into CRLF (the encoding engine is likely separate from the
> Copntent-MD5 engine) and so may introduce some CRLFs not appropriate for
> that application type, and strange things may then arise upon upcoding.
> 
> I think the only safe way is to encode all CRLF in application types as
> =0D=0A, giving
> 	foo=0Dbar=0Abax=0D=0A=CRLF
Do you mean doing this for EVERY time you use CTE=QP or only for Content-
MD5?

If you apply this to a text/plain part, you are almost certain to defeat 
the purpose of QP that is being "rather legible" if your mailer can't 
MIME.

I=20would=39t=20like=20to=20be=reading=0D=0A
this=20kind=20of=20stuff=20in=20my=20mailer=2E=2E=2E=20=0D=0A
=0D=0A
And=20you=3F=0D=0A

I know most decent mailers can MIME, but then, are we in a position to 
"make the switch" and ignore the rest? I don't think so...

Maybe it's time for 
Mime-Version: 1.1
Aaaaaaaarrrrrrrrrrgggggggghhhhhh!!!!!!!!!
:-)

> thus not relying on the CRLF at the end of the CTE lines for any meaning.
> But encoding engines do not currently work this way :-( . So it seems to
> me that a Content-MD5 engine (assuming it has no opportunity to alter the
> document, or to influence the encoding) is forced to try and 2nd guess
> what the encoding is going to do (or has already done).
> 

--
Mariano Absatz - El Baby
mailto:[email-masked]
http://www.baby.com.ar/
    PGP KEYS: http://www.baby.com.ar/datos/personales.html#claves_pgp
  |\  _
  _\\/'>     Powered by Pegasus Mail
 /|__)       http://www.pmail.com
  ) )\
-----------------------------------------------------------
Okay, who put a "stop payment" on my reality check? 

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Is 8BIT ESTMP really needed 
Date: Wed, 09 May 2001 13:31:50 -0400
Sender: [email-masked]

> Yes, but the content-transfer-encoding provides a second opportunity to
> canonicalize LF into CRLF 

if it does, it's broken.  the c-t-e takes an octet string as input.
it shouldn't be trying to understand what is or is not text.

Keith 

Date: Wed, 09 May 2001 17:35:31 +0100
To: Dave Crocker <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: pop in, imap out?
Sender: [email-masked]

At 10:11 03/05/2001 -0700, Dave Crocker wrote:
>This is sufficiently bizarre, I need to broadcast the query...
>
>When trying to access a user's set of mailboxes from multiple machines -- 
>eg, laptop and desktop -- just using operating system file sharing can be 
>a performance problem.
>
>So I am looking for some software that will use POP to pull down my mail 
>from various network accounts, and then will make the mail available via IMAP.
>
>That is, the "client" side of the server will go out and get new mail and 
>incorporate it into its storage environment.  The server side of the 
>server will allow other clients to access the store via IMAP.
>
>Does anyone know of such a WIN2K server?

I don't usually like 'advertising' on these mailing lists, but you may want 
to look at our VPOP3 Enterprise software 
(www.pscs.co.uk/products/vpop3/index.html). It sounds like it will do just 
what you want. It'll download mail from as many POP3 accounts as you want 
(over the LAN or dial-up connection) and then you can put them into one 
local merged POP3 or IMAP4 account.

There's a 30 day, 25 user trial version available, so you can see if it 
does what you need.

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

To: [email-masked]
Xref: clerew local.mime:598
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Is 8BIT ESTMP really needed
Date: Wed, 9 May 2001 09:51:16 GMT
Lines: 42
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>actually I think it's clear (or should be) that the MD5 computation
>should be completely independent of canonicalization.

That was the intention of RFC 1864, but unfortunately it does not deliver,
as its text is written. It provides for all "line endings" to be
canonicalized into CRLF before computing the hash, but it does not define
what is or is not a "line ending". For text/* types, that is no problem,
of course, but what about random application types? For some of them, the
concept of "line ending" is perfectly clear. For others it is not (someone
mentioned PDF).

>  that is, even
>if the canonicalization was done improperly, the MD5 needs to be
>computed over the form of the body part that exists *after* 
>canonicalization and *prior* to any content-transfer-encoding.

Yes, but the content-transfer-encoding provides a second opportunity to
canonicalize LF into CRLF (the encoding engine is likely separate from the
Copntent-MD5 engine) and so may introduce some CRLFs not appropriate for
that application type, and strange things may then arise upon upcoding.

I think the only safe way is to encode all CRLF in application types as
=0D=0A, giving
	foo=0Dbar=0Abax=0D=0A=CRLF
thus not relying on the CRLF at the end of the CTE lines for any meaning.
But encoding engines do not currently work this way :-( . So it seems to
me that a Content-MD5 engine (assuming it has no opportunity to alter the
document, or to influence the encoding) is forced to try and 2nd guess
what the encoding is going to do (or has already done).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:597
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Is 8BIT ESTMP really needed
Date: Wed, 9 May 2001 09:20:39 GMT
Lines: 29
Sender: [email-masked]

In <[email-masked]> Simon Josefsson <[email-masked]> writes:

>Gnus used to (or maybe it still does) encode binary attachments as
>QP/B64 depending on which resulted in the smallest size.  As it
>happened, PDF files often contain lots of ASCII and only a little
>binary data, so it would often be encoded as QP.

>In addition of causing problems with QP-encoded binary contents in
>some clients, up/down-conversion of the PDF file sometimes caused the
>content to be unreadable.  So it's not only an issue of MD5 or digital
>signatures, but of actually being able to transfer the data.  So in
>practice QP seem to be "for text only".

I think the only safe way to encode application types in QP would be to
encode ALL CRLFs as =0D=0A, as in one of my examples yesterday:
	foo=0Dbar=0Abax=0D=0A=CRLF
Would PDF files survive intact if the downcoding was always done in that
way?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: "Mitchell" <[email-masked]>
To: [email-masked]
Subject: Business/Employment Opportunity
Date: Tue, 8 May 2001 19:11:27 -1000
Sender: [email-masked]

Dear Friend:

"Making over half million dollars every 4 to 5 months from your
home for an investment of only $25 U.S. Dollars expense one
time"

THANKS TO THE COMPUTER AGE AND THE INTERNET!
===============================================

BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !!

Before you say "Bull" , please read the following. This is the
letter you have been hearing about on the news lately. Due to the
popularity of this letter on the internet, a national weekly news
program recently devoted an entire show to the investigation of
this program described below , to see if it really can make people
money.

The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are "absolutely
no laws prohibiting the participation in the program and if people
can follow the simple instructions, they are bound to make
some mega bucks with only $25 out of pocket cost".

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT
THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING
BETTER THAN EVER.

This is what one had to say:

"Thanks to this profitable opportunity. I was approached
many times before but each time I passed on it. I am so glad
I finally joined just to see what one could expect in return
for the minimal effort and money required. To my astonishment, I
received total $ 610,470.00 in 21 weeks, with money still
coming in".
Pam Hedland, Fort Lee, New Jersey.

-------------------------------------------------------------------------

Here is another testimonial:

"This program has been around for a long time but I never
believed in it. But one day when I received this again in
the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money
started to come in. First month I only made $240.00 but
the next 2 months after that I made a total of $290,000.00.
So far, in the past 8 months by re-entering the program,I
have made over $710,000.00 and I am playing it again.
The key to success in this program is to follow the simple
steps and NOT change anything ."

More testimonials later but first,

****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE *******

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $500,000 every 4 to 5 months
easily and comfortably, please read the following...THEN READ
IT AGAIN and AGAIN !!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR
FINANCIAL DREAMS WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

**** Order all 5 reports shown on the list below.

**** For each report, send $5 CASH, THE NAME & NUMBER OF THE
REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS
to the person whose name appears ON THAT LIST next to the report.
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE
TOP LEFT CORNER in case of any mail problems.

**** When you place your order, make sure you order each of the 5
reports. You will need all 5 reports so that you can save them on your 
computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00.

**** Within a few days you will receive, via e-mail, each of the 5
reports from these 5 different individuals. Save them on your computer
so they will be accessible for you to send to the 1,000's of people
who will order them from you. Also make a floppy of these
reports and keep it on your desk in case something happen to your
computer.

****.IMPORTANT - DO NOT alter the names of the people who are
listed next to each report, or their sequence on the list, in
any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you
understand the way this works, you will also see how it does not work if you 
change it.

Remember, this method has been tested, and if you alter, it
will NOT work!!! People have tried to put their friends/relatives names
on all five thinking they could get all the money. But it does not work this 
way. Believe us, we all have tried to be greedy and then nothing happened. 
So Do Not try to change anything other than what is instructed. Because if 
you do, it will not work for you. Remember, honesty reaps the reward!!!

1.. After you have ordered all 5 reports, take this advertisement
and REMOVE the name & address of the person in REPORT # 5. This
person has made it through the cycle and is no doubt counting
their fortune.

2.... Move the name & address in REPORT # 4 down TO REPORT # 5.

3.... Move the name & address in REPORT # 3 down TO REPORT # 4.

4.... Move the name & address in REPORT # 2 down TO REPORT # 3.

5.... Move the name & address in REPORT # 1 down TO REPORT # 2

6.... Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY !
=========================================================

Take this entire letter, with the modified list of names, and save
it on your computer. DO NOT MAKE ANY OTHER CHANGES.
Save this on a disk as well just in case if you loose any data.

To assist you with marketing your business on the internet, the
5 reports you purchase will provide you with invaluable
marketing information which includes how to send bulk e-mails legally,
where to find thousands of free classified ads and much more.

There are 2 Primary methods to get this venture going:

METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY
============================================
let's say that you decide to start small, just to see how it
goes, and we will assume You and those involved send out only
5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just
say it is only 0.2% . Also many people will send out hundreds of
thousands e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1.
Those 10 people responded by sending out 5,000 e-mail
each for a total of 50,000. Out of those 50,000 e-mails only
0.2% responded with orders. That's = 100 people responded
and ordered Report # 2. Those 100 people mail out 5,000
e-mails each for a total of 500,000 e-mails. The 0.2% response
to that is 1000 orders for Report # 3. Those 1000 people send
out 5,000 e-mails each for a total of 5 million e-mails sent out.
The 0.2% response to that is 10,000 orders for Report # 4.
Those 10,000 people send out 5,000 e-mails each for a total of
50,000,000 (50 million) e-mails. The 0.2% response to that is
100,000 orders for Report # 5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million).

Your total income in this example is:
1..... $50 +
2..... $500 +
3..... $5,000 +
4..... $50,000 +
5..... $500,000 ......... Grand Total = $555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE
OUT THE WORST POSSIBLE RESPONSES AND NO MATTER
HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF
MONEY !

------------------------------------------------------------------------------

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE
ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for
a moment what would happen if everyone, or half or even one 4th
of those people mailed 100,000 e-mails each or more? There are
over 250 million people on the internet worldwide and counting.
Believe me, many people will do just that, and more!

METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
===================================================
Advertising on the net is very very inexpensive and there are
hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly
suggest you start with Method # 1 and add METHOD # 2 as you go
along.

For every $5 you receive, all you must do is e-mail them the Report
they ordered. That's it . Always provide same day service on all
orders. This will guarantee that the e-mail they send out, with your
name and address on it, will be prompt because they can not advertise until 
they receive the report.

_____________________ AVAILABLE REPORTS_____________________

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY.

Notes: Always send $5 cash (U.S. CURRENCY) for each Report.
Checks NOT accepted. Make sure the cash is concealed by wrapping
it in at least 2 sheets of paper. On one of those sheets of paper,
Write the NUMBER & the NAME of the Report you are ordering, YOUR
E-MAIL ADDRESS and your name and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW :
==============================================
REPORT #1, "The Insider's Guide to Sending
Bulk E-mail on the Internet"

ORDER REPORT #1 FROM:

G. Donaldson
P.O. Box 25884
Honolulu, Hawaii 96825-0884

don't forget to provide a permanent e-mail address in clear writing (better 
typed) to receive the reports. We had problems in delivery e-mails before!!!

==============================================
REPORT #2 "The Insider's Guide to Advertising for Free on the
Internet"
ORDER REPORT #2 FROM:

Vijay Paul
C-291, Second Floor
Defence Colony
New Delhi - 110024
INDIA

==============================================
REPORT #3 "The Secrets to Multilevel Marketing on the Internet"
ORDER REPORT #3 FROM:

JD
P.O.Box 1114
Des Plaines, IL 60017
USA

==============================================
REPORT #4 "How to become a Millionaire utilizing the Power of
Multilevel Marketing and the Internet"
ORDER REPORT #4 FROM:

J Santi
833 Walter Ave
Des Plaines, IL 60016
USA

==============================================
REPORT #5 "How to SEND 1,000,000 e-mails for FREE"
ORDER REPORT #5 FROM:

Elaine Rix
138 Dundas Street, West, #243
Toronto, Ontario
Canada M5G 1C3

==============================================
There are currently more than 250,000,000 people online
worldwide!

$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$

Follow these guidelines to guarantee your success:

If you do not receive at least 10 orders for Report #1 within 2
weeks, continue sending e-mails until you do.

After you have received 10 orders, 2 to 3 weeks after that
you should receive 100 orders or more for REPORT # 2.
If you did not, continue advertising or sending e-mails until
you do.
Once you have received 100 or more orders for Report # 2,
YOU CAN RELAX, because the system is already working for
you , and the cash will continue to roll in !

THIS IS IMPORTANT TO REMEMBER : Every time your name is
moved down on the list, you are placed in front of a different report.
You can KEEP TRACK of your PROGRESS by watching which
report people are ordering from you. IF YOU WANT TO GENERATE
MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND
START THE WHOLE PROCESS AGAIN. There is NO LIMIT to
the income you can generate from this business !!!
____________________________________________________

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM:

You have just received information that can give you financial
freedom for the rest of your life, with NO RISK and JUST A
LITTLE BIT OF EFFORT. You can make more money in the
next few weeks and months than you have ever imagined.

Follow the program EXACTLY AS INSTRUCTED. Do Not change
it in any way. It works exceedingly well as it is now.
Remember to e-mail a copy of this exciting report after you
have put your name and address in Report #1 and moved others to
#2...........# 5 as instructed above. One of the people you send this to may 
send out 100,000 or more e-mails and your name will be on everyone of them. 
Remember though, the more you send out the more potential customers you will 
reach.

So my friend, I have given you the ideas, information,
materials and opportunity to become financially independent. IT IS UP TO YOU 
NOW !

************** MORE TESTIMONIALS ****************

"My name is Mitchell. My wife , Jody and I live in Chicago.
I am an accountant with a major U.S. Corporation and I
make pretty good money. When I received this program I grumbled
to Jody about receiving ''junk mail''. I made fun of the
whole thing, spouting my knowledge of the population and
percentages involved. I ''knew'' it wouldn't work. Jody
totally ignored my supposed intelligence and few days later she jumped in 
with both feet. I made merciless fun of her, and was ready to
lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received
50 responses. Within the next 45 days she had received a
total of $ 147,200.00 all cash! I was shocked. I have
joined Jody in her ''hobby''."
Mitchell Wolf,
Chicago, Illinois

------------------------------------------------------------

"Not being the gambling type, it took me several weeks to
make up my mind to participate in this plan. But conservative that
I am, I decided that the initial investment was so little
that there was just no way that I wouldn't get enough orders to at
least get my money back.

I was surprised when I found my medium size post office box
crammed with orders. I made $319,210.00 in the first 12
weeks. The nice thing about this deal is that it does not matter
where people live. There simply isn't a better investment
with a faster return and so big."
Dan Sondstrom, Alberta,
Canada

-----------------------------------------------------------

"I had received this program before. I deleted it, but
later I wondered if I should have given it a try. Of course, I had
no idea who to contact to get another copy, so I had to wait
until I was e-mailed again by someone else.........11 months
passed then it luckily came again...... I did not delete this
one! I made more than $490,000 on my first try and all the
money came within 22 weeks".
Susan De Suza,
New York, N.Y.

----------------------------------------------------

"It really is a great opportunity to make relatively easy
money with little cost to you. I followed the simple
instructions carefully and within 10 days the money
started to come in. My first month I made $ 20,560.00
and by the end of third month my total cash count was
$ 362,840.00. Life is beautiful, Thanx to internet".
Fred Dellaca, Westport,
New Zealand
------------------------------------------------------------

ORDER YOUR REPORTS TODAY AND GET STARTED ON
YOUR ROAD TO FINANCIAL FREEDOM !

=======================================================

If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.

Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal.
This is one time e-mail transmission. No request for removal is
necessary.

------------------------------------------------------------
This message is sent in compliance of the new email
Bill HR 1910. Under Bill HR 1910 passed by the 106th
US Congress on May 24, 1999, this message cannot be
considered Spam as long as we include the way to be
removed. Per Section HR 1910, Please type "REMOVE" in
the subject line and reply to this email. All removal
requests are handled personally an immediately once
received.

Date: Wed, 09 May 2001 00:36:19 -0400
From: Tony Hansen <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: Is 8BIT ESTMP really needed
Sender: [email-masked]

The gateways I've worked on that did up/down conversion were very
careful to differentiate between QP conversions in text/* parts and
anything/else parts. Text parts can make all sorts of assumptions about
CRs and LFs, but anything/else parts cannot. For example, the QP that I
generate for anything/else parts always uses =0D or =0A for CRs and LFs,
and uses soft newlines (=CRLF) after such CRs, LFs or CRLFs (and for
splitting apart long lines). This preserves the CRs and LFs while still
breaking the lines at the same locations within the attachment.

	Tony Hansen
	[email-masked]

Simon Josefsson wrote:
> 
> [email-masked] (Charles Lindsey) writes:
> 
> > Suppose your message has Content-Type: application/foo (there is never any
> > problem with text/plain). The body of the message is
> >       fooCRbarLFbazCRLF
> > (the naked CR and LF are a 'feature' os the application/foo protocol).
> > Suppose you decide to encode it in QP (maybe not the wisest choice, but
> > legal).
> 
> Just a note that there are real examples of this out there:
> 
> Gnus used to (or maybe it still does) encode binary attachments as
> QP/B64 depending on which resulted in the smallest size.  As it
> happened, PDF files often contain lots of ASCII and only a little
> binary data, so it would often be encoded as QP.
> 
> In addition of causing problems with QP-encoded binary contents in
> some clients, up/down-conversion of the PDF file sometimes caused the
> content to be unreadable.  So it's not only an issue of MD5 or digital
> signatures, but of actually being able to transfer the data.  So in
> practice QP seem to be "for text only".

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Is 8BIT ESTMP really needed 
Date: Tue, 08 May 2001 09:22:39 -0400
Sender: [email-masked]

> I think we established, a few weeks back, that the RFC defining
> Content-MD5 should really have made it clearer exactly when LF->CRLF
> canonicalization had to be done. 

actually I think it's clear (or should be) that the MD5 computation
should be completely independent of canonicalization.  that is, even
if the canonicalization was done improperly, the MD5 needs to be
computed over the form of the body part that exists *after* 
canonicalization and *prior* to any content-transfer-encoding.
the MD5 computation shouldn't try to second-guess the canonicalization,
nor should it be sensitive to either content-type or content-transfer-encoding

things are far less confusing and less prone to misimplementation if we
maintain a clean separation of function between layers.

Keith

From: Keith Moore <[email-masked]>
To: [email-masked] (Kai Henningsen)
cc: [email-masked]
Subject: Re: Is 8BIT ESTMP really needed 
Date: Tue, 08 May 2001 09:19:00 -0400
Sender: [email-masked]

> > > True, but the question is also what steps need to be taken to insure
> > > success.
> >
> > I think you've already answered that.  There is no means of ensuring
> > success, because the upconverter lacks the necessary information.
> 
> But the information he mentioned is all available. Determining used octet
> values and line length is not rocket science.

*if* you know the nature of each content-type used.  which, in general,
is not the case.
 
> Except in the signed case, where you need to preserve details of the
> original encoding, and *that* is broken.

true.

> What the relevant standard *should* have done (of course it's a little
> late now) was to sign the canonical form, and if they needed to sign the
> headers, too, then describing a canonicalization method for those.

it's not too late to define another multipart that works properly.

Keith

To: [email-masked] (Charles Lindsey)
Cc: [email-masked]
Subject: Re: Is 8BIT ESTMP really needed
From: Simon Josefsson <[email-masked]>
Date: 08 May 2001 14:39:21 +0200
Lines: 21
Sender: [email-masked]

[email-masked] (Charles Lindsey) writes:

> Suppose your message has Content-Type: application/foo (there is never any
> problem with text/plain). The body of the message is
> 	fooCRbarLFbazCRLF
> (the naked CR and LF are a 'feature' os the application/foo protocol).
> Suppose you decide to encode it in QP (maybe not the wisest choice, but
> legal).

Just a note that there are real examples of this out there:

Gnus used to (or maybe it still does) encode binary attachments as
QP/B64 depending on which resulted in the smallest size.  As it
happened, PDF files often contain lots of ASCII and only a little
binary data, so it would often be encoded as QP.

In addition of causing problems with QP-encoded binary contents in
some clients, up/down-conversion of the PDF file sometimes caused the
content to be unreadable.  So it's not only an issue of MD5 or digital
signatures, but of actually being able to transfer the data.  So in
practice QP seem to be "for text only".

To: [email-masked]
Xref: clerew local.mime:590
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Is 8BIT ESTMP really needed
Date: Tue, 8 May 2001 10:21:34 GMT
Lines: 78
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> AFAIK the only reason upconversion would ever break content-md5

>my guess is that it breaks content-md5 for the case where 
>bare CR or bare LF appears in the canonical form, and this 
>same character is coincidentally the line ending for the stored 
>form of the message at some point following upconversion.  the MD5 
>computation at the recipient would see the line ending as CR LF
>rather than just bare CR or bare LF as in the original.

Yes, that is the sort of case I had in mind.

Suppose your message has Content-Type: application/foo (there is never any
problem with text/plain). The body of the message is
	fooCRbarLFbazCRLF
(the naked CR and LF are a 'feature' os the application/foo protocol).
Suppose you decide to encode it in QP (maybe not the wisest choice, but
legal).

So you compute the Content-MD5 on the message exactly as above, and what
you send over the wire is:
	foo=0Dbar=0AbazCRLF
or	foo=0Dbar=0Abaz=0D=0A=CRLF
which, if it arrives at the far end intact, should verify correctly.

But if some intermediate site upconverts it (to binary, perhaps) and some
later site downconverts it again, or (being a UNIX site, changes the CR to
LF, and then changes both the LFs back to CRLF for MD5-checking) then
things can go wrong.

I think we established, a few weeks back, that the RFC defining
Content-MD5 should really have made it clearer exactly when LF->CRLF
canonicalization had to be done. But in the absence of such guidance, I
think the following is the correct (or at least the safest) way to check a
Content-MD5 on arrival.

1. If the Content-Type is text/*, undo any encoding, convert any naked LF
to CRLF (though there shouldn't be any) and protest loudly at any naked
CR. Then check the MD5.

2. If the Content-Type is other than text/*, look at the
Content-Transfer-Encoding.

2a. If it is 7bit, 8bit or binary, do the MD5 check as received.

2b. If it is base64, undo the encoding, and do the MD5 check on the result
(naked CR and LF remain as such).

2c. If it is QP, ensure that all line endings are in the form CRLF (just
in case you were on a UNIX box that had turned them into LF). Then undo
the encoding (which may expose some naked CR and LF) and then do the
check.

The last case is the tricky one. You may find:
	Naked CR that had been encoded as =0D
	Naked LF that had been encoded as =0A
	CRLF that had been encoded as =0D=0A
	CRLF that had not been encoded at all
	"nothing" that had been encoded as =CRLF

Note: One assumes that the person who sent the message and had chosen
(perhaps foolishly) to use Q-P has sent it in a form suited to the above.

But upconversion at an intermediate site might well break it (or, again,
it might not).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: 08 May 2001 08:51:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Is 8BIT ESTMP really needed
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Keith Moore)  wrote on 08.05.01 in <[email-masked]>:

> > True, but the question is also what steps need to be taken to insure
> > success.
>
> I think you've already answered that.  There is no means of ensuring
> success, because the upconverter lacks the necessary information.

But the information he mentioned is all available. Determining used octet  
values and line length is not rocket science.

Except in the signed case, where you need to preserve details of the  
original encoding, and *that* is broken.

What the relevant standard *should* have done (of course it's a little  
late now) was to sign the canonical form, and if they needed to sign the  
headers, too, then describing a canonicalization method for those.

MfG Kai

From: [email-masked]
Date: Mon, 07 May 2001 23:01:38 -0700 (PDT)
Subject: Re: Is 8BIT ESTMP really needed
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > True, but the question is also what steps need to be taken to insure success.

> I think you've already answered that.  There is no means of ensuring success,
> because the upconverter lacks the necessary information.

No, my point is that the data itself contains all the necessary information
to determine whether or not upconversion is possible and what the resulting
CTE has to be.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Is 8BIT ESTMP really needed 
Date: Tue, 08 May 2001 01:25:22 -0400
Sender: [email-masked]

> True, but the question is also what steps need to be taken to insure success.

I think you've already answered that.  There is no means of ensuring success,
because the upconverter lacks the necessary information.

From: [email-masked]
Date: Mon, 07 May 2001 18:39:42 -0700 (PDT)
Subject: Re: Is 8BIT ESTMP really needed
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > AFAIK the only reason upconversion would ever break content-md5

> my guess is that it breaks content-md5 for the case where
> bare CR or bare LF appears in the canonical form, and this
> same character is coincidentally the line ending for the stored
> form of the message at some point following upconversion.

This is specific case one of the possibilities I described: Upconversion to a
CTE that cannot properly represent the content. 7bit or 8bit CTEs cannot
represent such content, so upconverting such content to them breaks things.

Note that it isn't enough to have knowledge of the content type, you also have
to have knowledge of the actual content you are dealing with. (Although the
content type often tells you whether or not it is worth bothering with
upconversion.) For example, if you're upconverting text/plain you need to know
the maximum line length used by the content and what characters are present in
order to know whether a 7bit, 8bit, or binary CTE is appropriate.

> basically, converting a body part that is end-to-end transparent
> for all octet values to one which is not end-to-end transparent
> for all octet values can cause MD5 to fail.  no surprise there.

True, but the question is also what steps need to be taken to insure success.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Is 8BIT ESTMP really needed 
Date: Mon, 07 May 2001 20:23:21 -0400
Sender: [email-masked]

> AFAIK the only reason upconversion would ever break content-md5

my guess is that it breaks content-md5 for the case where 
bare CR or bare LF appears in the canonical form, and this 
same character is coincidentally the line ending for the stored 
form of the message at some point following upconversion.  the MD5 
computation at the recipient would see the line ending as CR LF
rather than just bare CR or bare LF as in the original.

basically, converting a body part that is end-to-end transparent 
for all octet values to one which is not end-to-end transparent 
for all octet values can cause MD5 to fail.  no surprise there.

Keith

From: [email-masked]
Date: Mon, 07 May 2001 14:05:38 -0700 (PDT)
Subject: Re: Is 8BIT ESTMP really needed
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> In <[email-masked]> Keith Moore <[email-masked]> writes:

> >> Is upconversion actually allowed by RFC 2821? Because it will break any
> >> PGP/MIME signature,

> >so will downconversion.  having the signature on the transfer-encoded
> >form is just broken - because this form doesn't get preserved end-to-end.

> Yes, I was confusing two things. It is Content-MD5 that is safe through
> downconcersion, but may be proken following a subsequent upconversion (see
> recent discussions on this list).

AFAIK the only reason upconversion would ever break content-md5 is (1)
The content was incorrectly canonicalized to begin with or (2) The
upconversion produced something that was intrinsicly incompatible with the
CTE chosen for the converted result.

Please elaborate if you are thinking of some other case.

				Ned

Date: Mon, 07 May 2001 11:23:25 -0400
From: Cyrus Daboo <[email-masked]>
To: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: pop in, imap out?
Sender: [email-masked]

--On Thursday, May 03, 2001 10:11:15 AM -0700 Dave Crocker 
<[email-masked]> wrote:

> This is sufficiently bizarre, I need to broadcast the query...
>
> When trying to access a user's set of mailboxes from multiple machines --
> eg, laptop and desktop -- just using operating system file sharing can be
> a  performance problem.
>
> So I am looking for some software that will use POP to pull down my mail
> from various network accounts, and then will make the mail available via
> IMAP.
>
> That is, the "client" side of the server will go out and get new mail and
> incorporate it into its storage environment.  The server side of the
> server  will allow other clients to access the store via IMAP.
>
> Does anyone know of such a WIN2K server?
>

One option is to find a conventional client that supports filtering between 
multiple accounts (POP and IMAP). You could then setup any old IMAP server 
on your laptop, and configure your mail client with the POP accounts and 
the one IMAP account and have the mail client do the POP->IMAP move 
operation whenever it checks for mail on the POP servers. I know of at 
least one client that would let you do that...

This would not be as efficient as say the fetchmail approach but it may be 
a lot easier to setup if you're already familiar with client-side filtering.

-- 
Cyrus Daboo

To: [email-masked]
Xref: clerew local.mime:585
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Is 8BIT ESTMP really needed
Date: Mon, 7 May 2001 09:07:46 GMT
Lines: 23
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> Is upconversion actually allowed by RFC 2821? Because it will break any
>> PGP/MIME signature, 

>so will downconversion.  having the signature on the transfer-encoded 
>form is just broken - because this form doesn't get preserved end-to-end.

Yes, I was confusing two things. It is Content-MD5 that is safe through
downconcersion, but may be proken following a subsequent upconversion (see
recent discussions on this list).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Fri, 04 May 2001 11:23:34 -0700
From: Chris Newman <[email-masked]>
Subject: Re: Is 8BIT ESTMP really needed
To: Charles Lindsey <[email-masked]>, [email-masked]
Sender: [email-masked]

>From RFC 1847 forbids 8-bit and binary in a multipart/security.

RFC 2821 is a bit more strongly worded than 821 in forbidding changes by 
"relays".  But an MTA which does upconversion is a gateway rather than a 
relay.  RFC 2480 applies to gateway MTAs.

		- Chris

--On Friday, May 4, 2001 11:02 +0000 Charles Lindsey <[email-masked]> 
wrote:
> Is upconversion actually allowed by RFC 2821? Because it will break any
> PGP/MIME signature, and may even break Content-MD5 for the reasons we were
> discussing last week.

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Is 8BIT ESTMP really needed 
Date: Fri, 04 May 2001 13:31:26 -0400
Sender: [email-masked]

> Is upconversion actually allowed by RFC 2821? Because it will break any
> PGP/MIME signature, 

so will downconversion.  having the signature on the transfer-encoded 
form is just broken - because this form doesn't get preserved end-to-end.

Keith

To: [email-masked]
Xref: clerew local.mime:579
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Is 8BIT ESTMP really needed
Date: Fri, 4 May 2001 11:02:02 GMT
Lines: 22
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>Absolutely true. Additionally, a lot of them downconvert when relaying to a
>non-8BITMIME system, and some even upconvert when relaying to an 8BITMIME
>system or when performing final delivery. I've seen cases recently where a
>message was converted several times. And it has actually been a while since
>I've seen a conversion that was done incorrectly.

Is upconversion actually allowed by RFC 2821? Because it will break any
PGP/MIME signature, and may even break Content-MD5 for the reasons we were
discussing last week.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: "Mariano Absatz" <[email-masked]>
To: Dave Crocker <[email-masked]>
Date: 	Fri, 4 May 2001 12:14:56 -0300
Subject: Re: pop in, imap out?
CC: RFC 822 list <[email-masked]>
Sender: [email-masked]

I once saw a cute windows mail server called FTGate... I just went to 
their website (http://ftgate.com) but these people doesn't seem to know a 
word about IMAP... it can fetch mail from different POP accounts into one 
mailbox, but you can only acces that mailbox either through POP or 
webmail... 

Anyway, you can also script mailboxes so they deliver it somwhere else, 
that way, you could deliver it to an IMAP server, but, especially on an 
MS box, you're kinda having 2 mailservers on the same box and that is 
usually way too harder to manage than in a unix box.

Also, take note that it's a commercial product (it has a 30 day 
evaluation demo) and there are 4 or 5 different versions, you should 
check which one is closer to (or less far from) what you need.

On the other hand, you could install any IMAP server you like and write a 
little POP client to access remote mailboxes and deliver locally (either 
through IMAP or through a local SMTP connection)... that shouldn't be too 
hard with Perl and a couple of modules from CPAN, I heard ActivePerl is 
quite stable... the point would be to have an interface for users to 
modify their POP client.

I don't know, there should be something better, but this is my 2c 
contrib...

El 3 May 2001, a las 10:11, Dave Crocker escribió:

> This is sufficiently bizarre, I need to broadcast the query...
> 
> When trying to access a user's set of mailboxes from multiple machines -- 
> eg, laptop and desktop -- just using operating system file sharing can be a 
> performance problem.
> 
> So I am looking for some software that will use POP to pull down my mail 
> from various network accounts, and then will make the mail available via 
> IMAP.
> 
> That is, the "client" side of the server will go out and get new mail and 
> incorporate it into its storage environment.  The server side of the server 
> will allow other clients to access the store via IMAP.
> 
> Does anyone know of such a WIN2K server?
> 
> d/
> 
> 
> ----------
> Dave Crocker   <mailto:[email-masked]>
> Brandenburg InternetWorking   <http://www.brandenburg.com>
> tel: +1.408.246.8253;   fax: +1.408.273.6464
> 

--
Mariano Absatz - El Baby
mailto:[email-masked]
http://www.baby.com.ar/
    PGP KEYS: http://www.baby.com.ar/datos/personales.html#claves_pgp
  |\  _
  _\\/'>     Powered by Pegasus Mail
 /|__)       http://www.pmail.com
  ) )\
-----------------------------------------------------------
Programming is an art form that fights back. 

Date: Fri, 04 May 2001 01:04:25 -0700
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: pop in, imap out? 
Cc: [email-masked]
Sender: [email-masked]

It's always interesting to hear someone deal with a question dismissively, 
presuming that the real problem is solved by just simplifying things.

As you note, the simplistic model that was suggested has its own drawbacks.

My note explained the scenario I want to support.  My laptop is my office; 
it contains the master mailbox files.  At home, I want to access them from 
my desktop.  Replication and synchronization between the two machines is 
not a viable approach, with current tools, since

         a) they will not be guaranteed to be sufficiently up to date,

         b) too much data would be copied, due to the nature of mailbox 
message addition.

Unfortunately, simply having the desktop access the mailbox files via 
remote file access suffers astonishingly bad performance.

So far, I have found web-based access essentially useless, due to high 
message flow needing more partitioning that web-based tools 
provide.  Besides that, I like to process mail offline.

d/

At 07:38 PM 5/3/2001, Keith Moore wrote:
> > Forward all you PoP email accounts to one account and then either read them
> > from there or read them via webmail.
>
>egad.  I can't speak for Dave, but having all of my mail end up in a
>single mailbox would be a disaster.  So, for that matter, would having
>to read my mail via the web (though it would be useful in a pinch).

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Fri, 4 May 2001 08:32:15 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: <[email-masked]>
cc: <[email-masked]>
Subject: Re: Is 8BIT ESTMP really needed
Sender: [email-masked]

On Thu, 3 May 2001 [email-masked] wrote:

> Most, but not all. Only a few weeks back I got a complaint about a message
> rejection that turned out to be someone sending unnegotiated 8bit to a system
> that was having none of it. Turning on conversion to quoted-printable solved
> the problem.

There are some people who believe that Q-P is an abomination. There are
some people who believe that you shouldn't use it because there are
receiving MUA clients that can't understand it. This may be a myth, of
course. There are also people who believe that MTAs shouldn't "tamper
with messages". Some of these people implement MTAs. I don't think there
will ever be consensus on this issue. At least not until the whole world
is 8-bit clean.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

From: Keith Moore <[email-masked]>
To: "Al Costanzo" <[email-masked]>
cc: [email-masked], "Dave Crocker" <[email-masked]>, [email-masked]
Subject: Re: pop in, imap out? 
Date: Thu, 03 May 2001 22:38:43 -0400
Sender: [email-masked]

> Forward all you PoP email accounts to one account and then either read them
> from there or read them via webmail.

egad.  I can't speak for Dave, but having all of my mail end up in a 
single mailbox would be a disaster.  So, for that matter, would having 
to read my mail via the web (though it would be useful in a pinch).

Keith

From: [email-masked]
Date: Thu, 03 May 2001 16:00:58 -0700 (PDT)
Subject: Re: Is 8BIT ESTMP really needed
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, Philip Hazel <[email-masked]>, Jacob Palme <[email-masked]>, [email-masked]
Sender: [email-masked]

> technically speaking, SMTP clients that send 8bit messages without
> seeing the proper 8BITMIME EHLO response from the server are in
> violation of the standards.

> practically speaking

> a) most mailers these days are at least tolerant of 8bit content
>    in the message body

Most, but not all. Only a few weeks back I got a complaint about a message
rejection that turned out to be someone sending unnegotiated 8bit to a system
that was having none of it. Turning on conversion to quoted-printable solved
the problem.

> b) most mailers these days advertise 8BITMIME anyway.

Absolutely true. Additionally, a lot of them downconvert when relaying to a
non-8BITMIME system, and some even upconvert when relaying to an 8BITMIME
system or when performing final delivery. I've seen cases recently where a
message was converted several times. And it has actually been a while since
I've seen a conversion that was done incorrectly.

				Ned

Reply-To: "Al Costanzo" <[email-masked]>
From: "Al Costanzo" <[email-masked]>
To: <[email-masked]>, "Dave Crocker" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: pop in, imap out?
Date: Thu, 3 May 2001 18:56:29 -0400
Sender: [email-masked]

Why go though all this trouble?

Forward all you PoP email accounts to one account and then either read them
from there or read them via webmail.

Not sure why this would be an issue at all.

-al

----- Original Message -----
From: <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 03, 2001 2:28 PM
Subject: Re: pop in, imap out?

> > This is sufficiently bizarre, I need to broadcast the query...
>
> > When trying to access a user's set of mailboxes from multiple
machines --
> > eg, laptop and desktop -- just using operating system file sharing can
be a
> > performance problem.
>
> > So I am looking for some software that will use POP to pull down my mail
> > from various network accounts, and then will make the mail available via
> > IMAP.
>
> > That is, the "client" side of the server will go out and get new mail
and
> > incorporate it into its storage environment.  The server side of the
server
> > will allow other clients to access the store via IMAP.
>
> > Does anyone know of such a WIN2K server?
>
> Fetchmail does stuff like this. It is pretty portable, but I don't know
> if it is built for WIN2K or not. However, you can run fetchmail on one
> system and have it pull mail from another and send it to a third, so
> platform isn't particularly relevant.
>
> Ned
>

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Philip Hazel <[email-masked]>, Jacob Palme <[email-masked]>, [email-masked]
Subject: Re: Is 8BIT ESTMP really needed 
Date: Thu, 03 May 2001 15:03:14 -0400
Sender: [email-masked]

technically speaking, SMTP clients that send 8bit messages without 
seeing the proper 8BITMIME EHLO response from the server are in 
violation of the standards.

practically speaking

a) most mailers these days are at least tolerant of 8bit content
   in the message body
b) most mailers these days advertise 8BITMIME anyway.

so it doesn't much matter.

Keith

From: "Lee Thompson" <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Philip Hazel <[email-masked]>, Jacob Palme <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Is 8BIT ESTMP really needed
Date: Thu, 03 May 2001 11:53:48 -0700
Organization: Seattle Lab, Inc.
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, 03 May 2001 13:15:10 -0400, you wrote:

> > I haven't seen any evidence in any RFC or STD saying that blindly (i.e. no
> > negotiation) sending raw 8bit data to an MTA is any sort of standard.
> 
> nor have I.  the question was about de facto standards, not official standards.
> 

Well I've seen what I consider broken clients and MTAs that DO this.  But I've
seen a lot of broken stuff out there :/

-- 
Lee Thompson               Software Engineer
[email-masked]          Voice 425 825-7000  Seattle Lab, Inc.
http://www.seattlelab.com  Fax 425 825-7001    a BVRP Group Company                                               

From: [email-masked]
Date: Thu, 03 May 2001 11:28:46 -0700 (PDT)
Subject: Re: pop in, imap out?
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> This is sufficiently bizarre, I need to broadcast the query...

> When trying to access a user's set of mailboxes from multiple machines --
> eg, laptop and desktop -- just using operating system file sharing can be a
> performance problem.

> So I am looking for some software that will use POP to pull down my mail
> from various network accounts, and then will make the mail available via
> IMAP.

> That is, the "client" side of the server will go out and get new mail and
> incorporate it into its storage environment.  The server side of the server
> will allow other clients to access the store via IMAP.

> Does anyone know of such a WIN2K server?

Fetchmail does stuff like this. It is pretty portable, but I don't know
if it is built for WIN2K or not. However, you can run fetchmail on one
system and have it pull mail from another and send it to a third, so
platform isn't particularly relevant.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Philip Hazel <[email-masked]>, Jacob Palme <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Is 8BIT ESTMP really needed 
Date: Thu, 03 May 2001 13:15:10 -0400
Sender: [email-masked]

> I haven't seen any evidence in any RFC or STD saying that blindly (i.e. no
> negotiation) sending raw 8bit data to an MTA is any sort of standard.

nor have I.  the question was about de facto standards, not official standards.

Keith

Date: Thu, 03 May 2001 10:11:15 -0700
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: pop in, imap out?
Sender: [email-masked]

This is sufficiently bizarre, I need to broadcast the query...

When trying to access a user's set of mailboxes from multiple machines -- 
eg, laptop and desktop -- just using operating system file sharing can be a 
performance problem.

So I am looking for some software that will use POP to pull down my mail 
from various network accounts, and then will make the mail available via 
IMAP.

That is, the "client" side of the server will go out and get new mail and 
incorporate it into its storage environment.  The server side of the server 
will allow other clients to access the store via IMAP.

Does anyone know of such a WIN2K server?

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: "Lee Thompson" <[email-masked]>
To: Philip Hazel <[email-masked]>
Cc: Jacob Palme <[email-masked]>, Keith Moore <[email-masked]>, <[email-masked]>
Subject: Re: Is 8BIT ESTMP really needed
Date: Thu, 03 May 2001 09:51:51 -0700
Organization: Seattle Lab, Inc.
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, 3 May 2001 10:06:54 +0100 (BST), you wrote:

> On Wed, 2 May 2001, Jacob Palme wrote:
> 
> > I have an impression that it has become de-facto standard in
> > e-mail today, that you send 8BIT characters without negotiating
> > an 8BIT connection according to RFC 1652?
> >
> > Is this right?
> 
> 
> On Wed, 2 May 2001, Keith Moore wrote:
> 
> > my impression is that the de facto standard is to advertise 8bit
> > capability.
> 
> 
> My impression is that *both* are the de-facto standard. The first
> applies to clients; the second applies to servers.

I haven't seen any evidence in any RFC or STD saying that blindly (i.e. no
negotiation) sending raw 8bit data to an MTA is any sort of standard.

-- 
Lee Thompson               Software Engineer
[email-masked]          Voice 425 825-7000  Seattle Lab, Inc.
http://www.seattlelab.com  Fax 425 825-7001    a BVRP Group Company                                               

Date: Thu, 3 May 2001 10:06:54 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Jacob Palme <[email-masked]>, Keith Moore <[email-masked]>
cc: <[email-masked]>
Subject: Re: Is 8BIT ESTMP really needed
Sender: [email-masked]

On Wed, 2 May 2001, Jacob Palme wrote:

> I have an impression that it has become de-facto standard in
> e-mail today, that you send 8BIT characters without negotiating
> an 8BIT connection according to RFC 1652?
>
> Is this right?

On Wed, 2 May 2001, Keith Moore wrote:

> my impression is that the de facto standard is to advertise 8bit
> capability.

My impression is that *both* are the de-facto standard. The first
applies to clients; the second applies to servers.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: [email-masked]
Subject: Re: Is 8BIT ESTMP really needed 
Date: Wed, 02 May 2001 17:07:24 -0400
Sender: [email-masked]

my impression is that the de facto standard is to advertise 8bit 
capability.

Keith

> I have an impression that it has become de-facto standard in
> e-mail today, that you send 8BIT characters without negotiating
> an 8BIT connection according to RFC 1652?

Date: Wed, 2 May 2001 19:31:49 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Is 8BIT ESTMP really needed
Sender: [email-masked]

I have an impression that it has become de-facto standard in
e-mail today, that you send 8BIT characters without negotiating
an 8BIT connection according to RFC 1652?

Is this right?
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: [email-masked]
To: <[email-masked]>
Subject: Conference Calls For Less                         21712
Date: Wed, 02 May 2001 04:23:51 -0700
Sender: [email-masked]

<HTML><HEAD><TITLE>Take Control Of Your Conference Calls</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12=
52">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY vLink=3D#c0c0c0 link=3D#c0c0c0 bgColor=3D#ffffff leftMargin=3D0><FON=
T 
face=3Darial,helvetica>
<P>
<CENTER>
<TABLE width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><B><FONT color=3D#000066 size=3D6>Long Distance 
      Conferencing<BR>Only <U>18 Cents</U> Per 
Minute</B></FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#ff0000 size=3D5><B>Connects Up To 100 Participants!</B><=
/FONT> 
<P>
<TABLE width=3D350 border=3D0>
  <TBODY>
  <TR>
    <TD><FONT size=3D3><B>
      <LI>No setup fees 
      <LI>No contracts or monthly fees 
      <LI>Call anytime, from anywhere, to anywhere 
      <LI>International Dial In 18 cents per minute 
      <LI>Simplicity in set up and administration 
      <LI>Operator Help available 24/7 </B></FONT></LI></TD></TR></TBODY><=
/TABLE>
<P>
<TABLE width=3D500 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#ff0000 size=3D60><B><FONT size=3D5>G=
et the best 
      quality, the easiest to use, and lowest rate in the 
      industry.</B></FONT></FONT></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#000066 size=3D4>If you like saving m=
oney, fill 
      out the form below and one of our consultants will contact 
  you.</FONT></TD></TR></TBODY></TABLE>
<P><FONT color=3D#000066 size=3D2>Required Input Field<FONT color=3D#ff000=
0 
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D#333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D#ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:[email-masked]?subject=3DConference_Inquir=
y 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D"100%">
        <TBODY>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 
          size=3D2>Name*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Company 
            Name*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Web 
            Address*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Business 
            Phone*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Email 
            Address*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 size=3D2=
>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D"Submit Information" name=3Dsubmit> 
    </FORM></P></TD></TR></TBODY></TABLE>
<P>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#000000 
      size=3D1>This email is to those persons that have contacted Conferen=
ce Calls 
      for Less regarding available services or product information. If thi=
s 
      email is reaching you in error and you feel that you have not contac=
ted 
      us, <FONT color=3D#666666><A 
      href=3D"mailto:[email-masked]?subject=3DRemove_Conferencing">C=
lick 
      here</A></FONT>. We will gladly remove you from our mailing 
      list.</FONT><BR></TD></TR></TBODY></TABLE></P></CENTER></FONT></BODY=
></HTML>