Subject: [EAI] Local-Part auto converting ?

From: "abel" <[email-masked]>
Date: Wed, 29 Nov 2006 10:45:33 +0800

Doese EAI discuss "local-part" converting algorithm?

In Downgrade draft said:
Trace headers:  Received: headers MUST NOT be target of downgrading
because they do not contain Non-ASCII mail addresses.

In utf8header draft said:
Internationalized domain names in Received fields must be transmitted
in punycode form.  "For" fields containing internationalized
addresses are prohibited

In smtpext draft said:
Internationalized domain names in Received fields MUST be transmitted
in the punycode form.
 
>From the above we know that, Trace Field should be puny code , But in 
general, trace field general will be part of the envelope
information. If the original mail is eai-aware and pickup UTF8 
information, whether it is really necessary to puny code ?
Why not UTF8 in EAI to EAI mail ?
We can see that "Trace Field" should be sent in ASCII from above. But in
general, trace fields are the SMTP routing path information. Is it
really necessary to convert them to ASCII when both SMTP client/server
side support EAI?

Another question is that if we have to convert EAI address => ASCII
address without ALT-ADDRESS, we will need a converting algorithm to do
that. I'm afraid this is not covered by current discussion.

Abel

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Yangwoo Ko <[email-masked]>
Date: Wed, 29 Nov 2006 12:58:16 +0900

> that. I'm afraid this is not covered by current discussion.
Idea of autonomic converting (without user involvement) was rejected
at the EAI WG preparation phase.

Use of ATOMIC was removed from documents at IETF 66 EAI WG
meeting.

Regards

---

From: "abel" <[email-masked]>
Date: Wed, 29 Nov 2006 12:31:14 +0800

So, if a non-EAI-aware MTA sent mail to EAI-aware server , the RCPT address
is ASCII  (no ALT-ADDRESS),
then EAI server must use MAPPING TABLE  to map this ASCII address to a UTF8
address ?
Can't use autonomic convert ?

> Use of ATOMIC was removed from documents at IETF 66 EAI WG

So, if a non-EAI-aware MTA sent mail to EAI-aware server , the RCPT address
is ASCII ,
does EAI server must use MAPPING TABLE  to map this ASCII address to a UTF8
address ?
Can't  use autonomic convert ?

Abel

---

From: Yangwoo Ko <[email-masked]>
Date: Wed, 29 Nov 2006 14:28:18 +0900

There is no in-transit upgrade defined in the current set of
documents. I don't see a reasonable way to do this without
breaking the model of envelope/message separation.

If an MTA has an access to an (imaginary) directory that
provides very persistent, reliable, and unique mapping
between addresses, it can do the upgrade. Do you happen
to mean this one?

As far as I understand from discussions so far in this group,
information loss during the downgrade is inevitable. That is
one of reasons why we call it "down"-"grade" rather than
translation or others.

Regards

---

From: "abel" <[email-masked]>
Date: Wed, 29 Nov 2006 14:53:57 +0800

> between addresses, it can do the upgrade. Do you happen
Yes, that's my one of points

But another issue is when i got a UTF8 address without ALD-ADDRESS,
How do i sent message via non-EAI server to this UTF8 address ?
Without ALD-ADDRESS,I think the UTF8 address converts algorithm is in need,
I don't wanna my server have two sets of accounts or a big account mapping
tables.

Another doubt that why trace field have to puny code , why not UTF8 in an
pure EAI mail ?
Trace Fileds include "Return-Path" and 'for' clause of Received, in usual,
Return-Path is envelope
from,'for' is envelope to , if those address (from/to) convert to puny code,
Return-Path will double
bounce potentially, 'for' of puny code is hard to trace message.

Abel

---

From: Yangwoo Ko <[email-masked]>
Date: Wed, 29 Nov 2006 16:08:28 +0900

> How do i sent message via non-EAI server to this UTF8 address ?

In that case, the mail should be rejected or NDN is generated
and returned.

> bounce potentially, 'for' of puny code is hard to trace message.

If "Trace-Fields" include non ASCII, they should be target of
downgrade. In other words, an MTA should be allowed to modify
(or changing UTF-8 address to all ASCII address) existing
Trace-Fields added by previous hop MTAs. This is NOT allowed
as far as I know.

