Subject: Re: RFC 5321 4.4 Trace info
From: Hector Santos <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Date: Sat, 08 Nov 2008 13:38:08 -0500
List-Id: <ietf-smtp.imc.org>

SM wrote:

> Hi Hector,
> At 06:22 07-11-2008, Hector Santos wrote:
>> In my view, the term "time stamp" should be removed.  The implication 
>> is that a "time stamp" header exist and it is an alternative header to 
>> the Received.  I'm not aware of a "time stamp" header.  If so, what is 
>> its field name?
> 
> In Section 4.1.1.4 of RFC 5321, there is:
> 
>   "When the SMTP server accepts a message either for relaying or for
>    final delivery, it inserts a trace record (also referred to
>    interchangeably as a "time stamp line" or "Received" line) at the top
>    of the mail data."
> 
> The "time stamp" header is not an alternative header to the Received.  
> What the above means is that we might say "time stamp line" and we might 
> say "Received" line but we are referring to the same thing.
 >
 > The Received line provides us with the date and time the message was
 > received.  What we are doing is to "time stamp" the message each
 > time it goes through a relay.
 >

Phew (wiping sweat off head). I'm so glad that is cleared up.  Thanks 
for the clarification because I always wondered if I can add a "Date" 
(a Time Stamp line).

Note: If it wasn't obvious, the above is a poor attempt at sarcasm. :-)

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sat, 08 Nov 2008 09:15:26 -0800
To: Hector Santos <[email-masked]>
From: SM <[email-masked]>
Subject: Re: RFC 5321 4.4 Trace info
Cc: [email-masked]
Sender: [email-masked]

Hi Hector,
At 06:22 07-11-2008, Hector Santos wrote:
>In my view, the term "time stamp" should be removed.  The 
>implication is that a "time stamp" header exist and it is an 
>alternative header to the Received.  I'm not aware of a "time stamp" 
>header.  If so, what is its field name?

In Section 4.1.1.4 of RFC 5321, there is:

   "When the SMTP server accepts a message either for relaying or for
    final delivery, it inserts a trace record (also referred to
    interchangeably as a "time stamp line" or "Received" line) at the top
    of the mail data."

The "time stamp" header is not an alternative header to the 
Received.  What the above means is that we might say "time stamp 
line" and we might say "Received" line but we are referring to the same thing.

The Received line provides us with the date and time the message was 
received.  What we are doing is to "time stamp" the message each time 
it goes through a relay.

>My suggestion:
>
>   1) Since a Received is a required - period and it
>      inherently includes a format with a time stamp, there
>      is no need to mention it in this paragraph.
>
>   2) Thus removing the "time stamp" from the parenthetical clause.

There are multiple occurrences of "time stamp" in RFC 5321.  The term 
can be used interchangeably which is why it's part of the clause 
together with Received.  That's why it worth a mention.

Regards,
-sm 

Date: Fri, 07 Nov 2008 12:53:35 -0800
To: Ivar Lumi <[email-masked]>
From: SM <[email-masked]>
Subject: Re: RFC 5321 4.4 Trace info
Cc: [email-masked]
Sender: [email-masked]

Hi Ivar,
At 01:28 07-11-2008, Ivar Lumi wrote:
>It's now almsot ok. Can you leave "interchangeably" out ? Most have 
>don't have English a main language, this forces to use dictionary ... .
>Just (also referred as "time  stamp" or "Received")  seems do the job.

The editor of the document will most likely take a decision based on 
the comments posted.   As he pointed out in a previous message, there 
is similar text in a previous section and the word "interchangeably" 
is used there.  My personal preference is to keep the word as it 
conveys the fact that we mean the same thing when we say "time stamp" 
or when we say "Received".

I understand that it may be difficult for non-English speakers but 
sometimes the authors cannot avoid that as they don't want a sentence 
to have two or more interpretations.

Regards,
-sm 

