Subject: Re: Translation of the subject header
From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Date: Tue, 26 Dec 2000 00:22:29 -0500
List-Id: <ietf-822.imc.org>

message-id shoudl be different for each translation and different
from the message-id of the multipart/alternative.

Keith

Date: Mon, 25 Dec 2000 23:00:39 +0800
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Translation of the subject header
Sender: [email-masked]

Question 1: Am I correct in that if I want to provide the
"Subject" header in more than one language, I have to use
the Message/rfc822 content-type for each of the language
alternatives.

Question 2: If yes to question 1, should the "Message-ID",
"From", "To" and other headers be repeated in each rfc822
body  part (as I have done below for the English version,
but  not for the German and French version)?

Question 3: If yes to question 2, should the "Message-ID"
be different for each translation and different from
the Message-ID of the multipart/alternative?

Message-ID: [email-masked]
From: John Smith <[email-masked]>
Content-Type: multipart/alternative; boundary="boundary 1"
To: Tropical Flowers Mailing List <[email-masked]>
Subject: (en) Orchids

--boundary 1
Content-Language: en
Content-Type: Message/rfc822

Message-ID: [email-masked]
From: John Smith <[email-masked]>
To: Tropical Flowers Mailing List <[email-masked]>
Content-Type: Text/plain; charset=iso-8859-1
Content-Language: en
Subject: (en) Orchids

Orchids are beautiful.
--boundary 1
Content-Language: de
Content-Type: Message/rfc822

Content-Type: Text/plain; charset=iso-8859-1
Content-Language: de
Subject: (de) Orchideen

Orchideen sind schön.
--boundary 1
Content-Language: fr
Content-Type: Message/rfc822

Content-Language: fr
Subject: (fr) Orchidée

Orchidée sont beau.
--boundary 1--
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: [email-masked]
DATE: 21 Dec 00 1:39:24 PM
SUBJECT: Improve your stepfamily life
Sender: [email-masked]

Does your stepfamily life resemble a soap opera more than it does the Brady
Bunch?

The Stepfamily Association of America invites you to participate in THE
NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans
Marriott Hotel.

This is an opportunity, designed by knowledgeable professionals, in
stepfamilies themselves, to help you:
* Make your remarriage a success
* Create bonds with your stepchildren
* Help your children adjust emotionally
* Manage money matters unique to your family
* Get more help from legal, financial, psychological advisors
* Overcome stepfather and stepmother stereotypes
* Elicit cooperation from your children's schools
* Bring more harmony into family life

Complete conference details at http://www.edupr.com
REGISTER ONLINE!

Attend, and also enjoy Mardi Gras week in New Orleans!

Special discounts for couples, students, groups.

HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND
AIRLINE SEATS FILL Special rates for conference attendees. Visit
http://www.edupr.com for discounts. Childcare available through a bonded
local service.

Up to 17 professional development credits available if you are an 			
educator, clinician, financial planner, social worker.

Questions? Email [email-masked]

If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience.

From: [email-masked]
Date: Mon, 18 Dec 2000 14:55:48 -0700 (PDT)
Subject: Re: DSN requests via headers?
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> > Now consider DSNs. Here the tradeoff is very different: Carrying the
> > information in the envelope has some costs associated with it, but the
> > benefit is that the resulting mechanism is reliable. A header-based
> > mechanism is inherently unreliable. The WG debated this and decided that
> > reliability was worth the cost. And while I'm sure that the purists were
> > pleased that this envelope information didn't get added to the header, I
> > don't recall this as being a deciding factor.

> The problem, here, though is that the actual choice is very often between
> an unreliable implementation (via header fields) and a useless
> implementation (via envelope, which doesn't happen to be supported end-to-
> end, and thus cannot work end-to-end).

> And yes, I really do believe that the current definition is practically
> worthless. Far too many MUAs and MTAs don't support it, and I see no signs
> of this changing in the near future.

It is certainly true that a number of MTAs and UAs don't support DSNs. However,
a very significant number of them do, including most of the major players, so
many that at least in my own experience I find that when I use DSNs they work
most of the time. And even when they don't work up to final delivery I get a
result that is at least of some utility -- often knowing that a messasge is no
longer on the local server is sufficient.

Bottom line is that I disagree with your assessment that not enough clients
and servers support this extension to be useful.

> Now, a header solution is certainly less reliable, but I suspect it would
> have the desired effect in significantly more situations.

This approach was tried, albeit informally, for many years prior to the
development of NOTARY. But again speaking from my own experience, I found
that this mechanism was almost never worth the bother of using it.