---

From: Kari Hurtta <[email-masked]>
Date: 29 Nov 2006 09:28:35 +0200

> bounce potentially, 'for' of puny code is hard to trace message.

As far I understanstand 'for' do not allow non-ascii address.

If mail is sent to UTF8 envelope recipient, 'for' is not generated.
In general 'for' is not generateted also, if mail have several envelope recipients.

And on syntax of Received: -header field there is no place for envelope sender.

Return-Path header field is generated when mail is disposed to mailbox.
It is not on mail which is on transit.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 29 Nov 2006 09:47:46 +0200

> I don't wanna my server have two sets of accounts or a big account mapping

My understanding is following:

If envelope recipient address is UTF8 address, it is assumed that mail do not
hit to  non-EAI server  (or some kind private tunneling mechanism is arranged).

If envelope sender address is UTF8 address, mail is either bounced or
server provieds some fancy gatewing service (I wrote about these some time ago).

If address on header field is UTF8, header field is encapsulated. After that
mail may miss some address header fields. 

( If only domain part of address is UTF8, it can be converted to punycode form.
  But subject talk about Local-Part, so I assume that UTF8 address on question 
  means address with UTF8 local part.)

/ Kari Hurtta

---

From: "abel" <[email-masked]>
Date: Wed, 29 Nov 2006 16:14:30 +0800

> As far I understanstand 'for' do not allow non-ascii address.
Agree.

if  one recipient and local-part is UTF8, 'for' need to auto convert
local-part,
to follow this converting algorithm , it should be used in MAIL/RCPT without
ALT-ADDRESS.
I think we need a default  if MUA has no ALT-ADDRESS.

> It is not on mail which is on transit.
if it's a catch-all server, how to bounce  mail with a ASCII 'Return-Path'
to UTF8 address ?

---

From: "abel" <[email-masked]>
Date: Wed, 29 Nov 2006 16:34:05 +0800

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 29, 2006 3:47 PM
Subject: Re: [EAI] Local-Part auto converting ?

> hit to  non-EAI server  (or some kind private tunneling mechanism is
arranged).
Hmm,I think it's possible to hit to non-EAI server. Such as
[email-masked] = [email-masked] ,
but i can't subscribe with the UTF8 address, So I using
yn--PunyCode@Domain-Part ,
that will auto convert (upgrade ) to '楊' (Yang) mailbox. Cause my testbed
is eai island.
If we don't have auto convert method , in feature ,that will affect our
promotion on EAI mail.

> server provieds some fancy gatewing service (I wrote about these some time
ago).
May you describe ideas about "fancy gatewing service " ?

Abel

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 29 Nov 2006 09:38:06 +0100

> Can't  use autonomic convert ?
That's a local decision; a server can use whatever mapping table it 
wants for its own users, including one produced by an algorithm such as 
Punycode.

But it cannot assume that any other server does the same thing.

                   Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 29 Nov 2006 09:50:59 +0100

> If we don't have auto convert method , in feature ,that will affect our
I don't understand this scenario. Let's see if I can flesh it out in detail.

If you want to subscribe to a mailing list that supports UTF8SMTP, you 
can enter the subscription request:

- Through a Web form. No problem - the web supports UTF-8.
- Through a "subscribe" request where the address is in the body of the 
message. No problem - mail bodies support UTF-8.
- Through a "subscribe" request where the address in the "from:" field 
of the message is subscribed.

In the last case, you have two cases:

- You send from inside your "EAI island". No problem.
- You send from outside your "EAI island", so your message doesn't have 
UTF-8 in the From: field.

You then have three possibilities, I think:

- Mail from the mailing list is delivered to your ASCII address. No 
technical problem.
- You prevail upon your sysadmin to enable UTF8SMTP locally, so that 
you're part of the "EAI island".
- The mailing list has access to some database that maps your ASCII 
address to an UTF-8 address.

One possible form of database is a table that says "twnic.tw uses 
punycode for its localparts" - presumably because the twnic.tw 
administrator has told the mailing list administrator that this is the case.