Date: Fri, 07 Nov 2008 09:22:04 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: SM <[email-masked]>
CC: Ivar Lumi <[email-masked]>, John C Klensin <[email-masked]>, [email-masked]
Subject: Re: RFC 5321 4.4 Trace info
Sender: [email-masked]

SM wrote:
> 
> Hi Ivar,
> 
> Thanks for providing us with a different perspective of RFC 5321.
> 
> At 23:10 06-11-2008, Ivar Lumi wrote:
>> What about something like:
>> it MUST insert trace time-stamp-line("Received:" header) .... or vice 
>> versa.
>>
>> ("time stamp" or "Received")
>> The "or" in current version is not the best, both terms are noting 
>> same stuff, while "or" refers to choice one or the another.
> 
> Reading Section 4.4 again, I see that the ("time stamp" or "Received") 
> might seem confusing to some people because of the "or".  It is commonly 
> known as the "Received" header.  I wouldn't mind the redundancy if it 
> makes the text clearer to implementors.  I'm leaving in "trace" as the 
> section is about trace information.
> 
>   When an SMTP server receives a message for delivery or further
>   processing, it MUST insert trace (also referred to interchangeably as 
> "time
>   stamp" or "Received") information at the beginning of the message
>   content, as discussed in Section 4.1.1.4.
> 
> Do you find the above clear enough?

In my view, the term "time stamp" should be removed.  The implication 
is that a "time stamp" header exist and it is an alternative header to 
the Received.  I'm not aware of a "time stamp" header.  If so, what is 
its field name?

My suggestion:

   1) Since a Received is a required - period and it
      inherently includes a format with a time stamp, there
      is no need to mention it in this paragraph.

   2) Thus removing the "time stamp" from the parenthetical clause.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Fri, 07 Nov 2008 11:28:19 +0200
From: Ivar Lumi <[email-masked]>
To: SM <[email-masked]>
CC: John C Klensin <[email-masked]>, [email-masked]
Subject: Re: RFC 5321 4.4 Trace info
Sender: [email-masked]

It's now almsot ok. Can you leave "interchangeably" out ? Most have 
don't have English a main language, this forces to use dictionary ... .
Just (also referred as "time  stamp" or "Received")  seems do the job.