So once again I disagree with you -- I think your prediction that such a
scheme, were it developed now, would somehow deploy to a much greater extent
than DSns have, is hopelessly optimistic. (And remember that were we to switch
we'd effectively be starting over.)

And finally, remember that if what you're after is a true end to end header
based receipt, we have one of these too. It s called an MDN and it is defined
in RFC 2298. The semantics are somewhat different, of course, and that makes it
a useful service to have in addition rather than isntead of, DSNs.

				Ned

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: DSN requests via headers? 
Date: Mon, 18 Dec 2000 18:02:51 -0500
Sender: [email-masked]

> Normal people measure the reliability of a return-receipt system as the
> chance of finding out whether the message was successfully delivered.
> 
> An end-to-end design is much better for this than a link-level design:
> it's much easier to implement, and it doesn't need support from relays.

provided, of course, that the delivery notification facility is
part of the design from the beginning, and that the recipient 
end points are mostly willing to generate delivery notifications...
neither of which is true in the real world.

> DSN proponents have a different notion of reliability. They think
> they've done their job if the user receives a bounce saying ``This
> message was relayed to a system that won't tell you what happens.''

not necessarily what the sender wants, but it's the best that MTAs
can reasonably do given the above constraints.

> In theory, a link-level system can guarantee that the user will always
> receive some sort of bounce, while an end-to-end system can't. So DSN
> proponents say that link-level systems are ``reliable'' and end-to-end
> systems are ``inherently unreliable,'' even though users actually find
> end-to-end systems more reliable.

users do find end-to-end systems more reliable if the recipient ends 
actually honor the requests.  but it's a big "if".

Keith

Date: 18 Dec 2000 21:15:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: DSN requests via 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]  wrote on 18.12.00 in <[email-masked]>:

> Now consider DSNs. Here the tradeoff is very different: Carrying the
> information in the envelope has some costs associated with it, but the
> benefit is that the resulting mechanism is reliable. A header-based
> mechanism is inherently unreliable. The WG debated this and decided that
> reliability was worth the cost. And while I'm sure that the purists were
> pleased that this envelope information didn't get added to the header, I
> don't recall this as being a deciding factor.

The problem, here, though is that the actual choice is very often between  
an unreliable implementation (via header fields) and a useless  
implementation (via envelope, which doesn't happen to be supported end-to- 
end, and thus cannot work end-to-end).

And yes, I really do believe that the current definition is practically  
worthless. Far too many MUAs and MTAs don't support it, and I see no signs  
of this changing in the near future.

Now, a header solution is certainly less reliable, but I suspect it would  
have the desired effect in significantly more situations.

MfG Kai

Date: 18 Dec 2000 21:24:26 -0000
Mail-Followup-To: [email-masked]
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: DSN requests via headers?
Sender: [email-masked]

Normal people measure the reliability of a return-receipt system as the
chance of finding out whether the message was successfully delivered.

An end-to-end design is much better for this than a link-level design:
it's much easier to implement, and it doesn't need support from relays.

DSN proponents have a different notion of reliability. They think
they've done their job if the user receives a bounce saying ``This
message was relayed to a system that won't tell you what happens.''

In theory, a link-level system can guarantee that the user will always
receive some sort of bounce, while an end-to-end system can't. So DSN
proponents say that link-level systems are ``reliable'' and end-to-end
systems are ``inherently unreliable,'' even though users actually find
end-to-end systems more reliable.

(In fact, DSN proponents are not telling the truth when they make this
guarantee. Sendmail 8.6.10 through 8.9.3 with the popular noreceipts
option will accept DSN requests and then throw them away.)

This has nothing to do with Alvestrand's screwed-up layering concepts,
or with minor syntax details of where link-level envelope information
appears in an SMTP conversation.

---Dan

From: [email-masked]
Date: Mon, 18 Dec 2000 09:13:09 -0700 (PDT)
Subject: Re: DSN requests via headers?
To: Jacob Palme <[email-masked]>
Cc: [email-masked], Mark Wickens <[email-masked]>
Sender: [email-masked]

> At 15.58 -0800 00-12-14, Harald Alvestrand wrote:
> >At 18:20 14/12/2000 -0500, Mark Wickens wrote:
> >>Hello,
> >>
> >>I am interested in opinions on the feasibility of transmitting DSN requests
> >>by means of message headers rather than SMTP (as RFC 1891 describes).
> >
> >This was debated extensively at the time the documents were written,
> >and the conclusion at the time was that the layering violation of
> >using headers for this was just too distasteful for serious
> >consideration.