But if your mailing list service gets a message from 
[email-masked] (which you haven't seen before), there is no 
information in the table  allowing you to interpret the localpart.

Is this the scenario you see as problematic?

                       Harald

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 29 Nov 2006 14:18:06 +0200 (EET)

>>> abel
[ Charset UTF-8 unsupported, converting... ]

>From archive
    http://article.gmane.org/gmane.ietf.ima/548

for example.

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Nov 2006 16:02:55 +0100

> I think we need a default  if MUA has no ALT-ADDRESS.

If I got that right your proposal is about a...

 RCPT TO:<[email-masked]>

...without alt-address, relayed by a server wishing to
add a "for" clause in its timestamp line.

For the right hand side the spec. apparently says that
it should use xn--whatever.domain.example

In other words the relay can't be completey stupid, it
has to know how to generate a punycode form of a given
UTF-8 domain.  That's okay, it has to figure out what
UTF-8.domain.example is, for that it has to use DNS,
and so it will also know how to handle punycode.

For the left hand side (local part) it could use some
ad hoc notation in its "for" clause, percent-encoded or
similar, but a default would be better.  It's not
required to be a "real" ASCII address, but we better
make sure that it's a sytactically invalid local part -
if it's invalid it can't be (ab)used as "real" address.

Something like...

 for (hh:hh:hh:hh)@xn--whatever.domain.example

...could do the trick, "(", ":", and ")" aren't allowed
in dot-atom-text.  Is that in essence your proposal for
a "for"-clause ?  Ignoring the syntactical details, if
"(" and ")" is a bad idea we could find something else.

Frank

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Nov 2006 10:19:29 -0500

> "(" and ")" is a bad idea we could find something else.

Of course, "(...)" is a comment.  So the example above is
equivalent, in every way, to 
   for (bogus-nonsense)@xn--whatever.domain.example

That takes us back to where I thought we were several weeks ago,
i.e., simply dropping "for" clauses on downgrade, just as they
are dropped (or not included in the first place) in all sorts of
other cases, such as multiple-recipient messages.   One could,
of course say that, instead of dropping the "for" clause in this
case, one MAY transform it into
   "(for undowngradable-utf8-string@" punycode-domain ")"

But I have been unable to understand why we are having this
discussion again, so perhaps I'm still missing something.

    john

---

From: Yangwoo Ko <[email-masked]>
Date: Thu, 30 Nov 2006 00:18:43 +0900

Frank Ellermann wrote:
> ..without alt-address, relayed by a server wishing to
> ..could do the trick, "(", ":", and ")" aren't allowed

If we decided to "encode" local part, I want it be
applied to the other side (i.e. domain part) so that
the whole address can be consistently processed.

For example, with one encoding to whole address,
we just need to copy and paste the "encoded" address to
a converter to see what it originally was.

Then, how about applying puny code to local part?
Well, my gut feeling is against it. Because puny
code is expected to be used for domain names.

---

From: Yangwoo Ko <[email-masked]>
Date: Thu, 30 Nov 2006 00:41:42 +0900

> discussion again, so perhaps I'm still missing something.

I had the same question. I found that there are several
cases where "for" clauses are not generated. (Multiple
recipients, Bcc, and others)

[[ Email Tutorial Session

Then, what is "for" for? What are typical examples of
automated processing of "for" clauses? Or, is it a
MUST/SHOULD in some RFC? ]]

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Nov 2006 16:40:45 +0100

John C Klensin wrote:

> I have been unable to understand why we are having this

No, it's me, I didn't know that it's a design decision if
a "for" clause can't work in UTF8SMTP without alt-address.

Checking the drafts, smtpext-02 says in 2.7.2:

| Addresses in "for" clauses need further examination and 
| might be treated differently depending on [EAI-utf8header].

Maybe it should say: "'for'-clauses cannot be used without
alt-address, if the local part is UTF-8" (or similar).

 
 
> code is expected to be used for domain names.

ACK, it MUST NOT be similar to any possible address if
it's no "real" address, the spammers would try to abuse
it without checking the details of RFC 2821 or 2822.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Nov 2006 16:58:16 +0100

Yangwoo Ko wrote:

> Then, what is "for" for? What are typical examples
> of automated processing of "for" clauses?

Header analysis if something doesn't work - if I get
a non-delivery report "[email-masked] - no such user"
and never sent a mail to foo@bar, an earlier "for"-
clause can help to identify what's it about:

Received: from one by two for [email-masked] ...
Received: from me by one for [email-masked] ...

Apparently user@foo forwards his mail at one to the
address foo@bar, and I'd know if I really tried to
send a mail to user@foo.

It's a similar situation if the mail arrives at 
foo@bar with To: user@foo, and this user forgot
that he still has a forwarding arrangement at 
server one.

> is it a MUST/SHOULD in some RFC?

No.  In the worst case it's a SHOULD NOT for the
privacy reasons stated in the 251-section.  I'm too
lazy to check this.  It's only for forensics.

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 29 Nov 2006 17:05:46 +0100

> MUST/SHOULD in some RFC? ]]
We thought it was a good idea 20 years ago.