SM wrote:
> Hi Ivar,
>
> Thanks for providing us with a different perspective of RFC 5321.
>
> At 23:10 06-11-2008, Ivar Lumi wrote:
>> What about something like:
>> it MUST insert trace time-stamp-line("Received:" header) .... or vice 
>> versa.
>>
>> ("time stamp" or "Received")
>> The "or" in current version is not the best, both terms are noting 
>> same stuff, while "or" refers to choice one or the another.
>
> Reading Section 4.4 again, I see that the ("time stamp" or "Received") 
> might seem confusing to some people because of the "or".  It is 
> commonly known as the "Received" header.  I wouldn't mind the 
> redundancy if it makes the text clearer to implementors.  I'm leaving 
> in "trace" as the section is about trace information.
>
>   When an SMTP server receives a message for delivery or further
>   processing, it MUST insert trace (also referred to interchangeably 
> as "time
>   stamp" or "Received") information at the beginning of the message
>   content, as discussed in Section 4.1.1.4.
>
> Do you find the above clear enough?
>
> Regards,
> -sm

Date: Fri, 07 Nov 2008 00:57:10 -0800
To: Ivar Lumi <[email-masked]>
From: SM <[email-masked]>
Subject: Re: RFC 5321 4.4 Trace info
Cc: John C Klensin <[email-masked]>, [email-masked]
Sender: [email-masked]

Hi Ivar,

Thanks for providing us with a different perspective of RFC 5321.

At 23:10 06-11-2008, Ivar Lumi wrote:
>What about something like:
>it MUST insert trace time-stamp-line("Received:" header) .... or vice versa.
>
>("time stamp" or "Received")
>The "or" in current version is not the best, both terms are noting 
>same stuff, while "or" refers to choice one or the another.

Reading Section 4.4 again, I see that the ("time stamp" or 
"Received") might seem confusing to some people because of the 
"or".  It is commonly known as the "Received" header.  I wouldn't 
mind the redundancy if it makes the text clearer to 
implementors.  I'm leaving in "trace" as the section is about trace 
information.

   When an SMTP server receives a message for delivery or further
   processing, it MUST insert trace (also referred to interchangeably as "time
   stamp" or "Received") information at the beginning of the message
   content, as discussed in Section 4.1.1.4.

Do you find the above clear enough?

Regards,
-sm 

Date: Fri, 07 Nov 2008 09:10:10 +0200
From: Ivar Lumi <[email-masked]>
To: Ned Freed <[email-masked]>
CC: John C Klensin <[email-masked]>, [email-masked]
Subject: Re: RFC 5321 4.4 Trace info
Sender: [email-masked]

What about something like:
it MUST insert trace time-stamp-line("Received:" header) .... or vice versa.

("time stamp" or "Received")
The "or" in current version is not the best, both terms are noting same 
stuff, while "or" refers to choice one or the another.

Ned Freed wrote:
>
>
>> I think right is :  "Time-stamp-line"      - no confusing "Received",
>> because time stamp defines received.
>> (My intentions wasn't nagg on text, just didn't get 100% that part)
>
>> This is because blow bnf syntax for it.
>
>> ....
>
>> The time stamp line and the return path line are formally defined as
>> follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 [4]):
>
>> Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
>> Time-stamp-line = "Received:" FWS Stamp <CRLF>
>
>> ...
>
> I don't support this change. While "time-stamp-line" may be more 
> technically
> correct, even experienced email implementors won't recognize the term 
> and will
> have to search for it. "Received", OTOH, is a much better known and 
> better
> understood term.
>
> I suppose you could say something about a Received: field as specified
> by the time-stamp-line ABNF, but I really see no point in doing so.
>
>                 Ned

Date: Fri, 07 Nov 2008 00:53:39 -0500
From: John C Klensin <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
cc: Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 5321 4.4 Trace info
Sender: [email-masked]

--On Thursday, 06 November, 2008 15:19 -0600 Pete Resnick
<[email-masked]> wrote:

> On 11/6/08 at 12:35 PM -0800, [email-masked] wrote:
> 
>>> I think right is :  "Time-stamp-line"      - no confusing 
>>> "Received", because time stamp defines received.
>> 
>> I don't support this change. While "time-stamp-line" may be
>> more  technically correct, even experienced email
>> implementors won't  recognize the term and will have to
>> search for it. Received", OTOH,  is a much better known and
>> better understood term.
> 
> I agree with Ned about the above suggestion. But 4.4 is easily
> clarified to make it so that folks like Ivar don't get
> confused:
> 
> ... it MUST insert trace (often referred to as "time stamp" or
> "Received") information at the beginning of the message...

I have tentatively made this change in the working draft of
rfc5321bis.   However, please note that this text is redundant
with a paragraph earlier in the document that starts.

# When the SMTP server accepts a message either for relaying
# or for final delivery, it inserts a trace record (also
# referred to interchangeably as a "time stamp line" or
# "Received" line) at the top...

The somewhat abbreviated form of the second parenthetical note
about the alternate terminology may have been induced by the
earlier, longer, form.

If I get motivated, or someone makes a specific suggestion that
seems usable, I will try to eliminate that redundancy.

 -- your friendly editor

Date: Thu, 6 Nov 2008 15:19:48 -0600
To: <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: RFC 5321 4.4 Trace info
CC: Ivar Lumi <[email-masked]>, John C Klensin <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 11/6/08 at 12:35 PM -0800, [email-masked] wrote:

>>I think right is :  "Time-stamp-line"      - no confusing 
>>"Received", because time stamp defines received.
>
>I don't support this change. While "time-stamp-line" may be more 
>technically correct, even experienced email implementors won't 
>recognize the term and will have to search for it. Received", OTOH, 
>is a much better known and better understood term.

I agree with Ned about the above suggestion. But 4.4 is easily 
clarified to make it so that folks like Ivar don't get confused:

... it MUST insert trace (often referred to as "time stamp" or 
"Received") information at the beginning of the message...

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 06 Nov 2008 12:35:00 -0800 (PST)
From: [email-masked]
Subject: Re: RFC 5321 4.4 Trace info
To: Ivar Lumi <[email-masked]>
Cc: John C Klensin <[email-masked]>, [email-masked]
Sender: [email-masked]

> I think right is :  "Time-stamp-line"      - no confusing "Received",
> because time stamp defines received.
> (My intentions wasn't nagg on text, just didn't get 100% that part)

> This is because blow bnf syntax for it.

> ....

> The time stamp line and the return path line are formally defined as
> follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 [4]):

> Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
> Time-stamp-line = "Received:" FWS Stamp <CRLF>

> ...

I don't support this change. While "time-stamp-line" may be more technically
correct, even experienced email implementors won't recognize the term and will
have to search for it. "Received", OTOH, is a much better known and better
understood term.

I suppose you could say something about a Received: field as specified
by the time-stamp-line ABNF, but I really see no point in doing so.

				Ned

Date: Thu, 06 Nov 2008 14:44:50 +0200
From: Ivar Lumi <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 5321 4.4 Trace info
Sender: [email-masked]

I think right is :  "Time-stamp-line"      - no confusing "Received", 
because time stamp defines received.
(My intentions wasn't nagg on text, just didn't get 100% that part)

This is because blow bnf syntax for it.

....

The time stamp line and the return path line are formally defined as 
follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 [4]):

Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
Time-stamp-line = "Received:" FWS Stamp <CRLF>

...

John C Klensin wrote:
> --On Thursday, 06 November, 2008 13:18 +0200 Ivar Lumi
> <[email-masked]> wrote:
>
>   
>> Hi,
>>
>> RFC 5321 4.4. Trace Information When an SMTP server receives a
>> message for delivery or further processing,
>> it MUST insert trace ("time stamp" or "Received") information
>> at the beginning of the message content,
>> as discussed in Section 4.1.1.4.
>>     
>
>   
>> What is meant by "Received" ???
>> When looking time-stamp syntax, isn't it same thing(a bit
>> confusing) ?
>>
>> Any comments would be welcome .
>>     
>
> The sentence in 5321 says exactly what it was intended to.  The
> formal term for that information in RFC 5321 is "trace".  It has
> been called "time stamp" data and a "Received field", the latter
> named after the header itself.  If you find that confusing, how
> would you suggest rewording it?
>  
>    john
>
>
>
>
>   

Date: Thu, 06 Nov 2008 07:27:28 -0500
From: John C Klensin <[email-masked]>
To: Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 5321 4.4 Trace info
Sender: [email-masked]

--On Thursday, 06 November, 2008 13:18 +0200 Ivar Lumi
<[email-masked]> wrote:

> Hi,
> 
> RFC 5321 4.4. Trace Information When an SMTP server receives a
> message for delivery or further processing,
> it MUST insert trace ("time stamp" or "Received") information
> at the beginning of the message content,
> as discussed in Section 4.1.1.4.

> What is meant by "Received" ???
> When looking time-stamp syntax, isn't it same thing(a bit
> confusing) ?
> 
> Any comments would be welcome .

The sentence in 5321 says exactly what it was intended to.  The
formal term for that information in RFC 5321 is "trace".  It has
been called "time stamp" data and a "Received field", the latter
named after the header itself.  If you find that confusing, how
would you suggest rewording it?
 
   john

Date: Thu, 06 Nov 2008 13:18:59 +0200
From: Ivar Lumi <[email-masked]>
To: [email-masked]
Subject: RFC 5321 4.4 Trace info
Sender: [email-masked]

Hi,

RFC 5321 4.4. Trace Information When an SMTP server receives a message 
for delivery or further processing,
it MUST insert trace ("time stamp" or "Received") information at the 
beginning of the message content,
as discussed in Section 4.1.1.4.