> There are other layering violations which have been accepted. For
> example the "Received" RFC822 header obviously belongs to the message
> transport layer, but is still part of RFC822. Why is this allowed, if
> layering violations are so distaseful?

It's a partly a matter of when things were designed and partly a matter of
costs versus benefits.

The cost of having a separate envelope structure is pretty high. In the
original design there wasn't much envelope information that needed to be
carried around, so the benefit of having a separate structure for it weren't
great. The result is that it made sense to overload the header in this simple
way, even though it is something of a layering violation.

Now, over the years we've added considerably to the amount of envelope
information we carry around, and this begs the question of whether we would
have been better off with an exsensible envelope structure in the beginning.
But frankly, when I look at X.400's envelope/header design, with its many
corner cases,  implementation issues, and general confusion, I'm not sure it is
a good idea even now.  And as I watch the confusion over this stuff in the
current discussions of instant messaging in general and CPIM in particular, I'm
even less sure. This may be a case of the right being the enemy of the good. We
really may be better off having an envelope that's really hard to extend (and
which has some layering violations inherent in its use) and a header format
that's very easy to extend.

Now consider DSNs. Here the tradeoff is very different: Carrying the
information in the envelope has some costs associated with it, but the benefit
is that the resulting mechanism is reliable. A header-based mechanism is
inherently unreliable. The WG debated this and decided that reliability was
worth the cost. And while I'm sure that the purists were pleased that this
envelope information didn't get added to the header, I don't recall this as
being a deciding factor.

				Ned

Date: Sat, 16 Dec 2000 23:34:26 +0800
To: <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: DSN requests via headers?
Cc: "Mark Wickens" <[email-masked]>
Sender: [email-masked]

At 15.58 -0800 00-12-14, Harald Alvestrand wrote:
>At 18:20 14/12/2000 -0500, Mark Wickens wrote:
>>Hello,
>>
>>I am interested in opinions on the feasibility of transmitting DSN requests
>>by means of message headers rather than SMTP (as RFC 1891 describes).
>
>This was debated extensively at the time the documents were written, 
>and the conclusion at the time was that the layering violation of 
>using headers for this was just too distasteful for serious 
>consideration.

There are other layering violations which have been accepted. For
example the "Received" RFC822 header obviously belongs to the message
transport layer, but is still part of RFC822. Why is this allowed, if
layering violations are so distaseful?
-- 
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: "Soegi Hartono" <[email-masked]>
cc: "Keith Moore" <[email-masked]>, "Mark Wickens" <[email-masked]>, [email-masked], [email-masked], "Soegi Hartono" <[email-masked]>
Subject: Re: "Delivery Service Notification" 
Date: Fri, 15 Dec 2000 22:44:13 -0500
Sender: [email-masked]

> Hi there, I was wondering if I could use any e-mail program that does not
> have the "Delivery Service Notification" feature to have
> DSN by adding special syntax on the recepient field.

nope.

From: [email-masked]
To: Soegi Hartono <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Delivery Service Notification 
Date: Fri, 15 Dec 2000 13:07:47 -0500
Sender: [email-masked]

--==_Exmh_1007677728P
Content-Type: text/plain; charset=us-ascii

On Fri, 15 Dec 2000 09:45:34 PST, Soegi Hartono said:
> Hi there, I was wondering if I could use any e-mail program that does not
> have the "Delivery Service Notification" feature to have
> DSN by adding special syntax on the recepient field.

No.

Your e-mail program must support it.

I suppose a company *could* come up with some proprietary hack for their
e-mail program that only worked with their e-mail server, that did it via
syntax in the recipient field.  But I think everybody except Microsoft
has learned that's not the way to do it....
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

--==_Exmh_1007677728P
Content-Type: application/pgp-signature

--==_Exmh_1007677728P--

From: "Soegi Hartono" <[email-masked]>
To: "Keith Moore" <[email-masked]>, "Mark Wickens" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Soegi Hartono" <[email-masked]>
Subject: "Delivery Service Notification"
Date: Fri, 15 Dec 2000 09:47:22 -0800
Disposition-Notification-To: "Soegi Hartono" <[email-masked]>
Sender: [email-masked]

Hi there, I was wondering if I could use any e-mail program that does not
have the "Delivery Service Notification" feature to have
DSN by adding special syntax on the recepient field.

Thanks

Soegi

From: "Soegi Hartono" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Delivery Service Notification
Date: Fri, 15 Dec 2000 09:45:34 -0800
Disposition-Notification-To: "Soegi Hartono" <[email-masked]>
Sender: [email-masked]