It's sometimes useful in debugging alias files, or figuring out which 
particular obscure mailing list I've forgotten to unsubscribe from.

Neither of the statements above means that it's a good idea today.

And AFAIK, it's not a MUST/SHOULD in any RFC.

                    Harald

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Nov 2006 11:16:35 -0500

> MUST/SHOULD in some RFC? ]]

Automated processing of anything that appears in a "Received:"
header field is essentially prohibited by the standards.  Those
fields are generally only intended for tracing and debugging.
The prohibition is sometimes violated in practice, but
production implementations that violate it have learned to be
_very_ careful to expect, and not fail or do something stupid
because of, unexpected syntax, odd constructions, unusable
information, and so on.

I don't remember the whole history and may not have ever known,
but "for" seemed to be a good idea in a different time.   I can
remember a few reasons, such as tracking address changes across
gateway-type boundaries.  At least in theory, the right place to
track address changes due to forwarding is in "Resent-" fields,
so information in "for", if present, would be redundant and,
conversely, if "for" is needed to straighten out forwarding
issues, one is already in trouble.  Over the years, the
recommendations about their use have become more and more
restricted.  That process accelerated when it was pointed out
that they could accidentally breach the security of private
information, with the ever-fragile "blind-copy" concept being
one of the worst cases.

What we are left with, in essence, is that one may include a
"for" clause in a single-recipient message in which the
recipient address also appears in the "To:" or "Cc:" header.
But their use in all other cases is strongly discouraged.  I
believe that there are several MTAs implementers out there that
have decided that the complexity of evaluating the conditions
under which "for" is safe are complex enough relative to its
value to simply never produce it.  The standard permits that
interpretation, so one can _never_ count on the "for" clause
being present.

So, again getting back to where I thought we were weeks ago, I
believe that:

	* Any "for" clause that contains UTF-8 material should
	be discarded on downgrade. 
	
	* Instead of discarding it, one might plausibly turn the
	entire clause into a comment.   Of course, one could
	devise syntax for use within the comment that explicitly
	identifies the encoding(s) being used, an option that
	does not exist with "for".

In the absence of some compelling argument about the importance
of "for", one compelling enough to override the trend toward
reduction of its use, I think anything beyond the above just
makes the protocol more complicated without adding significant
value.

    john

---

From: Kari Hurtta <[email-masked]>
Date: 29 Nov 2006 19:44:18 +0200

> if it's a catch-all server, how to bounce  mail with a ASCII 'Return-Path'

I think that I'm lost.

I do not see how your question makes sense as comment to may text about
Return-Path header field.

Bounces uses <> as envelope sender address.

Please do not confuse Return-path header field, which is added when mail 
is written to mailbox, with envelope sender address which is carried
with MAIL FROM command on SMTP.

/ Kari Hurtta

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Nov 2006 20:22:40 -0000

>    "(for undowngradable-utf8-string@" punycode-domain ")"

My recollection was that we decided not to include a 'for' at all in a  
Received header for any UTF8SMTP mail. That way nobody could be embarassed  
at having to modify the Received header. There was a suggestion from Chris  
Newman to put the equivalent of a 'for' in a comment (though that would  
imply that one could downgrade comments in Received headers). Of course,  
if you have an alt-address, you can always use that, even if you are still  
hopeful of delivery to the utf8-address.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   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: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Nov 2006 20:28:35 -0000

> Neither of the statements above means that it's a good idea today.