What is meant by "Received" ???
When looking time-stamp syntax, isn't it same thing(a bit confusing) ?

Any comments would be welcome .

Thanks,

Date: Tue, 04 Nov 2008 16:37:44 +0200
From: Ivar Lumi <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: SMTP AUTH digest-md5
Sender: [email-masked]

Yep thats hard to notice.

But i coded http universal digest authentication, so using in SASL that 
module ... suddenly calculated response won't match.
Toke a bit time to get what ffff is going on, so seeing this all came 
together.

Most of times it won't be problematic.

Alexey Melnikov wrote:
> Hi,
>
> Ivar Lumi wrote:
>
>> The value is "AUTHENTICATE".
>
> This looks right.
>
>> But i tought that auth diges-md5 and sasl digest-md5 100% compatible.
>> Now if they are then RFC bug, if not then all ok.
>> Syntax diff on same stuff:
>>    RFC 2831. digest-uri = "digest-uri" "=" <"> digest-uri-value <">
>>    RFC 2617  digest-uri           = "uri" "=" digest-uri-value
>
> I never noticed this before. It looks like this was an unintentionally 
> introduced difference.
>
>> In one case "digest-uri", another "uri"
>>
>> Any comments welcome.
>>
>>
>> Ivar Lumi wrote:
>>
>>> Hi,
>>>
>>> What value must be "request-method" in "A2" calculation ?
>>>
>>> IMAP has "AUTHENTICATE", does SMTP have "AUTH" ?
>>>
>>> I can't get outlook 2007 digest response to match my calculated 
>>> value, so there must be some thing i miss.
>>>
>>>
>>> Thanks,
>>
>

Date: Tue, 04 Nov 2008 13:55:25 +0000
From: Alexey Melnikov <[email-masked]>
To: Ivar Lumi <[email-masked]>
CC: [email-masked]
Subject: Re: SMTP AUTH digest-md5
Sender: [email-masked]

Hi,

Ivar Lumi wrote:

> The value is "AUTHENTICATE".

This looks right.

> But i tought that auth diges-md5 and sasl digest-md5 100% compatible.
> Now if they are then RFC bug, if not then all ok.
> Syntax diff on same stuff:
>    RFC 2831. digest-uri = "digest-uri" "=" <"> digest-uri-value <">
>    RFC 2617  digest-uri           = "uri" "=" digest-uri-value

I never noticed this before. It looks like this was an unintentionally 
introduced difference.

> In one case "digest-uri", another "uri"
>
> Any comments welcome.
>
>
> Ivar Lumi wrote:
>
>> Hi,
>>
>> What value must be "request-method" in "A2" calculation ?
>>
>> IMAP has "AUTHENTICATE", does SMTP have "AUTH" ?
>>
>> I can't get outlook 2007 digest response to match my calculated 
>> value, so there must be some thing i miss.
>>
>>
>> Thanks,
>

Date: Tue, 04 Nov 2008 12:20:50 +0200
From: Ivar Lumi <[email-masked]>
To: [email-masked]
Subject: Re: SMTP AUTH digest-md5
Sender: [email-masked]

The value is "AUTHENTICATE".

But i tought that auth diges-md5 and sasl digest-md5 100% compatible.
Now if they are then RFC bug, if not then all ok.
Syntax diff on same stuff:
    RFC 2831. digest-uri = "digest-uri" "=" <"> digest-uri-value <">
    RFC 2617  digest-uri           = "uri" "=" digest-uri-value

In one case "digest-uri", another "uri"

Any comments welcome.

Ivar Lumi wrote:
>
> Hi,
>
> What value must be "request-method" in "A2" calculation ?
>
> IMAP has "AUTHENTICATE", does SMTP have "AUTH" ?
>
> I can't get outlook 2007 digest response to match my calculated value, 
> so there must be some thing i miss.
>
>
> Thanks,
>