Hi there, I was wondering if I could use any e-mail program that does not
have the "Delivery Service Notification" feature to have
DSN by adding special syntax on the recepient field.

Thanks

Soegi

Date: Fri, 15 Dec 2000 09:41:54 -0800
From: Soegi Hartono <[email-masked]>
To: [email-masked], [email-masked]
Subject: Delivery Service Notification
Sender: [email-masked]

Hi there, I was wondering if I could use any e-mail program that does not have the "Delivery Service Notification" feature to have 
DSN by adding special syntax on the recepient field.

Thanks

Soegi

From: Keith Moore <[email-masked]>
To: "Mark Wickens" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: DSN requests via headers? 
Date: Thu, 14 Dec 2000 22:35:28 -0500
Sender: [email-masked]

> I am interested in opinions on the feasibility of transmitting DSN requests
> by means of message headers rather than SMTP (as RFC 1891 describes).

it's not feasible; at least, not if you want anything resembling
backward compatibility, reliability, or robustness.

Keith

Date: Thu, 14 Dec 2000 15:58:46 -0800
To: "Mark Wickens" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Harald Alvestrand <[email-masked]>
Subject: Re: DSN requests via headers?
Sender: [email-masked]

At 18:20 14/12/2000 -0500, Mark Wickens wrote:
>Hello,
>
>I am interested in opinions on the feasibility of transmitting DSN requests
>by means of message headers rather than SMTP (as RFC 1891 describes).

This was debated extensively at the time the documents were written, and 
the conclusion at the time was that the layering violation of using headers 
for this was just too distasteful for serious consideration.

>  The
>benefit of using headers would be that they pass through non-supporting
>MTAs, while the SMTP method is thwarted upon encountering an MTA that knows
>nothing about the DSN extension.

this is a feature, not a bug. See the description of RELAYED.
(Microsoft Exchange 5.5 found the only way to make this feature non-useful. 
However, Exchange 2000 can apparently be configured for correct DSN 
generation. Life is not without hope.)

>I realize that only a subset of the request functionality described in RFC
>1891 may be possible. The first thing that comes to mind is that headers
>would not provide an easy way to do per-address requests.
>
>Is this an idea worth pursuing or one doomed to failure?

The functionality of MDNs (RFC 2298) is probably worth looking at.
--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

From: "Mark Wickens" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: DSN requests via headers?
Date: Thu, 14 Dec 2000 18:20:19 -0500
Importance: Normal
Sender: [email-masked]

Hello,

I am interested in opinions on the feasibility of transmitting DSN requests
by means of message headers rather than SMTP (as RFC 1891 describes). The
benefit of using headers would be that they pass through non-supporting
MTAs, while the SMTP method is thwarted upon encountering an MTA that knows
nothing about the DSN extension.

I realize that only a subset of the request functionality described in RFC
1891 may be possible. The first thing that comes to mind is that headers
would not provide an easy way to do per-address requests.

Is this an idea worth pursuing or one doomed to failure?

Thanks,
Mark
--
Mark Wickens
emailtopia

From: [email-masked]
DATE: 05 Dec 00 4:37:56 PM
SUBJECT: 1+1=2
Sender: [email-masked]

The Internet's Finest and Most Reliable Bulk Email Provider!

Since 1996, Tech Data Technologies has provided bulk email service to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced, direct email technology, employed by only a knowledgeable few in the world. Our expert programmers have made it possible for us to penetrate any email blocking filter in use.

We have over 120 million active email addresses, increasing our list at the rate of half a million to one million a month. We will put your product or service instantly and directly into the hands of millions of prospects! You will have instant, guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours.

Our email addresses are sorted by country, state and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience!

Your message can be presented in any language you wish, as plain text if you desire simplicity, or in html with color and graphics.

Call us for a free consultation at (323)- 851- 8386  [U.S.A.]. We are open 24 hours a day, 7 days a week. No one understands the global market like we do. 

For a limited time, take advantage of our holiday special -- two million general U.S. emails for just $450 per million! We include, at no cost, a bullet proof email address for 30 days, a $400 value!

BULK EMAIL PRICES

   500,000........................$375
   750,000........................$562
1,200,000........................$720
1,600,000..................    ...$960
3,000,000......................$1,500
3,000,000+ ...................PLEASE CALL FOR A QUOTE

Resellers welcome. We accept Visa, MasterCard and check by FAX.

DON'T WAIT! LET TECH DATA TECHNOLOGIES BE YOUR PARTNER!!

Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below).To Remove Yourself From This List: reply to this email with the email
address that you would like removed and the word REMOVE in the subject heading.