Personally, I find it useful quite often. I receive some (possibly spam)  
whose To: and From: headers make no sense to me. So I look at the Received  
headers to see why it came to me. That way the 'for' field will at least  
tell me why it came to me, and whether I got it as [email-masked],  
or as [email-masked], or as [email-masked] or various other  
possibilities

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Nov 2006 22:00:28 +0100

John C Klensin wrote:

> At least in theory, the right place to track address changes
> due to forwarding is in "Resent-" fields,

That's an interesting statement.  I'm not sure about the theory
in STD 11, and you're probably not talking about RFC 4406.  In
RFC 2822 the MUSTard theory is apparently different:

| 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.

Resent-* is a big mess, also in 4409 8.1 or (probably) in DKIM SSP,
and of course in SenderID after the second SenderID-appeal.

> issues, one is already in trouble.

Anything remotely related to 1123 5.3.6(a) means trouble.

> makes the protocol more complicated without adding significant

If that's clearly documented in one of the next "smtpext" drafts
it's okay.  SMTP has worse problems than this.

Frank

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Nov 2006 17:24:18 -0500

--On Wednesday, 29 November, 2006 22:00 +0100 Frank Ellermann
<[email-masked]> wrote:

>...
> Resent-* is a big mess, also in 4409 8.1 or (probably) in DKIM
> SSP, and of course in SenderID after the second
> SenderID-appeal.

I do not disagree with this.  But "Received: ...for" isn't the
place to try to fix it.

> Anything remotely related to 1123 5.3.6(a) means trouble.

No comment in the context of this WG.

>> In the absence of some compelling argument about the
>> importance of "for", one compelling enough to override the
>> trend toward reduction of its use, I think anything beyond
>> the above just makes the protocol more complicated without
>> adding significant value.
> 
> If that's clearly documented in one of the next "smtpext"
> drafts it's okay.  SMTP has worse problems than this.

I agree that it should be clearly documented.  The WG needs to
figure out whether to prohibit UTF-8 in "for" clauses entirely,
or to require discarding "for" clauses containing UTF-8 material
on downgrading.  In the first case, the relevant text would go
in the "smtpext" draft.  In the second, it might well go in the
"downgrade" document.

    john

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 29 Nov 2006 14:37:10 -0800 (PST)

> I do not disagree with this.  But "Received: ...for" isn't the

Sometime ago I proposed new trace header field for this purpose:
  http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-01.txt
  (also http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-01.html)

You're welcome to send me comments about it and I'll get for -02 version
sometime next year (I've been working on it as well as well as few other
drafts although rather slowly).

I note also that for example Gmail is using sever X- fields for this 
purpose, for example, in particular I see the following in between the 
Received header fields for email that goes though my gmail account:

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Nov 2006 17:40:59 -0500

--On Wednesday, 29 November, 2006 14:37 -0800
"william(at)elan.net" <[email-masked]> wrote:

>>> Resent-* is a big mess, also in 4409 8.1 or (probably) in
>>> DKIM SSP, and of course in SenderID after the second
>>> SenderID-appeal.
>> 
>   (also
> http://www.elan.net/~william/emailsecurity/draft-leibzon-email
> redirection-traceheaders-01.html)
> 

Just make sure you direct comments on it, and initiate
discussion on it, on the SMTP list, not here.  This WG really
cannot start improving/fixing basic SMTP characteristics or we
will never get our work finished.

> I note also that for example Gmail is using sever X- fields
> for this purpose, for example, in particular I see the
> following in between the Received header fields for email that
> goes though my gmail account:
> 
> Received: ...
> X-Forwarded-To: [email-masked]
> X-Forwarded-For: [email-masked] [email-masked]
> Delivered-To: [email-masked]
> Received: ...

Not original, and, unless time-stamped, etc., will cause their
own set of problems.

   john

---

From: "abel" <[email-masked]>
Date: Thu, 30 Nov 2006 09:58:03 +0800

> with MAIL FROM command on SMTP.

Thanks for your comment, I greatly admire your contribution to sendmail.

But according to the draft, it seems, "Return-Path" as well as puny code
(Ascii),
does it confuse ?

Abel

---

From: Kari Hurtta <[email-masked]>
Date: 30 Nov 2006 06:46:37 +0200