Date: Tue, 04 Nov 2008 10:21:55 +0200
From: Ivar Lumi <[email-masked]>
To: [email-masked]
Subject: SMTP AUTH digest-md5
Sender: [email-masked]

Hi,

What value must be "request-method" in "A2" calculation ?

IMAP has "AUTHENTICATE", does SMTP have "AUTH" ?

I can't get outlook 2007 digest response to match my calculated value, 
so there must be some thing i miss.

Thanks,

Date: Mon, 3 Nov 2008 17:12:27 +0000
From: Tony Finch <[email-masked]>
To: Alessandro Vesely <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: Q: English terms for forwarded addresses
Sender: [email-masked]

On Mon, 3 Nov 2008, Alessandro Vesely wrote:
>
> Did you mean that "forwarding" is bound to be a fuzzy (non-technical) term in
> SMTP?

Yes, so it's best to use a different unambiguous term instead, e.g. "alias
address" or "mailing list address".

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
TYNE DOGGER FISHER GERMAN BIGHT: EAST OR NORTHEAST 4 OR 5, OCCASIONALLY 6.
MODERATE. OCCASIONAL RAIN OR DRIZZLE. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Mon, 03 Nov 2008 17:55:13 +0100
From: Alessandro Vesely <[email-masked]>
To: Tony Finch <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: Q: English terms for forwarded addresses
Sender: [email-masked]

Tony Finch wrote:
> On Mon, 3 Nov 2008, Alessandro Vesely wrote:
>>
>> Assume a forwarding recipe directs the MX server of example.com to
>> forward all messages destined to [email-masked] to [email-masked].
>> [...] I often read the term "forwarded address" for [email-masked].
>> Then, what is the correct term for its counterpart [email-masked]?
> 
> I would say [email-masked] is an alias, and [email-masked] is the
> target of the alias. See sections 3.5 and 3.9 of RFC 5321 for examples.

Thanks, "target" is clearly the world I've been looking for :-)

However, I'm puzzled as to whether you meant something by resorting to 
"alias" even when the envelope sender changes... sect. 3.5 says the 
distinction between mailing list and aliases is fuzzy, and sect. 3.9.2 
implies "redistribution" != "forwarding", but also "handling aliases" 
!= "forwarding". In facts, "forwarding" is commonly used for the 
action started by hitting a MUA's forward button, which should result 
in a new message...

Did you mean that "forwarding" is bound to be a fuzzy (non-technical) 
term in SMTP?

Date: Mon, 3 Nov 2008 13:08:09 +0000
From: Tony Finch <[email-masked]>
To: Alessandro Vesely <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: Q: English terms for forwarded addresses
Sender: [email-masked]

On Mon, 3 Nov 2008, Alessandro Vesely wrote:
>
> Assume a forwarding recipe directs the MX server of example.com to
> forward all messages destined to [email-masked] to [email-masked].
> [...] I often read the term "forwarded address" for [email-masked].
> Then, what is the correct term for its counterpart [email-masked]?

I would say [email-masked] is an alias, and [email-masked] is the
target of the alias. See sections 3.5 and 3.9 of RFC 5321 for examples.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
TYNE DOGGER FISHER GERMAN BIGHT HUMBER: EAST OR NORTHEAST 4 OR 5. MODERATE.
OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Mon, 03 Nov 2008 12:09:21 +0100
From: Alessandro Vesely <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Q: English terms for forwarded addresses
Sender: [email-masked]

Hi!

Assume a forwarding recipe directs the MX server of example.com to 
forward all messages destined to [email-masked] to [email-masked]. 
(Strictly speaking, it is not aliasing if the RFC2821.MailFrom is 
being changed, e.g. for SPF compliance, but rather a mailing list, 
although featuring a single fixed subscriber.) I often read the term 
"forwarded address" for [email-masked]. Then, what is the correct 
term for its counterpart [email-masked]?

As I'm not a native English speaker, I'd prefer not to invent new 
terms. However, I haven't been able to spot the correct ones on the 
web. Grateful for any hint

TIA