> Thanks for your comment, I greatly admire your contribution to sendmail.

But I still did not understand question.

| "abel" <[email-masked]> writes gmane.ietf.ima:
| 
| > > Return-Path header field is generated when mail is disposed to mailbox.
| > > It is not on mail which is on transit.
| > if it's a catch-all server, how to bounce  mail with a ASCII 'Return-Path'
| > to UTF8 address ?
| 
| I think that I'm lost.

What is a scenarion ?  I'm still lost.

> But according to the draft, it seems, "Return-Path" as well as puny code

http://article.gmane.org/gmane.ietf.ima/733

I think that it was intention that Return-Path: header field can store
enevelope sender address from MAIL FROM when mail is stored to mailbox.
Even when it is UTF-8. 

/ Kari Hurtta

---

From: "abel" <[email-masked]>
Date: Thu, 30 Nov 2006 14:50:41 +0800

> enevelope sender address from MAIL FROM when mail is stored to mailbox.

Sorry Kari, I didn't explain  my question clearly, as I know the Trace
Fields include "Return-Path" and "Received".
but the drafts talk about Trace Fields section in "Received" only, so I
wonder that the "Return-Path" produce rule,
Your comment is articulate , Whether it is UTF8 or ASCII,the envelope from
equals "Return-Path" header value.

Abel

---

From: Jeff Yeh <[email-masked]>
Date: Thu, 30 Nov 2006 15:58:32 +0800

I think Abel is trying to say that "Return-Path" is also part of trace 
field. As discussed in earlier post, all trace field must put in ASCII.
For "Received" can skip "for" to bypass the UTF8->ASCII convertion. 
However, the "Return-Path" still need a converting algorithm. Under the 
circumstance of "MAIL FROM is UTF8 without ALT ADDRESS".

Jeff Yeh
-TWNIC

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 30 Nov 2006 10:05:29 +0200 (EET)

> circumstance of "MAIL FROM is UTF8 without ALT ADDRESS".

Idea was that Received: -header field must not be altered on transit.
Therefore ASCII only.

On other hand Return-Path: -header field do not exist when
mail is on transit.    So Return-Path: -header field is different.

On previous discussion answer was when I asked that, that Return-Path: 
-header field should be allowed to store UTF-8.

Return-Path header field may be usefull for MUA. That header field 
is issue for IMAP and POP downgrade.  On SMTP it is supposed to be
non existant.
 
> > equals "Return-Path" header value.

OK.  Your comment about bounce confused me, because bounce do not use
Return-path -header filed  (there is no any header field on mail
which is on transit.)

/ Kari Hurtta

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Nov 2006 12:39:16 -0000

>   http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-01.txt

It seems interesting, though a bit over complicated.

However, my immediate reaction is that your Original-* headers bear some  
slight similarity to our Downgraded header, the main diffewrence being  
that our downgraded approach applied to your Original-* idea would result  
in something like:

Original-Header: Sender: "W. Rabbit" <[email-masked]>

Just a thought. The point of our Downgraded: header, of course, is that  
you are allowed to use RFC 2047 encoding inside it.

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Nov 2006 09:18:32 -0500

--On Wednesday, 29 November, 2006 20:28 +0000 Charles Lindsey
<[email-masked]> wrote:

> On Wed, 29 Nov 2006 16:05:46 -0000, Harald
> Alvestrand<[email-masked]> wrote:
> 
>> It's sometimes useful in debugging alias files, or figuring
>> out which   particular obscure mailing list I've forgotten to
>> unsubscribe from.
>> 
> Personally, I find it useful quite often. I receive some
> (possibly spam)whose To: and From: headers make no sense to
> me. So I look at the Receivedheaders to see why it came to me.
> That way the 'for' field will at leasttell me why it came to
> me, and whether I got it as [email-masked],or as
> [email-masked], or as [email-masked] or various
> otherpossibilities

Of course, if there is more than one member of
"[email-masked]", anything that supplies a "for" with
an individual address in it is violating the specs.

Find a mail system/supplier who will give you access to the
forward-pointing and backward-pointing envelope addresses.  It
will give you just about the same information, _much_ more
reliably.

But it is irrelevant here.  How useful the feature is or isn't
to you is a base SMTP issue, not an EAI one.

    john