Subject: Re: mail-followup-to / mail-copies-to
From: "Charles Lindsey" <[email-masked]>
To: [email-masked]
Date: Tue, 31 May 2005 11:19:47 GMT
Newsgroups: local.mime
List-Id: <ietf-822.imc.org>

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

>On Mon, 30 May 2005, Charles Lindsey wrote:

>> In <[email-masked]> Bruce Lilly 
>> <[email-masked]> writes:
>>
>>> As another, not uncommon, example, consider a message posted to a 
>>> mailing list with a request by the author to send off-list (only) 
>>> responses, to be summarized by the author.  The author could 
>>> easily indicate that with Reply-To, and every response that is 
>>> directed "where the author suggested" will comply with that.  For 
>>> such a mailing list message, your "list context" would send a 
>>> doubly wrong response -- it wouldn't go directly to the author (as 
>>> requested) and would go to the entire list (contrary to the 
>>> request).

>Note btw that "list context" isn't my idea, it's simply what a few 
>MUAs in the field already /do/. (Indeed, at least one simply ignores 
>all cues in the mail being replied to for a "list reply", other than 
>MFT).

>The problem isn't so much in 'my' "list context", but in the 
>problematic /deployed/ MUA functionality.

>> That is exactly the sort of situation that MFT is supposed to deal 
>> with. In the absence of MFT, then using the List-Post address is 
>> the right thing when "Replying-to-List". But if MFT is present, it 
>> should override the List-Post. There might even be a 'list' keyword 
>> in the MFT header to mean reply to List-Post (to be used in 
>> addition to the sender's address if he want replies both to the 
>> list and himself).

>I'm not sure about MFT, it seems as vague and broad (and hence as 
>problematic) as Reply-To is.

Which is why there needs to be a standard to declare exactly what it is
supposed to do and not to do.

>It seems to me that supplying information which is as specific and 
>indisputably true as possible is better than supplying vague 
>"suggestions", which may be too broad in their scope to be able to 
>provide . Eg:

>"Suggest that Replies go To <a>, <b>, etc.."

>and

>"Suggest that Follow-ups go To ...."

Sure. But a proper MFT standard would state clearly who the reply was to
go to (subject to user override) in all the possible combinations of
List-Post fields, MFT fields, Reply-To fields, etc that could arise.

-- 
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: Tue, 31 May 2005 09:21:41 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Charles Lindsey <[email-masked]>
cc: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Mon, 30 May 2005, Charles Lindsey wrote:

> >Pine does, via 'roles'. You would set up a role for each list setting 
> >role selector as to be 'Participant' == 'list mailbox', and then in 
> >the 'Actions' set 'Set-Reply-To' to list mailbox.
> 
> Does it really allow you to set the Reply-To field according to the "role"?

Yes. I use it for precisely that purpose, to set Reply-To when I post to 
certain mailing lists. (I haven't bothered to set it up for this list.)

Philip

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

Date: Tue, 31 May 2005 02:49:14 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Charles Lindsey <[email-masked]>
cc: [email-masked]
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, 30 May 2005, Charles Lindsey wrote:

> In <[email-masked]> Bruce Lilly 
> <[email-masked]> writes:
>
>> As another, not uncommon, example, consider a message posted to a 
>> mailing list with a request by the author to send off-list (only) 
>> responses, to be summarized by the author.  The author could 
>> easily indicate that with Reply-To, and every response that is 
>> directed "where the author suggested" will comply with that.  For 
>> such a mailing list message, your "list context" would send a 
>> doubly wrong response -- it wouldn't go directly to the author (as 
>> requested) and would go to the entire list (contrary to the 
>> request).

Note btw that "list context" isn't my idea, it's simply what a few 
MUAs in the field already /do/. (Indeed, at least one simply ignores 
all cues in the mail being replied to for a "list reply", other than 
MFT).

The problem isn't so much in 'my' "list context", but in the 
problematic /deployed/ MUA functionality.

> That is exactly the sort of situation that MFT is supposed to deal 
> with. In the absence of MFT, then using the List-Post address is 
> the right thing when "Replying-to-List". But if MFT is present, it 
> should override the List-Post. There might even be a 'list' keyword 
> in the MFT header to mean reply to List-Post (to be used in 
> addition to the sender's address if he want replies both to the 
> list and himself).

I'm not sure about MFT, it seems as vague and broad (and hence as 
problematic) as Reply-To is.

It seems to me that supplying information which is as specific and 
indisputably true as possible is better than supplying vague 
"suggestions", which may be too broad in their scope to be able to 
provide . Eg:

"Suggest that Replies go To <a>, <b>, etc.."

and

"Suggest that Follow-ups go To ...."

seem fraught with possibilities of ambigious corner cases to me. 
Compared to things like:

"This mail was sent by <b>"

or

"Please consider copying <a>, <b>, ... on replies"

Seem far clearer and with far limited scope for misinterpretation. 
(whether the information/suggestion is acted on is a different matter 
and in the hands of the respondent). It's nice to have a limited set 
of general cues if it all works out nicely, but not if it fails to 
deal with common usage scenarios. :)

For the MFT case, what constitutes a "Followup" exactly? And didn't 
Keith Moore highlight a few problems in the previous thread? (around 
list exploders, i cant remember - i'll have to go reread again).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You know, the difference between this company and the Titanic is that the
Titanic had paying customers.

To: [email-masked]
Xref: clerew local.mime:4744
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Date: Mon, 30 May 2005 11:40:29 GMT
Lines: 38
Sender: [email-masked]

In <[email-masked]> "william(at)elan.net" <[email-masked]> writes:

>On Fri, 27 May 2005, Charles Lindsey wrote:

>> I thought the whole idea of X-headers was that they would NOT be
>> registered, so that people can invent them ad hoc as needed (however, it
>> needs to be understood that they are primarily there for human
>> consumption).

>My understanding about "X-" is that they are for use in local-system
>specific data (for use by other local systems or users) and for local 
>experiments (local can extend to more then one organization) and that 
>if they are for human consumption or machine consumption or both does
>not matter. And when experiment wants to become standard then they
>define full header field without "x".

If you use an X-header in an email sent to someone with whom you have no
prior arrangement, then it can only be for human-readable purposes (but
very useful nevertheless). The only time when an X-header can be
machine-interpreted is within some closed group of users, or when it is
expected that the message may come back to the machine that sent it (as in
a bounce), when it might help in deciding how to process it next.

If you are planning on having your header recognized all over the internet
(perhaps experimentally with a view to a full standard), then you should
publish it somewhere (as an ID perhaps) and that apply for a provisional
registration for it.

-- 
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: Mon, 30 May 2005 19:19:05 +0100 (BST)
To: [email-masked]
Xref: clerew local.mime:4742
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Sender: [email-masked]

<[email-masked]> <[email-masked]>
<[email-masked]>
<[email-masked]> <[email-masked]>
<[email-masked]> <[email-masked]>
<[email-masked]> <[email-masked]>
<[email-masked]> <[email-masked]>
<[email-masked]>
<[email-masked]>
Date: Mon, 30 May 2005 11:23:01 GMT
Lines: 26
MIME-Version: 1.0

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

>On Mon, 27 Sep 2004, Charles Lindsey wrote:

>> Which existing MUAs have the feature to set the Reply-To field
>> "_automatically_" according to the particular list(s) involved?

>Pine does, via 'roles'. You would set up a role for each list setting 
>role selector as to be 'Participant' == 'list mailbox', and then in 
>the 'Actions' set 'Set-Reply-To' to list mailbox.

Does it really allow you to set the Reply-To field according to the "role"?
Certainly, the intention wrt Mail-Followup-To was that users could set
something like those "roles", but in a manner that generated a MFT field
depedong on the "role".

-- 
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: Mon, 30 May 2005 19:19:22 +0100 (BST)
To: [email-masked]
Xref: clerew local.mime:4743
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Sender: [email-masked]

<[email-masked]>
<[email-masked]>
<[email-masked]>
Date: Mon, 30 May 2005 11:33:19 GMT
Lines: 27
MIME-Version: 1.0

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

>As another, not uncommon, example, consider a message posted to a mailing
>list with a request by the author to send off-list (only) responses, to
>be summarized by the author.  The author could easily indicate that with
>Reply-To, and every response that is directed "where the author suggested"
>will comply with that.  For such a mailing list message, your "list context"
>would send a doubly wrong response -- it wouldn't go directly to the author
>(as requested) and would go to the entire list (contrary to the request).

That is exactly the sort of situation that MFT is supposed to deal with.
In the absence of MFT, then using the List-Post address is the right
thing when "Replying-to-List". But if MFT is present, it should override
the List-Post. There might even be a 'list' keyword in the MFT header to
mean reply to List-Post (to be used in addition to the sender's address if
he want replies both to the list and himself).

-- 
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: Mon, 30 May 2005 19:30:38 +0100 (BST)
To: [email-masked]
Xref: clerew local.mime:4745
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Folding of long lines in message bodies
Sender: [email-masked]

<[email-masked]>
Date: Mon, 30 May 2005 11:43:58 GMT
Lines: 27
MIME-Version: 1.0

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

>I believe that you're referring to a content markup language known
>as "format=flowed", which is described in RFC 3676.  There was a
>long discussion on ietf-822 ca. February-August 2003, including
>an attempt to define a syntax for that content markup language
>(though I don't think there was ever a conclusion to that effort).

>The format seems to be used and understood by only a few MUAs; it
>causes quoted material, particularly with copy & paste, to be
>formatted in extremely long lines in other MUAs. 

I believe it is quite widely recognized by MUAs now, judging by my own
experience of using it. And if implemented correctly, it should not result
in extremely long lines when viewed in other MUAs, whether for quoted
material or for original material.

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

Cc: <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: SMTP option for DHCPv6
Date: Sun, 29 May 2005 13:43:17 -0400
To: Cristian Cadar <[email-masked]>
Sender: [email-masked]

IMHO, this is an entirely inappropriate use of DHCP.  Mail submission  
should not be dependent on, or constrained by. network topology.  The  
existing DHCPv4 option should be deprecated or at least discouraged.

Keith

On May 27, 2005, at 5:04 AM, Cristian Cadar wrote:

>
> Dear all,
>
> I was asked by the IETF DHC members to post this question here asking
> for your opinion. I have recently submitted an IETF draft on SMTP  
> option
> for DHCPv6 protocol suite and presented my draft
> http://www.ietf.org/internet-drafts/draft-cadar-dhc-dhcpv6-opt- 
> smtp-00.t
> xt during the last IETF meeting.
> There is already a standardized SMTP option for DHCPv4. My question  
> is:
> Do you know any implementation where SMTP option is used by  
> somebody for
> delegating IPv4 SMTP server addresses to the clients? do you think  
> that
> the SMTP option for DHCPv6 will be used in the future by the email
> clients?
>
> Thank you in advance
>
>
> Regards,
>
> Cristian Cadar
> NEC Europe Ltd.
>
>
>

Date: Sun, 29 May 2005 02:43:34 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, 28 May 2005, Paul Jakma wrote:

>> Unlikely to happen -- it is a legitimate use and may be appropriate in some 
>> contexts.
>
> Perfect.
>
>> Oh, it was supposed to be a footnote?  If you meant restricting use of
>> Reply-To, no, I don;t think it would be appropriate.
>
> Fine, in that case if the meaning of Reply-To can *not* be made 
> more specific, it's not suitable for list usage. In which case some 
> other solution is needed. Eg, 'Foo-Copy-Me'.

Another "solution" would be (as suggested by Bruce in that previous, 
older thread and also hinted at, I think, by Keith Moore) to draft 
something concerning best practice for MUAs on their interaction with 
their users, specifically in how fields such as Reply-To/From, etc.. 
are presented to the user and /base/ reccomendations on how the MUA 
should behave.

(though, I have a sneaking suspicion consensus would be just as hard 
to achieve.. but hey, worth a try).

As far I can tell, the following reccomendations /might/ be 
acceptable:

- that the MUA should allow the From field to be editable
   (this apparently would raise other questions - eg 'anonymous' mail
   ?? Also, not sure if site admins would always like this.)

- that setting From should be the preferred way to indicate author's
   preferred mailbox

- that MUAs should make their user aware of a Reply-To field in a
   mail being responded to and should engage the user in selecting the
   correct addresses to reply to.

A major part of /my/ problem with using Reply-To for directing 
list-replies is that many MUAs will then direct replies (be it 
'reply' or 'reply-all') to the mailbox(es) in the Reply-To field 
automatically *without* involving their user in this decision, with 
great risk that user doesn't even notice the redirection (and hence 
commits an indiscretion by sending a private reply to multiple 
addresses, not just the original author).

If that annoying behaviour were discouraged via an official document 
I could then whine at the implementors of such MUAs, rather than 
having to take up the time of the learned members of this list. :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You knew the job was dangerous when you took it, Fred.
 		-- Superchicken

Date: Sun, 29 May 2005 01:55:16 +0100 (IST)
From: Paul Jakma <[email-masked]>
Reply-To: [email-masked], [email-masked]
To: Charles Lindsey <[email-masked]>
cc: [email-masked]
Subject: Re: Understanding response protocols
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

(sorry for extremely late reply. I'm still catching up on this very 
long thread)

On Mon, 27 Sep 2004, Charles Lindsey wrote:

> Which existing MUAs have the feature to set the Reply-To field
> "_automatically_" according to the particular list(s) involved?

Pine does, via 'roles'. You would set up a role for each list setting 
role selector as to be 'Participant' == 'list mailbox', and then in 
the 'Actions' set 'Set-Reply-To' to list mailbox.

At the moment the most recent version of Pine (4.63) has a bug in 
that it does not allow one to specify multiple mailboxes in the 
'Set-Reply-To', hence it doesn't work for me (I would want to set my 
address + list mailbox - if I wanted to use Reply-To in this way). 
Ironically, I could use this feature to correctly set MFT (Via 
'Set-Custom-Hdr') which lets me enter whatever non-standard headers I 
want.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Sinners can repent, but stupid is forever.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Folding of long lines in message bodies
Date: Sat, 28 May 2005 14:23:42 -0400
Cc: Jacob Palme <[email-masked]>
Sender: [email-masked]

On Sat May 28 2005 13:28, Jacob Palme wrote:
> 
> 
> 
> I remember that there has been discussion some years ago
> about folding of long lines in message bodies. The idea was
> that if there is a space immediately before a line break,
> this space indicates that this is a soft line break and
> should be unfolded on receipt.
> 
> What happended with these ideas? Did they ever become a
> standard, or a de-facto-standard?

I believe that you're referring to a content markup language known
as "format=flowed", which is described in RFC 3676.  There was a
long discussion on ietf-822 ca. February-August 2003, including
an attempt to define a syntax for that content markup language
(though I don't think there was ever a conclusion to that effort).

The format seems to be used and understood by only a few MUAs; it
causes quoted material, particularly with copy & paste, to be
formatted in extremely long lines in other MUAs. 

Also, as it employs (rather complicated, judging by the syntax
discussions) content markup, it seems inconsistent with the
intent of the text/plain media type (RFC 2046 section 3):

   The five discrete top-level media types are:

    (1)   text -- textual information.  The subtype "plain" in
          particular indicates plain text containing no
          formatting commands or directives of any sort. Plain
          text is intended to be displayed "as-is".

and section 4.1:

   Plain text does not provide for or allow
   formatting commands, font attribute specifications, processing
   instructions, interpretation directives, or content markup.

From: [email-masked]
Cc: IETF mailing list on MIME and e-mail <[email-masked]>
Date: Sat, 28 May 2005 10:45:45 -0700 (PDT)
Subject: Re: Folding of long lines in message bodies
To: Jacob Palme <[email-masked]>
Sender: [email-masked]

> I remember that there has been discussion some years ago
> about folding of long lines in message bodies. The idea was
> that if there is a space immediately before a line break,
> this space indicates that this is a soft line break and
> should be unfolded on receipt.

> What happended with these ideas? Did they ever become a
> standard, or a de-facto-standard?

RFC 3676.

				Ned

Date: Sat, 28 May 2005 18:40:47 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, 28 May 2005, Bruce Lilly wrote:

> You claimed that it was perceived to be a problem based on a 
> misinterpretation of the meaning of Reply-To as "private".  The 
> problem is with that misinterpretation (apparently yours).

No, I'm just trying to point out some of the real-world ambiguity 
around use of Reply-To. The example in 2822 shows the problem, so 
please stop claiming there is no problem.

> Unlikely to happen -- it is a legitimate use and may be appropriate 
> in some contexts.

Perfect.

> Oh, it was supposed to be a footnote?  If you meant restricting use of
> Reply-To, no, I don;t think it would be appropriate.

Fine, in that case if the meaning of Reply-To can *not* be made more 
specific, it's not suitable for list usage. In which case some other 
solution is needed. Eg, 'Foo-Copy-Me'.

("There shouldn't be a way to indicate desire to be copied on list 
replies" is an /answer/ but not a solution).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Never argue with a man who buys ink by the barrel.

Date: Sat, 28 May 2005 19:28:57 +0200
To: IETF mailing list on MIME and e-mail <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Folding of long lines in message bodies
Sender: [email-masked]

I remember that there has been discussion some years ago
about folding of long lines in message bodies. The idea was
that if there is a space immediately before a line break,
this space indicates that this is a soft line break and
should be unfolded on receipt.

What happended with these ideas? Did they ever become a
standard, or a de-facto-standard?

(This message is in that format, since Eudora, which I
am using, automatically produces this format when you
use the "Wrap Selection" command.)
-- 
Professor Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Date: Sat, 28 May 2005 13:31:39 -0400
Cc: Paul Jakma <[email-masked]>
Sender: [email-masked]

On Sat May 28 2005 11:54, Paul Jakma wrote:
> 
> On Sat, 28 May 2005, Bruce Lilly wrote:

> >> Lots of MUAs will reply to both [email-masked] and
> >> [email-masked] for 'reply'.
> >
> > That's what the author suggested for responses.  Why do you say
> > "things go wrong"?
> 
> Sorry, but you seem too knowledgeable to not be aware of the 
> potential problems of using Reply-To in public mails. Do I have to 
> spell it out? (I thought I already mentioned the Reply-To risk).

You claimed that it was perceived to be a problem based on a misinterpretation
of the meaning of Reply-To as "private".  The problem is with that
misinterpretation (apparently yours).
 
> If use of Reply-To as a way to indicate ones own mailbox were 
> deprecated, and instead it were mandated that From should always be 
> the author's mailbox, then Reply-To would be more suitable for the 
> purpose I need.

Unlikely to happen -- it is a legitimate use and may be appropriate
in some contexts.
 
> >> Would it be an idea to act on this suggestion?
> >>
> >> 1. Specifically, more implementations supporting MFT.
> >
> > Nobody has yet produced a coherent suggestion along those lines that
> > gained any sort of consensus.  Keith Moore identified a number of serious
> > problems with MFT.  So it's highly unlikely.
> 
> Could you answer the question rather than my footnote? :)

Oh, it was supposed to be a footnote?  If you meant restricting use of
Reply-To, no, I don;t think it would be appropriate.

Date: Sat, 28 May 2005 16:54:34 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, 28 May 2005, Bruce Lilly wrote:

>> Clearly this example shows how 'Reply-To' can be used to suggest 
>> that author prefers replies to go to their [email-masked] 
>> mailbox rather than their [email-masked] mailbox.
>
> Perfectly legal. When there are multiple ways to do the same thing,
> and there are no reasons to prefer one over the others...

Agreed.

>> Where things go wrong is when MUAs try to respond to the following:
>>
>> ---------------------------------------------------------------------
>> From: Mary Smith <[email-masked]>
>> To: John Doe <[email-masked]>
>> Cc: Example list <[email-masked]>
>> Reply-To: "Mary Smith: Personal Account" <[email-masked]>,
>>  	Example list <[email-masked]>
>> Subject: Re: Saying Hello
>> Date: Fri, 21 Nov 1997 10:01:10 -0600
>> Message-ID: <[email-masked]>
>> In-Reply-To: <[email-masked]>
>> References: <[email-masked]>
>>
>> This is a mail to you and the list
>> ----------------------------------------------------------------------
>>
>> Lots of MUAs will reply to both [email-masked] and
>> [email-masked] for 'reply'.
>
> That's what the author suggested for responses.  Why do you say
> "things go wrong"?

Sorry, but you seem too knowledgeable to not be aware of the 
potential problems of using Reply-To in public mails. Do I have to 
spell it out? (I thought I already mentioned the Reply-To risk).

> Yes, for each individual author who has a mailbox, and who does not 
> require anonymity.  There is of course nothing in the current 
> specification to prevent that.

If use of Reply-To as a way to indicate ones own mailbox were 
deprecated, and instead it were mandated that From should always be 
the author's mailbox, then Reply-To would be more suitable for the 
purpose I need.

Anonymity is another matter I guess.

>> Would it be an idea to act on this suggestion?
>>
>> 1. Specifically, more implementations supporting MFT.
>
> Nobody has yet produced a coherent suggestion along those lines that
> gained any sort of consensus.  Keith Moore identified a number of serious
> problems with MFT.  So it's highly unlikely.

Could you answer the question rather than my footnote? :)

I have at no time advocated the MFT header, it's presence in my mails 
should not be construed as advocacy of it, nor would I advocate it 
standardisation. :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
If happiness is in your destiny, you need not be in a hurry.
 		-- Chinese proverb

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Date: Sat, 28 May 2005 06:44:32 -0400
Cc: Paul Jakma <[email-masked]>
Sender: [email-masked]

On Sat May 28 2005 00:07, Paul Jakma wrote:

> It's not clear enough though. Eg, lets just quote from the example 
> 2822 gives:

Last time I counted, there were about a dozen examples in 2822. Anyway: 
> ---------------------------------------------------------------------
> From: Mary Smith <[email-masked]>
> To: John Doe <[email-masked]>
> Reply-To: "Mary Smith: Personal Account" <[email-masked]>
> Subject: Re: Saying Hello
> Date: Fri, 21 Nov 1997 10:01:10 -0600
> Message-ID: <[email-masked]>
> In-Reply-To: <[email-masked]>
> References: <[email-masked]>
> 
> This is a reply to your hello.
> ----
> 
>     Note the "Reply-To:" field in the above message.  When John 
> replies
>     to Mary's message above, the reply should go to the address in the
>     "Reply-To:" field instead of the address in the "From:" field.
> ---------------------------------------------------------------------
> 
> Clearly this example shows how 'Reply-To' can be used to suggest that 
> author prefers replies to go to their [email-masked] mailbox 
> rather than their [email-masked] mailbox.

Perfectly legal. When there are multiple ways to do the same thing,
and there are no reasons to prefer one over the others...

> Where things go wrong is when MUAs try to respond to the following:
> 
> ---------------------------------------------------------------------
> From: Mary Smith <[email-masked]>
> To: John Doe <[email-masked]>
> Cc: Example list <[email-masked]>
> Reply-To: "Mary Smith: Personal Account" <[email-masked]>,
>  	Example list <[email-masked]>
> Subject: Re: Saying Hello
> Date: Fri, 21 Nov 1997 10:01:10 -0600
> Message-ID: <[email-masked]>
> In-Reply-To: <[email-masked]>
> References: <[email-masked]>
> 
> This is a mail to you and the list
> ----------------------------------------------------------------------
> 
> Lots of MUAs will reply to both [email-masked] and 
> [email-masked] for 'reply'.

That's what the author suggested for responses.  Why do you say
"things go wrong"?
 
> IIRC a suggestion was floated in that last discussion you pointed me 
> at, from circa august last year, that the From field should always be 
> set to the author's preferred mailbox for replies to the author.

Yes, for each individual author who has a mailbox, and who does not
require anonymity.  There is of course nothing in the current specification
to prevent that.

> Would it be an idea to act on this suggestion?
> 
> 1. Specifically, more implementations supporting MFT.

Nobody has yet produced a coherent suggestion along those lines that
gained any sort of consensus.  Keith Moore identified a number of serious
problems with MFT.  So it's highly unlikely.

Date: Sat, 28 May 2005 05:07:17 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, 27 May 2005, Bruce Lilly wrote:

> On Fri May 27 2005 21:49, Paul Jakma wrote:
>
>> It absolutely is not fine to set Reply-To == list mailbox because of
>> the *definite* risk of MUAs sending 'private' mails to the Reply-To.

> You are confused. Reply-To has semantics of "suggestion for responses",
> not "private".

Well, rather several MUAs are confused on this point. (Mine isn't - 
it asks me whether I want to follow the 'suggestion' of a Reply-To).

> RFCs 724, 733, and 822 had some confusing statements.  RFC 2822 is 
> much more clear, and was approved with community review and 
> consensus more than four years ago.  So this has already happened.

Hmm, 2822 is clearer yes.

It's not clear enough though. Eg, lets just quote from the example 
2822 gives:

---------------------------------------------------------------------
From: Mary Smith <[email-masked]>
To: John Doe <[email-masked]>
Reply-To: "Mary Smith: Personal Account" <[email-masked]>
Subject: Re: Saying Hello
Date: Fri, 21 Nov 1997 10:01:10 -0600
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
References: <[email-masked]>

This is a reply to your hello.
----

    Note the "Reply-To:" field in the above message.  When John 
replies
    to Mary's message above, the reply should go to the address in the
    "Reply-To:" field instead of the address in the "From:" field.
---------------------------------------------------------------------

Clearly this example shows how 'Reply-To' can be used to suggest that 
author prefers replies to go to their [email-masked] mailbox 
rather than their [email-masked] mailbox.

Where things go wrong is when MUAs try to respond to the following:

---------------------------------------------------------------------
From: Mary Smith <[email-masked]>
To: John Doe <[email-masked]>
Cc: Example list <[email-masked]>
Reply-To: "Mary Smith: Personal Account" <[email-masked]>,
 	Example list <[email-masked]>
Subject: Re: Saying Hello
Date: Fri, 21 Nov 1997 10:01:10 -0600
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
References: <[email-masked]>

This is a mail to you and the list
----------------------------------------------------------------------

Lots of MUAs will reply to both [email-masked] and 
[email-masked] for 'reply'.

We can try deny the existence of this problem, but then I suspect 
we'll just have:

- the same dead-locked discussion on this list every now and again
   about the problem

Which will lead to:

- More and more ad-hoc solutions to the problem[1], because of
   dead-lock in trying to have either the cause of the problem
   clarified, or any new solution accepted at an IETF level (ie this
   list :) ).

IIRC a suggestion was floated in that last discussion you pointed me 
at, from circa august last year, that the From field should always be 
set to the author's preferred mailbox for replies to the author. Such 
a suggestion would allow Reply-To to be useful and (eventually, after 
a long amount of time no doubt) allow me to use it.

Would it be an idea to act on this suggestion?

1. Specifically, more implementations supporting MFT.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Sho' they got to have it against the law.  Shoot, ever'body git high,
they wouldn't be nobody git up and feed the chickens.  Hee-hee.
 		-- Terry Southern

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Date: Fri, 27 May 2005 23:29:38 -0400
Cc: Paul Jakma <[email-masked]>
Sender: [email-masked]

On Fri May 27 2005 21:49, Paul Jakma wrote:

> It absolutely is not fine to set Reply-To == list mailbox because of 
> the *definite* risk of MUAs sending 'private' mails to the Reply-To. 

You are confused. Reply-To has semantics of "suggestion for responses",
not "private".

> If Reply-To is supposed to the answer, then at a minimum there should 
> be a sanctioned clarification of how implementations should deal with 
> it.

RFCs 724, 733, and 822 had some confusing statements.  RFC 2822 is much
more clear, and was approved with community review and consensus more
than four years ago.  So this has already happened.

Date: Sat, 28 May 2005 03:58:27 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, 28 May 2005, Paul Jakma wrote:

> Reply-To. (I've seen it happen countless few times both on lists 
> which munged Reply-To and with someone who set it themselves.).

The first line should read "countless times". (I started with "a few 
times", then as i started thinking of instances, I realised I have 
seen it happen on many occasions :) ).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Why aren't fishmongers generous? Their business makes them selfish.
%

Date: Sat, 28 May 2005 02:49:08 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, 27 May 2005, Bruce Lilly wrote:

> Kmail and Evolution provide options for directing responses "To 
> List", in addition to other places (e.g. "To Sender", "To Author"), 
> not a "context".

It's "the context in which the user wishes to reply". Tortured 
terminology maybe.

> I don't know -- maybe quirky developers (ones who like medium gray
> text on a dark gray background).

Damn their souls. :)

Next question: Why do quite a few MUAs provide a "list reply" 
function?

>> Because the most likely reason for it being set are:
>>
>> - The author's preferred 'receive' mailbox is not their From
>>    (ie to indicate preference for their personal mailbox)
>
> Makes no sense -- for replies "to author" the From field mailbox can
> (and should) be set accordingly.

Ok.

> Umm, look at this message for example (and note past messages as 
> well). That specific case (along with a couple of others) is 
> specifically mentioned in RFC 724, which has been around for close 
> to three decades, and its successors.

I've only ever once seen anyone set "Reply-To: <list>", and they 
eventually got burned by the risk mentioned below. I've never seen 
anyone set Reply-To to both their own mailbox and the list mailbox 
(until you replied to me, and I tried it with one or two of my 
mails).

> No, it's a problem with your proposal; Reply-To: 
> [email-masked] works fine to specify responses to the 
> (including) list (possibly in addition to other mailboxes).  That 
> removes any ambiguity about which list responses are supposed to be 
> sent to.

No it doesn't work fine.

It absolutely is not fine to set Reply-To == list mailbox because of 
the *definite* risk of MUAs sending 'private' mails to the Reply-To. 
(I've seen it happen countless few times both on lists which munged 
Reply-To and with someone who set it themselves.).

If Reply-To is supposed to the answer, then at a minimum there should 
be a sanctioned clarification of how implementations should deal with 
it.

However, even if such a clarification document were released, you 
still *wont* see much uptake in use of Reply-To to solve the problem 
I (and a minority like me) have because it wont alleviate the risk 
until /all/ implementations behave better.

Are you saying that the problems around use of Reply-To and lists 
with deployed bad implementations we apparently are not to consider? 
"Reply-To /should/ be the answer, therefore it is the answer - real 
world be damned"?

A new header, with restricted and unambigious scope, to solve only a 
very specific problem around replying to list emails (something 
common enough that MUA implementors feel is worthwhile enough to add 
an extra button to their UI for - even Apple, who dont like UI 
clutter) is out of the question, because a header which is widely 
misinterpreted /should/ work, if only everyone fixed their software? 
:)

Or have I missed some key point in the discussion?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You!  What PLANET is this!
 		-- McCoy, "The City on the Edge of Forever", stardate 3134.0

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Original-* (was: I-D ACTION:draft-shafranovich-feedback-report-01.txt)
Date:  Sat, 28 May 2005 03:39:17 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 25
Sender: [email-masked]

william(at)elan.net wrote:

> My view of it all is that Original-* header fields should
> really be defined as trace fields - that is really how they
> are used right now if the data is meant to go outside the
> system

I'm sure that Bruce and / or Keith have something to say about
your idea, but "it doesn't fly with 3864" would be a very weak
argument.  You could register one Original-xxx representative
found in another RfC (updated by your I-D) and then simply try
to register the complete "class" Original-:

RfC 2822 grabs VCHAR minus colon, so Original-: can never be a
header field name of its own.  IIRC you had something about not
adding Original- to any Original-xxx, therefore you could also
try to register the "class" Original-

Some flame wars later, if the IESG approves your idea, then I
doubt that IANA could or would veto it.  It's a hack, but the
registry shouldn't be abused aa a tool to throttle innovation.
If this innovation has merit.  If Graham doesn't shoot you :-)

                       Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Date: Fri, 27 May 2005 20:30:26 -0400
Cc: Paul Jakma <[email-masked]>
Sender: [email-masked]

On Fri May 27 2005 18:34, Paul Jakma wrote:

> There seems to be broad consensus among MUA designers on the first 
> two of these contexts (personal and public), and a slow consensus 
> evolving on providing a "list reply" context for users.
> 
> There is clearly a /perceived/ need for such a context, at least.
> 
> >> The fact that already several MUAs (popular ones at that,
> >> thunderbird, apple mail, and mutt) /do/ do see fit to provide a "list
> >> context"
> >
> > I see nothing resembling that in Thunderbird.
> 
> Hmm, I must be confused then. Sorry. (It appears to be an extension). 
> Kmail and Evolution MUAs definitely have it.

Kmail and Evolution provide options for directing responses "To List",
in addition to other places (e.g. "To Sender", "To Author"), not a
"context".

> Why does it provide this quirk?

I don't know -- maybe quirky developers (ones who like medium gray
text on a dark gray background).

> >> Hence, Reply-To can /not/ be used.
> >
> > You're going to have to justify that claim.
> 
> Because the most likely reason for it being set are:
> 
> - The author's preferred 'receive' mailbox is not their From
>    (ie to indicate preference for their personal mailbox)

Makes no sense -- for replies "to author" the From field mailbox can
(and should) be set accordingly.
 
> - The author set it to direct replies to the list
> 
> The latter case is, ime, rare.

Umm, look at this message for example (and note past messages as well).
That specific case (along with a couple of others) is specifically
mentioned in RFC 724, which has been around for close to three decades,
and its successors. 
 
> > 2. Sometimes one list's expansion feeds another list, and one may
> >   then have multiple sets of List-fields; one cannot in general tell
> >   which list is included in another.  Sending to all directly will
> >   result in duplicates in the included list.  Picking only the included
> >   list (by guessing) won't copy the subscribers of the other list who
> >   are not also subscribed to the included list.
> 
> That seems a problem with the definition of List-Post, and would 
> affect any usage of List-Post, not just this proposed usage. Out of 
> scope for what I'm proposing.

No, it's a problem with your proposal; Reply-To: [email-masked]
works fine to specify responses to the (including) list (possibly in
addition to other mailboxes).  That removes any ambiguity about which
list responses are supposed to be sent to.

Date: Fri, 27 May 2005 23:34:02 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, 27 May 2005, Bruce Lilly wrote:

> On Thu May 26 2005 19:27, Paul Jakma wrote:
>
>> I think by looking at what MUAs do, one could define that context.
>
> Depending on what you look at, you may get a different impression
> (a corollary to "if the only tool that you have is a hammer, everything
> looks like a nail").

There seems to be broad consensus among MUA designers on the first 
two of these contexts (personal and public), and a slow consensus 
evolving on providing a "list reply" context for users.

There is clearly a /perceived/ need for such a context, at least.

>> The fact that already several MUAs (popular ones at that,
>> thunderbird, apple mail, and mutt) /do/ do see fit to provide a "list
>> context"
>
> I see nothing resembling that in Thunderbird.

Hmm, I must be confused then. Sorry. (It appears to be an extension). 
Kmail and Evolution MUAs definitely have it.

>> And it /does/ for mutt.
>
> Only if everybody uses that specific UA with its non-standard quirks.
> Not very realistic.

Why does it provide this quirk?

To be honest, while I'm not happy with the quirk, at least it gives a 
way to influence at least /that/ MUA. I'd just like a standard way to 
specify this preference of mine, so that there may one day be broader 
support for indicating a "copy me on list replies" preference.

>> "list context reply" should /not/ consider Reply-To, for if it did,
>> that would imply it should also consider "From", which obviously isnt
>> the idea.
>
> I don't see how you're making the leap to that conclusion; From and 
> Reply-To fields have very different semantics -- they are not 
> directly linked.

Fair enough.

>> However, see above, I do not (at the moment) think it would be right
>> to consider From/Reply-To in a "list reply" context.
>
> I see that you said so, but you offered no rationale.

Because MUAs which provide a "list reply" context do not wish to 
reply to the author directly, per default. That's the entire raison 
d'etre for this new list-reply context appearing in MUAs - because 
people in general appear to prefer to not receive direct copies.

We can get hung up on arguing how there isn't a scientific basis for 
this claim, but there is plenty of anecdotal evidence, from my 
personal experience and obviously the MUA maintainers perceive it is 
so, or they wouldn't feel a need to implement such a context.

>> Hence, Reply-To can /not/ be used.
>
> You're going to have to justify that claim.

Because the most likely reason for it being set are:

- The author's preferred 'receive' mailbox is not their From
   (ie to indicate preference for their personal mailbox)

- The author set it to direct replies to the list

The latter case is, ime, rare.

> As long as standard mechanisms are used, and implementations comply 
> with those standard mechanisms, it doesn't matter which 
> standards-conforming implementation is used.

Grand.

There is no way to achieve what is wanted though - A way to indicate 
"My preference is to be copied on list replies". List netiquette has 
evolved where people actively strip out all but list mailbox on 
replies, and further several popular MUAs offer "list reply" context 
to make even that step unnecessary.

That's all within standards. Fine.

The only thing which is missing in this changed list culture is a 
good way to indicate "I /do/ want copies of list replies".

> No, you're conflating separate things; use of Reply-To means "where 
> the author suggested" whereas use of From means "directly to the 
> author(s)".

Ok.

I don't see how that affects list context reply which, in /all/ MUAs 
implementing it, exists precisely to *not* use either of these cues.

>> - list
>>  	To: List-Post
>
> Several problems:

> 1. RFC 2369 fields are not mandatory; many lists do not use them

That's fine. "List-Post" here is meant more symbolically, as value of 
mailbox of list, derived either by explicit user configuration or 
implicitely in some fashion (eg the header by same name, if present).

> 2. Sometimes one list's expansion feeds another list, and one may
>   then have multiple sets of List-fields; one cannot in general tell
>   which list is included in another.  Sending to all directly will
>   result in duplicates in the included list.  Picking only the included
>   list (by guessing) won't copy the subscribers of the other list who
>   are not also subscribed to the included list.

That seems a problem with the definition of List-Post, and would 
affect any usage of List-Post, not just this proposed usage. Out of 
scope for what I'm proposing.

> The more serious problem is that mail doesn't have any notion of 
> "context" (other than the optional RFC 3458 field, which is 
> unrelated to your concept); it has only "recipients".  Your list of 
> proposed "contexts" ignores the type of real considerations that 
> apply to selecting recipients:
>
> o the author(s)
> o the sender
> o the reverse (delivery notification) path
> o where the author suggested
> o other recipients of the original, as indicated by the author(s) [N.B.
>  there is no guarantee that they in fact were recipients]

Fair point.

However, this conflates the information available to and suggested 
behaviour of the MUA in acting on this information, with the context 
the MUA user is presented with (which initiates the previous 
behaviour) and has chosen. The latter, the contexts the user may 
choose from, is almost uniform across MUAs, other than "list reply" 
which is restricted to a smaller subset of MUAs (though, very popular 
MUAs).

Clearly though, I need to be more careful in seperating the context 
the user initiated and the various contexts the MUA may find itself 
in. (whether carries out due to one of the few 'user contexts' or 
not).

> For example, sending a "vacation"-like response is independent of 
> any of the items you listed as "context"; such responses need to go 
> to the delivery notification path (see RFC 3834).

That wouldn't fall within the contexts I outlined.

I hadn't considered that.

> As another, not uncommon, example, consider a message posted to a 
> mailing list with a request by the author to send off-list (only) 
> responses, to be summarized by the author.  The author could easily 
> indicate that with Reply-To, and every response that is directed 
> "where the author suggested" will comply with that.  For such a 
> mailing list message, your "list context" would send a doubly wrong 
> response -- it wouldn't go directly to the author (as requested) 
> and would go to the entire list (contrary to the request).

That would be the fault of the MUA /user though, for choosing "list 
reply" context in replying, rather than "reply" context.

The MUA is but the humble servant of the user, and shouldn't be 
blamed if its user directs it wrongly.

It's no more different than the user replying using "Reply All" 
rather than "Reply" - what exactly is the MUA to do other than act on 
its user's wishes?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Some people have a way about them that seems to say: "If I have
only one life to live, let me live it as a jerk."

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SMTP option for DHCPv6
Date:  Fri, 27 May 2005 13:08:32 -0500
Lines: 11
Cancel-Lock: sha1:+Ncs9/Ph+ttuangWE/7N5AZ5mBs=
Sender: [email-masked]

In <[email-masked]> "Eric A. Hall" <[email-masked]> writes:
>
> Along the same lines, mail sessions are keyed to user identity, and user
> identity is independent of the current network topology, while DHCP is
> focused on topology identity.

With the increasing use of port 25 blocking (or worse), the MSA that
you can use is increasingly dependent on the current network topology.

-wayne

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SMTP option for DHCPv6
Date:  Fri, 27 May 2005 12:58:44 -0500
Lines: 38
Cancel-Lock: sha1:E0gJuoSBc6Qr09RI8sAh7M9fH9Q=
Sender: [email-masked]

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

> Cristian Cadar writes:
>
>> do you think that the SMTP option for DHCPv6 will be used in the
>> future by the email clients?
>
> Unlikely. It (and the IPv4 option) is incompatible with SPF, and my
> bet is that SPF will prove stronger. (Oversimplifying, SPF is a hacky
> way to say "only these IP addresses may send mail from this domain".)

I do not think that SPF is necessarily incompatible with DHCP, but the
use of SPF does place restrictions on which domains you can use with
which MTAs/MSAs.

Configuring DHCP would require knowing which domains the DHCP clients
would most likely use, and the DHCP clients would have to know if they
are using atypical domains.

> To see why it's incompatible, suppose you take your laptop along to
> the IETF in Paris in two months, and that your company uses SPF at
> that time. At the IETF, the DHCP server will give you an IP
> address. Perhaps it also gives you an SMTP server. If your laptop that
> server, then anyone who checks SPF will see that the IETF conference's
> SMTP server is not allowed to send mail on behalf of netlab.nec.de.

Right.  In cases of roaming users such as above, it doesn't really
make much sense to supply an SMTP server via DHCP, and it doesn't make
much sense for DHCP clients to pay attention to the suggested SMTP
server.

However, if you are in a corporate environment, it may make a lot of
sense to make sure that all email being sent out of the business is
using approved domain names via approved MTAs.

-wayne

Date: Fri, 27 May 2005 09:51:54 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: Charles Lindsey <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Sender: [email-masked]

On Fri, 27 May 2005, Charles Lindsey wrote:
>
> In <[email-masked]> "william(at)elan.net" <[email-masked]> writes:
>
>> On Wed, 25 May 2005, Yakov Shafranovich wrote:
>
>>> Any particular reason why these fields were not included in the initial
>>> header registry? Sounds rather strange to me.
>
>> 3. If you don't want to register several dozen fields one-by-one then
>>    it'd have to be proposal to modify header field registration system
>>    and create special new subtype of header registry for "Prefix-x"
>>    (which I'd still like to do but can't quite get to it).

Ok I should have made clear that "x" does not mean in traditional smtp
sense "x-" header field. I meant that I'd like to be able to register
entire set of "Prefix-headerfieldname" fields all together without 
specifying each and instead make it based on that headerfieldname
would  already be registered and "prefix" changes its use in some 
pre-determined way.

> I thought the whole idea of X-headers was that they would NOT be
> registered, so that people can invent them ad hoc as needed (however, it
> needs to be understood that they are primarily there for human
> consumption).

My understanding about "X-" is that they are for use in local-system
specific data (for use by other local systems or users) and for local 
experiments (local can extend to more then one organization) and that 
if they are for human consumption or machine consumption or both does
not matter. And when experiment wants to become standard then they
define full header field without "x".

> So all the Original-* headers should really be X-Original-* headers.

Only if the data is meant entirely for use by local system and they
are not meant for reading by some human on remote network when looking
at email message info and what happened to it.

My view of it all is that Original-* header fields should really be 
defined as trace fields - that is really how they are used right now
if the data is meant to go outside the system (i.e. when using "X-"
may not be appropriate). They are also used at least in one instance
as non-header fields like what Yakov proposed (and that is why I said
to him on different list that perhaps Original- name should not be
used by feedback-report so as not to create confusion).

-- 
William Leibzon
Elan Networks
[email-masked]

To: [email-masked]
Xref: clerew local.mime:4711
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Date: Fri, 27 May 2005 13:04:43 GMT
Lines: 63
Sender: [email-masked]

In <[email-masked]> "Adam M. Costello" <[email-masked]> writes:

>There are several things that would be useful to be able to express.
>Here are the ones that spring to my mind right now:

>  * What sorts of replies are allowed/encouraged:
>    - Prefer private reply.
>    - Prefer public reply.
>    - Public reply is the only option (From address is bogus).
>    - No preference.

>    (Mailing lists may want to supply a preference if the author did
>    not supply one, but they generally should not clobber the author's
>    preference if one was supplied.)

>  * Where private replies should go:
>    - The From address vs. some other address(es).

>  * Where public replies should go:
>    - To the To/Cc addresses, or to some other addresses?  (For example,
>      replies to an announcement list might be directed to a discussion
>      list.)
>    - Should the private-reply address be excluded to avoid duplication
>      (because the public-reply addresses already cover it), or included
>      (because the public-reply addresses don't already cover it)?

I think we established last time round that the MFT header could cope with
all those requirements, provided the standard was clear as to how it was
to be used, and who should be able to write (or not overwrite) it.

Main problems with MFT are

1. It presumes that MUAs will have at least three buttons corresponding to
reply (to author), Reply-to-All, and Reply-to-List/Followup/whatever. You
can't mandate in a standard that all MUAs should provide all three, but
you can indicate that the standard assumes them (and then specifies who
the mail should be sent back to - modulo user overrides - in the various
cases). There also needs to be a fallback interpretation for MUAs that
only provide the first two (as is commonly the case at the present time).

2. It really needs a sympathetic MUA which can be configured by the
original author to set the MFT header as he desires. I gather that MUAs
written by DJB do this nicely, but sadly there exist MUAs not written by
DJB :-( .

3. It needs to be defined how it interacts with the various List-*
headers. Sadly, many mailing lists still do not use those headers.

4. It really needs to cope with News as well, in place of the
Mail-Copies-To header that does not quite do the right thing for mail (and
which the Usefor WG has decided not to standardize at present, partly
because a solution that works for both Lists and News would be better).

-- 
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:4712
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Date: Fri, 27 May 2005 13:07:34 GMT
Lines: 29
Sender: [email-masked]

In <[email-masked]> "william(at)elan.net" <[email-masked]> writes:

>On Wed, 25 May 2005, Yakov Shafranovich wrote:

>> Any particular reason why these fields were not included in the initial 
>> header registry? Sounds rather strange to me.

>3. If you don't want to register several dozen fields one-by-one then
>    it'd have to be proposal to modify header field registration system
>    and create special new subtype of header registry for "Prefix-x"
>    (which I'd still like to do but can't quite get to it).

I thought the whole idea of X-headers was that they would NOT be
registered, so that people can invent them ad hoc as needed (however, it
needs to be understood that they are primarily there for human
consumption).

So all the Original-* headers should really be X-Original-* headers.

-- 
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, 27 May 2005 18:03:16 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SMTP option for DHCPv6
Cc: "Eric A. Hall" <[email-masked]>, Cristian Cadar <[email-masked]>, "william(at)elan.net" <[email-masked]>
Sender: [email-masked]

william(at)elan.net writes:
> SMTP option for DHCP may not be entirely useful but SUBMIT option for 
> DHCP sure sounds to me like something quite useful and 
> network-topology dependent in many instances.

How would a MUA know whether to use it or not?

If I'm a consultant, then the MUA should use the SUBMIT option when I'm 
in my own office, but not when I'm at a client site, right? Otherwise I 
risk getting the SPF/whatever problems I described this morning.

Arnt

Date: Fri, 27 May 2005 11:59:01 -0400
From: "Eric A. Hall" <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Cristian Cadar <[email-masked]>, [email-masked]
Subject: Re: SMTP option for DHCPv6
Sender: [email-masked]

On 5/27/2005 11:47 AM, Ned Freed wrote:

> I will also note that it is essential that the option provide a means of
> specifying the port to connect to in addition to the server name, and it might
> be best if the default port was the SMTP-submit port 587 rather than port 25.
> (I haven't looked at the IPv4 version of the option so I don't know if it
> provides this capability or what the default is.)

It doesn't. Just a static unordered array of addresses.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Fri, 27 May 2005 11:57:30 -0400
From: "Eric A. Hall" <[email-masked]>
To: "william(at)elan.net" <[email-masked]>
Cc: Cristian Cadar <[email-masked]>, [email-masked]
Subject: Re: SMTP option for DHCPv6
Sender: [email-masked]

On 5/27/2005 11:47 AM, william(at)elan.net wrote:

> So perhaps we should not bother defining SMTP option for DHCPv6 at all
> and just go ahead and do it under proper name.

> Same for DHCPv4 if SMTP option is not much used, it should possibly be 
> depreciated and replaced by SUBMIT.

Well that's fine, and probably appropriate.

But renaming it won't fix any of the problems that I described earlier,
and it certainly won't change the short answer either. I mean, clients
still aren't likely to use it directly (and still won't be able to do so
if the port is locked and bound).

And I hesitate to mention this, but at some point somebody needs to look
at beefing up the algorithm so that it is more than a simple array of
unordered addresses. There should be preference-flagging capabilities,
fall-back ordering, and other such mechanisms which are standardized so
that clients implement them consistently (lack of consistency in
processing means Client-A will come up with a different answer than
Client-B, with the operator having no control). I wouldn't worry about
that with this, but its something that needs to be done if there is going
to be significant effort at reinvigorating this technology.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: [email-masked]
Cc: Cristian Cadar <[email-masked]>, [email-masked]
Date: Fri, 27 May 2005 08:47:38 -0700 (PDT)
Subject: Re: SMTP option for DHCPv6
To: Eric A Hall <[email-masked]>
Sender: [email-masked]

> On 5/27/2005 5:04 AM, Cristian Cadar wrote:

> > There is already a standardized SMTP option for DHCPv4. My question is:
> > Do you know any implementation where SMTP option is used by somebody for
> > delegating IPv4 SMTP server addresses to the clients? do you think that
> > the SMTP option for DHCPv6 will be used in the future by the email
> > clients?

> The short answer is no.

Agreed.

> The long answer consists of multiple parts. For one thing, most of the
> client DHCP stacks are not integrated with application software very well.
> About the best you can expect (and this isn't very good) is for the DHCP
> client to overwrite config data for an application (like updating a
> mail.conf file that it has been told about). Very few applications
> actually make DHCP calls themselves, and in some cases this isn't even
> possible because the DHCP client has bound to the ports and is preventing
> the applications from making their own requests.

> Another point of difficulty here is that DHCP is mostly geared towards
> "host configuration" and not to "user-specific configuration". This has
> some security implications in application layer software--you may not want
> anonymous guest users using your mail server, or your mail server may
> require authentication (which won't work with guests), etc.

Indeed. In the past these sorts of options that silently change configuration
based on remote data have been the source of a lot of user problems and support
headaches. I imagine that even if this option were generally useful - which it
isn't - sites will be reluctant to use it for this reason.

> Along the same lines, mail sessions are keyed to user identity, and user
> identity is independent of the current network topology, while DHCP is
> focused on topology identity.

Additionally, nothing says that a user will have a single email identity. Lots
of users - including many fairly unsophisticated ones - have multiple email
accounts, each one requiring the use of a different server.

> Having said all of that, defining the option could still be useful and the
> work should be done. But I wouldn't expect it to be used except in the
> minor subset of instances where the above factors coincide with actual
> installation considerations.

I will also note that it is essential that the option provide a means of
specifying the port to connect to in addition to the server name, and it might
be best if the default port was the SMTP-submit port 587 rather than port 25.
(I haven't looked at the IPv4 version of the option so I don't know if it
provides this capability or what the default is.)

				Ned

Date: Fri, 27 May 2005 08:47:59 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Cristian Cadar <[email-masked]>, [email-masked]
Subject: Re: SMTP option for DHCPv6
Sender: [email-masked]

On Fri, 27 May 2005, Eric A. Hall wrote:

> On 5/27/2005 11:33 AM, william(at)elan.net wrote:
>
>> SMTP option for DHCP may not be entirely useful but SUBMIT option for
>> DHCP sure sounds to me like something quite useful and network-topology
>> dependent in many instances.
>
> I don't see any other use for it (it's certainly not usable for
> mail-routing purposes, given that DHCP isn't intended to be available
> beyond a specific topology scope).

So perhaps we should not bother defining SMTP option for DHCPv6 at all
and just go ahead and do it under proper name.

This is not to say that SUBMIT server for particular network can not be 
located on port 25 as normal SMTP, but that would be up to that network 
to specify as part of DHCP SUBMIT information.

Same for DHCPv4 if SMTP option is not much used, it should possibly be 
depreciated and replaced by SUBMIT.

-- 
William Leibzon
Elan Networks
[email-masked]

Date: Fri, 27 May 2005 11:39:30 -0400
From: "Eric A. Hall" <[email-masked]>
To: "william(at)elan.net" <[email-masked]>
Cc: Cristian Cadar <[email-masked]>, [email-masked]
Subject: Re: SMTP option for DHCPv6
Sender: [email-masked]

On 5/27/2005 11:33 AM, william(at)elan.net wrote:

> SMTP option for DHCP may not be entirely useful but SUBMIT option for
> DHCP sure sounds to me like something quite useful and network-topology
> dependent in many instances.

I don't see any other use for it (it's certainly not usable for
mail-routing purposes, given that DHCP isn't intended to be available
beyond a specific topology scope).

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Fri, 27 May 2005 08:33:56 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Cristian Cadar <[email-masked]>, [email-masked]
Subject: Re: SMTP option for DHCPv6
Sender: [email-masked]

On Fri, 27 May 2005, Eric A. Hall wrote:

> Another point of difficulty here is that DHCP is mostly geared towards
> "host configuration" and not to "user-specific configuration". This has
> some security implications in application layer software--you may not want
> anonymous guest users using your mail server, or your mail server may
> require authentication (which won't work with guests), etc.
>
> Along the same lines, mail sessions are keyed to user identity, and user
> identity is independent of the current network topology, while DHCP is
> focused on topology identity.
>
> Having said all of that, defining the option could still be useful and the
> work should be done. But I wouldn't expect it to be used except in the
> minor subset of instances where the above factors coincide with actual
> installation considerations.

SMTP option for DHCP may not be entirely useful but SUBMIT option for
DHCP sure sounds to me like something quite useful and network-topology
dependent in many instances.

-- 
William Leibzon
Elan Networks
[email-masked]

Date: Fri, 27 May 2005 11:17:53 -0400
From: "Eric A. Hall" <[email-masked]>
To: Cristian Cadar <[email-masked]>
Cc: [email-masked]
Subject: Re: SMTP option for DHCPv6
Sender: [email-masked]

On 5/27/2005 5:04 AM, Cristian Cadar wrote:

> There is already a standardized SMTP option for DHCPv4. My question is:
> Do you know any implementation where SMTP option is used by somebody for
> delegating IPv4 SMTP server addresses to the clients? do you think that
> the SMTP option for DHCPv6 will be used in the future by the email
> clients?

The short answer is no.

The long answer consists of multiple parts. For one thing, most of the
client DHCP stacks are not integrated with application software very well.
About the best you can expect (and this isn't very good) is for the DHCP
client to overwrite config data for an application (like updating a
mail.conf file that it has been told about). Very few applications
actually make DHCP calls themselves, and in some cases this isn't even
possible because the DHCP client has bound to the ports and is preventing
the applications from making their own requests.

Another point of difficulty here is that DHCP is mostly geared towards
"host configuration" and not to "user-specific configuration". This has
some security implications in application layer software--you may not want
anonymous guest users using your mail server, or your mail server may
require authentication (which won't work with guests), etc.

Along the same lines, mail sessions are keyed to user identity, and user
identity is independent of the current network topology, while DHCP is
focused on topology identity.

Having said all of that, defining the option could still be useful and the
work should be done. But I wouldn't expect it to be used except in the
minor subset of instances where the above factors coincide with actual
installation considerations.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>, [email-masked]
Subject: Re: mail-followup-to / mail-copies-to
Date: Fri, 27 May 2005 10:41:43 -0400
Sender: [email-masked]

On Thu May 26 2005 19:27, Paul Jakma wrote:

> I think by looking at what MUAs do, one could define that context.

Depending on what you look at, you may get a different impression
(a corollary to "if the only tool that you have is a hammer, everything
looks like a nail").

> The fact that already several MUAs (popular ones at that, 
> thunderbird, apple mail, and mutt) /do/ do see fit to provide a "list 
> context"

I see nothing resembling that in Thunderbird.

> And it /does/ for mutt.

Only if everybody uses that specific UA with its non-standard quirks.
Not very realistic.

> "list context reply" should /not/ consider Reply-To, for if it did, 
> that would imply it should also consider "From", which obviously isnt 
> the idea.

I don't see how you're making the leap to that conclusion; From and
Reply-To fields have very different semantics -- they are not directly
linked.

> However, see above, I do not (at the moment) think it would be right 
> to consider From/Reply-To in a "list reply" context.

I see that you said so, but you offered no rationale.

> Hence, Reply-To can /not/ be used.

You're going to have to justify that claim.

> For reasons you gave previously  
> (what exactly does it indicate?

It indicates exactly what RFC 2822 says it indicates, as previously quoted.

[...]
> I suspect though I would fail if I instead set out to persuade 
> everyone to switch to Pine.

As long as standard mechanisms are used, and implementations comply with
those standard mechanisms, it doesn't matter which standards-conforming
implementation is used.

> > I'd first have to see a definition of that "list context" that is 
> > somehow distinctive from any other "context" and which makes some 
> > sort of sense given the fact that -- no matter what -- a respondent 
> > is going to have to decide where he wants to send responses.
> 
> Or rather than "where", in what /context/ they wish to respond. 
> Choosing the /context/ is easy for an user.
> 
> Those contexts are, in every MUA I know of, 'personal', 'all' and, in 
> several of the more popular MUAs, 'list':
> 
> - personal
> 
>  	Typically (it seems to me):
>  		To: (Reply-To) ? Reply-To : From

No, you're conflating separate things; use of Reply-To means "where the author
suggested" whereas use of From means "directly to the author(s)".
 
[...]
> My concern is solely with the 'list' case. I would propose it be (and 
> apologies again for not yet being familiar with the /correct/ 
> language for expressing these things):
> 
> - list
>  	To: List-Post

Several problems:
1. RFC 2369 fields are not mandatory; many lists do not use them
2. Sometimes one list's expansion feeds another list, and one may
   then have multiple sets of List-fields; one cannot in general tell
   which list is included in another.  Sending to all directly will
   result in duplicates in the included list.  Picking only the included
   list (by guessing) won't copy the subscribers of the other list who
   are not also subscribed to the included list.

The more serious problem is that mail doesn't have any notion of "context"
(other than the optional RFC 3458 field, which is unrelated to your concept);
it has only "recipients".  Your list of proposed "contexts" ignores the
type of real considerations that apply to selecting recipients:

o the author(s)
o the sender
o the reverse (delivery notification) path
o where the author suggested
o other recipients of the original, as indicated by the author(s) [N.B.
  there is no guarantee that they in fact were recipients]

For example, sending a "vacation"-like response is independent of any
of the items you listed as "context"; such responses need to go to the
delivery notification path (see RFC 3834).

As another, not uncommon, example, consider a message posted to a mailing
list with a request by the author to send off-list (only) responses, to
be summarized by the author.  The author could easily indicate that with
Reply-To, and every response that is directed "where the author suggested"
will comply with that.  For such a mailing list message, your "list context"
would send a doubly wrong response -- it wouldn't go directly to the author
(as requested) and would go to the entire list (contrary to the request). 

Date: Fri, 27 May 2005 11:42:01 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SMTP option for DHCPv6
Cc: Cristian Cadar <[email-masked]>
Sender: [email-masked]

Cristian Cadar writes:
> Do you know any implementation where SMTP option is used by somebody 
> for delegating IPv4 SMTP server addresses to the clients?

I can't think of any right now. There may be some.

> do you think that the SMTP option for DHCPv6 will be used in the 
> future by the email clients?

Unlikely. It (and the IPv4 option) is incompatible with SPF, and my bet 
is that SPF will prove stronger. (Oversimplifying, SPF is a hacky way 
to say "only these IP addresses may send mail from this domain".)

To see why it's incompatible, suppose you take your laptop along to the 
IETF in Paris in two months, and that your company uses SPF at that 
time. At the IETF, the DHCP server will give you an IP address. Perhaps 
it also gives you an SMTP server. If your laptop that server, then 
anyone who checks SPF will see that the IETF conference's SMTP server 
is not allowed to send mail on behalf of netlab.nec.de.

Personally, I think the problem is more with SPF than with your draft. 
However, in terms of realpolitik, SPF is IMO likely to be stronger.

Arnt

Content-class: urn:content-classes:message
Subject: SMTP option for DHCPv6
Date: Fri, 27 May 2005 11:04:54 +0200
From: "Cristian Cadar" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Dear all,

I was asked by the IETF DHC members to post this question here asking
for your opinion. I have recently submitted an IETF draft on SMTP option
for DHCPv6 protocol suite and presented my draft
http://www.ietf.org/internet-drafts/draft-cadar-dhc-dhcpv6-opt-smtp-00.t
xt during the last IETF meeting.
There is already a standardized SMTP option for DHCPv4. My question is:
Do you know any implementation where SMTP option is used by somebody for
delegating IPv4 SMTP server addresses to the clients? do you think that
the SMTP option for DHCPv6 will be used in the future by the email
clients?

Thank you in advance

Regards,

Cristian Cadar
NEC Europe Ltd.

Date: Fri, 27 May 2005 10:13:19 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: mail-followup-to / mail-copies-to
Cc: Bruce Lilly <[email-masked]>, [email-masked]
Sender: [email-masked]

Bruce Lilly writes:
> On Thu May 26 2005 16:26, Paul Jakma wrote:
>> This MUA also ignores From/Reply-To when "reply in list context" is used.
>
> That strikes me as equivalent to saying "screw you, I'm going to 
> completely ignore your stated request as well as the relevant 
> standards and do something different for spite".

Or "screw the moron list admin who probably mangled your perfectly fine 
message".

Arnt

Date: Fri, 27 May 2005 00:27:31 +0100 (IST)
From: Paul Jakma <[email-masked]>
Reply-To: [email-masked], [email-masked]
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, 26 May 2005, Bruce Lilly wrote:

> On Thu May 26 2005 16:26, Paul Jakma wrote:
>
>> However, if I would suggest this "list-reply" functionality should be
>> taken as "reply in a list context"
>
> One problem is defining precisely what that means, in a way which is
> likely to reach consensus.

Agreed.

I think by looking at what MUAs do, one could define that context.

The fact that already several MUAs (popular ones at that, 
thunderbird, apple mail, and mutt) /do/ do see fit to provide a "list 
context", in addition to the long standing "reply" and "reply to all" 
contexts, suggests there may be value in distinguishing this context 
from others.

> That strikes me as equivalent to saying "screw you, I'm going to 
> completely ignore your stated request as well as the relevant 
> standards and do something different for spite".

Ha! To an extent, I'd agree - and it's definitely caused me problems. 
However, just complaining about it though isn't productive, because 
the Mutt developers (and its users) do seem to feel it solves a 
problem.

And it /does/ for mutt. If I were to use Mutt and configure MFT for 
all the various lists, I'd generally be happy - except when non-Mutt 
users replied to me.

So I'd like to try help fix that, somehow, even if it's no more than 
clarifying best practice in some way. However, note that I /agree/ 
"list context reply" should /not/ consider Reply-To, for if it did, 
that would imply it should also consider "From", which obviously isnt 
the idea.

>> I would disagree that the list-reply functionality of some MUAs 
>> means "reply /only/ to list". One of more popular MUA which 
>> implements list-reply supports this view (as it will take MFT into 
>> consideration).
>
> The problem with that is that it leads to nasty surprises; an invisible
> (non-standard, not displayed) header field changes the way a function
> works, with no warning to the user.

I don't quite agree with MFT either. Please don't take the fact that 
I have this header in my mails as a sign I agree with it - it's there 
for least-worst reasons.

> Beware of some things that you may read; there are bogus claims 
> that "Reply-To prevents direct responses to an author" -- that is 
> simply untrue.  A moment's thought should convince you that given a 
> message:
>
>  From: [email-masked]
>  Reply-To: [email-masked]
>  Cc: [email-masked]
>
> nothing prevents you from sending a response to any of those 
> mailboxes, or indeed to [email-masked].  Now it may 
> be the case that *some* MUAs lack a single-key/click/whatever 
> "reply-to-author(s)" function, but that is an implementation issue 
> with those MUAs -- there certainly are several MUAs that do have 
> such a function -- and in no way results from some putative evil 
> characteristic of the Reply-To field.

Yes, I agree. Pine is quite good in this respect as it asks you what 
to do, it makes you think. Other MUAs unfortunately aren't as 
careful.

However, see above, I do not (at the moment) think it would be right 
to consider From/Reply-To in a "list reply" context. The entire 
reason "list reply" exists is because of a perceived desire that most 
people prefer not to get direct copies of list mail, my limited and 
statistically meaningless research seems to support this. :)

Hence, Reply-To can /not/ be used. For reasons you gave previously 
(what exactly does it indicate? A preference to direct public or 
personal mail? Whatever the rights or wrongs of that grey area, it 
exists - otherwise MUAs would not be offering a "list context" reply 
feature).

> No need. Pine already provides the option for a user to reply to 
> the author(s) (From field) or where the author(s) suggested 
> (Reply-To field) or to "group" and/or to any mailbox in the users 
> address book or which the user can type.

Yes, Pine is fine.

I suspect though I would fail if I instead set out to persuade 
everyone to switch to Pine. Activism here (and even drafting a 
proposal, if needs be) is, I hope, likely to be more productive (in 
the long term, I realise).

>> So is there any answer? Without wishing to have you prejudice your 
>> stance on the question(s), would you be able to suggest which 
>> avenues would the most fruitful to investigate?

> I'd first have to see a definition of that "list context" that is 
> somehow distinctive from any other "context" and which makes some 
> sort of sense given the fact that -- no matter what -- a respondent 
> is going to have to decide where he wants to send responses.

Or rather than "where", in what /context/ they wish to respond. 
Choosing the /context/ is easy for an user.

Those contexts are, in every MUA I know of, 'personal', 'all' and, in 
several of the more popular MUAs, 'list':

- personal

 	Typically (it seems to me):
 		To: (Reply-To) ? Reply-To : From

 	Better MUAs prompt the user:
 		prompt: "Use Reply-To or From?"

- all

 	Typically:

 		To: ((Reply-To) ? Reply-To : From)
 		Cc: To, Cc

 	(some MUAs may prompt)

- list

 	Typically (List-Post from header, or statically configured):

 		To: List-Post

 	Some:

 		To: List-Post, (MFT ? MFT : '')

 	Minority:

 		To: (MFT ? MFT : List-Post)

(apologies for the ad-hoc selection description language, it's 
intended to be vaguely according to C, as if above were headers, and 
anything left of initial : were variables named according to fields 
of replied-to-email along with the C ? operator. Duplicate and empty 
address/header removal after selection is implicit. I'll try figure 
out how to specify above (and below) in the correct way).

My concern is solely with the 'list' case. I would propose it be (and 
apologies again for not yet being familiar with the /correct/ 
language for expressing these things):

- list
 	To: List-Post
 	Cc: (Foo-Copies-To ? Foo-Copies-To : '')

The 'Foo-Copies-To' header would be additive, any one MAY add their 
address to it, and transitive, if it were present in a mail being 
replied to MUAs SHOULD retain it and its contents.

(I'd look at language of In-Reply-To and References to ensure it 
would be defined in a consistent and similar manner - apologies, but 
i'm not yet familiar with the correct language for this.).

> Up to you.  Unless you have a very clear idea of the problem and 
> the breadth of possible solutions, and have carefully considered 
> the implications, a draft may be premature.

See the above. Would work I think. Or at least, would /allow/ MUAs to 
work in a way that would keep me happy, wrt "list context replies".

> Sounds like the root of the problem is MUAs that implement the 
> "spiteful" stance noted earlier.

Yes, but they implement it because of a perceived problem. As much I 
would prefer that everyone would hit "reply to all" on list mails, I 
realise it's not going to happen - and MUAs now ever more are 
providing "list context" to make it easy for users to only mail the 
list and anyone who has indicated a preference for copies on list 
context mail - the problem is there no way to indicate that 
preference. :)

> Maybe a draft along the lines of "MUAs that do not respect standard 
> field semantics considered harmful" might raise awareness.

It might, but I'd imagine it would be ignored if there is no solution 
to "list context".

> Whether or not that root problem will be fixed is another matter...

Hehe.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
If you think last Tuesday was a drag, wait till you see what happens tomorrow!

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>, [email-masked]
Subject: Re: mail-followup-to / mail-copies-to
Date: Thu, 26 May 2005 18:38:57 -0400
Sender: [email-masked]

On Thu May 26 2005 16:26, Paul Jakma wrote:

> However, if I would suggest this "list-reply" functionality should be 
> taken as "reply in a list context"

One problem is defining precisely what that means, in a way which is
likely to reach consensus.

> This MUA also ignores From/Reply-To when "reply in list context" is 
> used.

That strikes me as equivalent to saying "screw you, I'm going to
completely ignore your stated request as well as the relevant standards
and do something different for spite".

> > "Only to list" really has to mean "only to list".  If there were a 
> > hypothetical way for a message originator to cause a recipient's 
> > MUA to do something else for "reply only to list", matters would be 
> > far worse than now (I think Keith Moore made that observation last 
> > year).
> 
> I would disagree that the list-reply functionality of some MUAs means 
> "reply /only/ to list". One of more popular MUA which implements 
> list-reply supports this view (as it will take MFT into 
> consideration).

The problem with that is that it leads to nasty surprises; an invisible
(non-standard, not displayed) header field changes the way a function
works, with no warning to the user.
 
> As you point out above, Reply-To would suggest a preference for both 
> 'public' and 'private' replies, which is /not/ quite the preference I 
> /really/ want to indicate to others, or anyone else like me who 
> prefers to receive direct copies on list replies and any subsequent 
> replies in a thread. (And the difference is critical to me, even if i 
> fail to convince anyone here of the need for extra standards work, I 
> wont be using Reply-To, because of limitations/dangers in its use in 
> a list context).

Beware of some things that you may read; there are bogus claims that
"Reply-To prevents direct responses to an author" -- that is simply
untrue.  A moment's thought should convince you that given a message:

  From: [email-masked]
  Reply-To: [email-masked]
  Cc: [email-masked]

nothing prevents you from sending a response to any of those
mailboxes, or indeed to [email-masked].  Now it may
be the case that *some* MUAs lack a single-key/click/whatever
"reply-to-author(s)" function, but that is an implementation issue
with those MUAs -- there certainly are several MUAs that do have such
a function -- and in no way results from some putative evil
characteristic of the Reply-To field.

> > You can try to convince MUA developers to provide a set of 
> > response options that includes "where the author suggested" -- 
> > maybe some will, maybe some won't (that also of course applies to a 
> > new proposal, but encouraging support for a standard mechanism may 
> > be easier to get across).
> 
> Well, my preferred MUA is Pine. There is 0 chance of persuading the 
> Pine developers to add support for such things without something that 
> is to make it to standards track.

No need. Pine already provides the option for a user to reply to the
author(s) (From field) or where the author(s) suggested (Reply-To
field) or to "group" and/or to any mailbox in the users address book or
which the user can type.

> So is there any answer? Without wishing to have you prejudice your 
> stance on the question(s), would you be able to suggest which avenues 
> would the most fruitful to investigate?

I'd first have to see a definition of that "list context" that is
somehow distinctive from any other "context" and which makes some
sort of sense given the fact that -- no matter what -- a respondent
is going to have to decide where he wants to send responses.

> Am I right in thinking this is where I draw up a draft, eg one 
> focused solely on the issue of affecting mailbox selection in "list 
> context" replies? (Or would it be better to first answer these 
> questions here, in list email?).

Up to you.  Unless you have a very clear idea of the problem and
the breadth of possible solutions, and have carefully considered
the implications, a draft may be premature.

> Initially I tried whining on the mailling list concerned "Please, use 
> reply-all like $DEITY intended - i like to get direct mail for 
> replies and threads i'm involved in". Replies ranged from:
> 
> - Why could you possibly want a direct copy?
> - So we're supposed to remember every person's preference when we
>    reply?
> - Your fault for using Pine, use Mutt
> - Set a Mail-Followup-To header.
> - Oh stop whining paul
> - Why dont you just filter based on In-Reply-To and/or References and
>    create the extra copy yourself?
> 
> The more I whinge, the more beer gets spilled on me 'accidently' at 
> LUG meets. (And recently things have taken a turn for the worse, the 
> empty glasses now also get thrown at me). :)

Sounds like the root of the problem is MUAs that implement the "spiteful"
stance noted earlier.  Maybe a draft along the lines of "MUAs that do
not respect standard field semantics considered harmful" might raise
awareness.  Whether or not that root problem will be fixed is another
matter...

Date: Thu, 26 May 2005 21:26:39 +0100 (IST)
From: Paul Jakma <[email-masked]>
Reply-To: [email-masked], [email-masked]
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, 26 May 2005, Bruce Lilly wrote:

> Well, if an MUA user selects "reply (only) to list", is it really 
> surprising that the reply goes only to the list mailbox? 
> Ultimately, what a respondent chooses will affect where a response 
> goes, no matter what somebody else might suggest.  That's a key 
> point.

I agree. If a respondent really wants "send to list", they should get 
that.

However, if I would suggest this "list-reply" functionality should be 
taken as "reply in a list context" rather than "reply /only/ to 
list", particularly since one popular MUA /will/ copy those who 
indicate a preference for it - using a (unfortunately non-standard) 
mail header - most definitely not "reply /only/ to list".

This MUA also ignores From/Reply-To when "reply in list context" is 
used.

> The field simply specifies "the mailbox(es) to which the author of 
> the message suggests that replies be sent".  Whether a response is 
> "public" or "private" is at least as much under the control of the 
> respondent. Now it's certainly true that the Reply-To field doesn't 
> indicate *why* the message author has made the suggestion in any 
> machine-readable form, but an author who wishes to indicate a 
> reason can use a phrase (in any suitable charset and language using 
> RFC 2047 mechanisms) in named group syntax or name-addr syntax, or 
> in a (mildly deprecated) comment.

So you're saying I should have something vaguely like:

 	(please include me in list replies) <[email-masked]>

as my From address on list email? I'm not sure that'll work. I have 
actually tried something like this before. Most people dont look at 
the addresses, they just hit 'reply', 'reply-all' or 'list-reply' and 
figure their MUA will work it out. All I want is a way to help those 
other MUAs figure out that I /do/ like to get copies for /list/ 
replies.

> In your specific case, distinguishing between suggestions for 
> "private" and "public" responses won't help, because you want 
> responses to go to *both* a public list and to your personal 
> mailbox.

No, not quite.

I dont want responses to go to both a public list and my personal 
mailbox. But that's all I can achieve with Reply-To.

What I want is to be able to indicate a preference on whether I 
prefer a direct copy when an MUA decides automatically which 
mailbox(es)? to send email to when its user has asked for a "list 
context" reply.

> "Only to list" really has to mean "only to list".  If there were a 
> hypothetical way for a message originator to cause a recipient's 
> MUA to do something else for "reply only to list", matters would be 
> far worse than now (I think Keith Moore made that observation last 
> year).

I would disagree that the list-reply functionality of some MUAs means 
"reply /only/ to list". One of more popular MUA which implements 
list-reply supports this view (as it will take MFT into 
consideration).

> Without a) a carefully worded question, and b) a scientific, 
> statistically significant sample of responses, I would hesitate to 
> make such a claim.

Agreed.

Sorry, that assertion is made based only on vague anecdotal evidence 
- I should have made that clear. (I asked the question on the 'ILUG' 
list a while ago, the responses were a small sample of its 700 
subscribers, all but 1 indicated they preferred to not receive direct 
copies).

> Sometimes it's beyond the scope of what standardization can do.

Standardisation can not do it, I agree.

Standards can /allow/ for it however.

A complete lack of suitable standards can make it impossible. (And/or 
lead to ad-hoc'ery, eg MFT).

>> However there is no hope of influencing future implementations to do
>> 'the right thing' without some attempt to standardise what this
>> 'right thing' is. (To be specific, this "right thing" for me
>> currently is a way to allow me to specify my unusual preference to be
>> included in list replies).
>
> "specify [a] preference" == "suggest [where] replies be sent" == Reply-To.
>
> Whether or not a particular recipient will honor that suggestion, or
> whether his choice of MUA will permit it, are separate matters.

That is fine.

I'm not arguing for MUST, I'm arguing there should be something at 
least that allows for MAY.

> Many UAs provide multiple response options.  If a respondent 
> (habitually or otherwise) chooses something other than "where the 
> author suggested" there isn't anything you can do.

I agree.

The problem is there is no good way for me to even make the 
suggestion.

As you point out above, Reply-To would suggest a preference for both 
'public' and 'private' replies, which is /not/ quite the preference I 
/really/ want to indicate to others, or anyone else like me who 
prefers to receive direct copies on list replies and any subsequent 
replies in a thread. (And the difference is critical to me, even if i 
fail to convince anyone here of the need for extra standards work, I 
wont be using Reply-To, because of limitations/dangers in its use in 
a list context).

> One thing is certain; if you do not provide a suggestion (via the 
> established standard mechanism), you guarantee that no respondent 
> can comply with your wishes other than by accident.  In the absence 
> of such a suggestion, some respondents may be forced into 
> "reply-to-all" (which happens to be compatible with what you want), 
> whereas others may choose "reply-to-list-only", etc.

A means to provide the suggestion is all I want :)

>> I very much wish to avoid getting stuck in #2-#4.

> You can't avoid #2; the respondent's freedom of choice trumps the 
> author's suggestion.

Of course, I am not at all arguing for  "MUST include the mailbox in 
the Foo-Copy-Me-Please in any replies" behaviour.

I meant more I do not wish to try change any of the already 
standardised headers that affect the broader scope of #2-#4, or how 
MUAs present functionality to users.

I merely wish to have a /valid/ way of indicating my preference to an 
MUA, when its user asks for something along the lines of "list 
context reply". That, eg, Mutt and at least other MUA seem amienable 
to modifying their list-reply behaviour based on information in 
headers, where they will not consider Reply-To/From, seems to suggest 
there is at least some validity in wanting to be able to express such 
a preference.

> Always.  You can try to convince MUA developers to provide a set of 
> response options that includes "where the author suggested" -- 
> maybe some will, maybe some won't (that also of course applies to a 
> new proposal, but encouraging support for a standard mechanism may 
> be easier to get across).

Well, my preferred MUA is Pine. There is 0 chance of persuading the 
Pine developers to add support for such things without something that 
is to make it to standards track. Nor would I approach other MUAs 
unless there were some proposal with a good chance of achieving 
consensus. :)

> There's no registered field with that name, though there's a draft 
> that contains a proposal.  First-come, first-served. (but I don't 
> think that's the answer)

Aha.

So is there any answer? Without wishing to have you prejudice your 
stance on the question(s), would you be able to suggest which avenues 
would the most fruitful to investigate?

> The first problem is that no MUA currently recognizes that, so none 
> will copy it to responses.

Agreed.

> A second issue is what happens when a respondent intentionally 
> wishes to send a private response?  And how is the MUA supposed to 
> know the respondent's intentions?

Good questions.

I would suggest a private response should not take any 
'Foo-Copies-To' header into consideration. Reply-To it probably 
should. (But then, didn't I read that From and only From should be 
taken as being the originator's mailbox? But that's not really my 
concern here.).

> First question is precisely what semantics are you trying to 
> indicate, and how is that different from "the mailbox(es) to which 
> the author of the message suggests that replies be sent"?  I.e. 
> first carefully formulate the problem that you're trying to solve, 
> as clearly and precisely as possible -- solving the wrong problem 
> is rarely a good approach.

Agreed.

Am I right in thinking this is where I draw up a draft, eg one 
focused solely on the issue of affecting mailbox selection in "list 
context" replies? (Or would it be better to first answer these 
questions here, in list email?).

Thanks for this paragraph of your reply, most wise.

> Another point to consider is that solutions to problems do not 
> exclusively lie in the realm of "let's invent a new header field to 
> ...".

I agree.

Initially I tried whining on the mailling list concerned "Please, use 
reply-all like $DEITY intended - i like to get direct mail for 
replies and threads i'm involved in". Replies ranged from:

- Why could you possibly want a direct copy?
- So we're supposed to remember every person's preference when we
   reply?
- Your fault for using Pine, use Mutt
- Set a Mail-Followup-To header.
- Oh stop whining paul
- Why dont you just filter based on In-Reply-To and/or References and
   create the extra copy yourself?

The more I whinge, the more beer gets spilled on me 'accidently' at 
LUG meets. (And recently things have taken a turn for the worse, the 
empty glasses now also get thrown at me). :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
What happens when you cut back the jungle?  It recedes.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>, Bill Fenner <[email-masked]>
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Date: Thu, 26 May 2005 15:06:23 -0400
Cc: [email-masked]
Sender: [email-masked]

On Thu May 26 2005 09:44, Bill Fenner wrote:

> The RFC Editor has explicitly said that they don't have a position on
> numbered or unnumbered references sections.  RFC2223bis itself is not
> consistent on this topic; when it mentions splitting
> normative/informative it talks about sections s and s+1, but 2223bis
> itself doesn't use numbered sections.

Note that 2223bis has Appendices (I'll return to that).

If the RFC Editor really doesn't care, then it boils down to other
considerations (and as I said, it's probably not a big deal). Anyway:

Numbered:
 IF one has reason to refer to the section (as opposed to citing references),
   then a numbered section makes some sense.

Unnumbered:
 More concise.

 Avoids problems with numbering, especially when there are Appendices (which
   are recommended to appear before References)

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Date: Thu, 26 May 2005 14:18:17 -0400
Cc: Paul Jakma <[email-masked]>
Sender: [email-masked]

On Thu May 26 2005 12:34, Paul Jakma wrote:

> > 1. What a message originator wishes to indicate as a preference
> 
> Right.
> 
> You indicated previously 'reply-to' should be used, however it has 
> problems (and is ignored completely in the "list context" reply mode 
> of some MUAs - where the non-standard MFT is not).

Well, if an MUA user selects "reply (only) to list", is it really
surprising that the reply goes only to the list mailbox?  Ultimately,
what a respondent chooses will affect where a response goes, no matter
what somebody else might suggest.  That's a key point.
 
> Right, but it most definitely has problems. (It's not fine-grained 
> enough to distinguish between public and private replies).

The field simply specifies "the mailbox(es) to which the author of the
message suggests that replies be sent".  Whether a response is "public"
or "private" is at least as much under the control of the respondent.
Now it's certainly true that the Reply-To field doesn't indicate *why*
the message author has made the suggestion in any machine-readable
form, but an author who wishes to indicate a reason can use a phrase (in
any suitable charset and language using RFC 2047 mechanisms) in named
group syntax or name-addr syntax, or in a (mildly deprecated) comment.

In your specific case, distinguishing between suggestions for "private"
and "public" responses won't help, because you want responses to go to
*both* a public list and to your personal mailbox.

> Send to list sends only to list because there is no good way for the 
> originator what their preference is on list-replies.

"Only to list" really has to mean "only to list".  If there were a
hypothetical way for a message originator to cause a recipient's
MUA to do something else for "reply only to list", matters would
be far worse than now (I think Keith Moore made that observation last
year).

> The majority of  
> people today prefer not to receive a direct copy

Without a) a carefully worded question, and b) a scientific, statistically
significant sample of responses, I would hesitate to make such a claim.

> What MUAs do and dont do is not directly in the hands of the 
> standards, but we can learn from it as to whether there is a need for 
> further standard specification, and if so what.

Sometimes it's beyond the scope of what standardization can do.
 
> However there is no hope of influencing future implementations to do 
> 'the right thing' without some attempt to standardise what this 
> 'right thing' is. (To be specific, this "right thing" for me 
> currently is a way to allow me to specify my unusual preference to be 
> included in list replies).

"specify [a] preference" == "suggest [where] replies be sent" == Reply-To.

Whether or not a particular recipient will honor that suggestion, or
whether his choice of MUA will permit it, are separate matters.
 
> Yes. Unfortunately, this doesn't solve my problem as more and more 
> MUAs implement 'list reply' functionality, and do not reply to 
> originator.

Many UAs provide multiple response options.  If a respondent (habitually
or otherwise) chooses something other than "where the author suggested"
there isn't anything you can do.  One thing is certain; if you do not
provide a suggestion (via the established standard mechanism), you
guarantee that no respondent can comply with your wishes other than
by accident.  In the absence of such a suggestion, some respondents
may be forced into "reply-to-all" (which happens to be compatible with
what you want), whereas others may choose "reply-to-list-only", etc.

> I very much wish to avoid getting stuck in #2-#4.

You can't avoid #2; the respondent's freedom of choice trumps the
author's suggestion.  Always.  You can try to convince MUA developers
to provide a set of response options that includes "where the author
suggested" -- maybe some will, maybe some won't (that also of course
applies to a new proposal, but encouraging support for a standard
mechanism may be easier to get across).

> Ok. It can't be 'Mail-Copies-To' unfortunately, because it's already 
> in use in (i think) NNTP, can it?

There's no registered field with that name, though there's a draft that
contains a proposal.  First-come, first-served. (but I don't think that's
the answer)
 
> >> Which MTAs should retain in replies.
> >
> > MTAs play no direct role in responses; perhaps you mean MUAs?

The first problem is that no MUA currently recognizes that, so none will
copy it to responses.

A second issue is what happens when a respondent intentionally wishes to
send a private response?  And how is the MUA supposed to know the
respondent's intentions?

> Does that sound reasonable?

First question is precisely what semantics are you trying to indicate,
and how is that different from "the mailbox(es) to which the author of
the message suggests that replies be sent"?  I.e. first carefully
formulate the problem that you're trying to solve, as clearly and
precisely as possible -- solving the wrong problem is rarely a good
approach.

Another point to consider is that solutions to problems do not
exclusively lie in the realm of "let's invent a new header field to ...".

From: [email-masked]
Cc: ietf-822 <[email-masked]>, Yakov Shafranovich <[email-masked]>
Date: Thu, 26 May 2005 09:34:49 -0700 (PDT)
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On Wed May 25 2005 22:33, Yakov Shafranovich wrote:

> > In this specific case, additional registered fields need to specify the
> > type of feedback they are used for.

> That's a design issue which should probably be revisited, particularly
> in light of review comments regarding "other" and "any".

> > By using BCP 90, there isn't
> > sufficient space to do that. Same goes for the DSN/MDN/MTSN fields which
> > need more than simple registration.

> For DSN, MDN, MTSN fields, the BCP 90 registration "applicable protocol"
> field could specify "DSN", "MDN", or "MTSN" as appropriate.
 
> > Any particular reason why these fields were not included in the initial
> > header registry? Sounds rather strange to me.

> Probably nobody got around to it yet; some message header fields aren't
> yet registered and HTTP fields haven't yet been registered.

That's not it at all. The issue was and is that there are already separate
registries for DSN and MDN report field extensions. There was no need for them
to use the BCP 90 registry. The IESG flatly rejected the attempt to build a
single, all-inclusive registry, and opted instead for a registry for certain
specific protocols that didn't already have then plus allowing the option for
future protocols to use the registry if they so desired.

IMO this work would be better off with a separate registry that doens't
conflate these fields with header fields in other protocols. But that's
just my position - you could try and use the BCP 90 header registry, keeping
in mind that there may be pushback since these are not, properly speaking,
header fields.

				Ned

Date: Thu, 26 May 2005 17:34:11 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi Bruce,

On Thu, 26 May 2005, Bruce Lilly wrote:

> There are several largely separate but intertwined issues:

> 1. What a message originator wishes to indicate as a preference

Right.

You indicated previously 'reply-to' should be used, however it has 
problems (and is ignored completely in the "list context" reply mode 
of some MUAs - where the non-standard MFT is not).

> 2. Where a respondent wishes to direct responses, which may be
>   different from #1
> 3. What capabilities are present in a particular MUA
> 4. How MUA capabilities are labeled and what they actually do
> 5. What specific list management software does to a message's content
>   when processing a list message
> 6. How specific list management software processes delivery of list
>   messages for particular list recipients
>
> The standard way to handle #1 is via the Reply-To field.

Right, but it most definitely has problems. (It's not fine-grained 
enough to distinguish between public and private replies).

> Sometimes that's screwed up by #5, sometimes particular UAs screw 
> it up (#3,4)
>
> A respondent can choose where to send responses, and he might 
> choose to ignore or override the original message originators 
> expressed preference. if any.  Obviously, if a respondent chooses a 
> "send only to list" response option (if supported by #3, #4), 
> that's where the response will go, regardless of the original 
> message originator's preference.

Send to list sends only to list because there is no good way for the 
originator what their preference is on list-replies. The majority of 
people today prefer not to receive a direct copy - this leaves the 
minority of people who /do/ want a direct copy high and dry.

> If a particular MUA doesn't provide an option to honor the original 
> message originator's expressed preference (#3,4) a respondent is 
> left with some other response choice (#2).  Some MUAs support 
> non-standard fields; most do not.  Given the fact that some MUAs do 
> not support standard functionality, an assumption that all MUAs 
> support non-standard fields would be ill-advised.

What MUAs do and dont do is not directly in the hands of the 
standards, but we can learn from it as to whether there is a need for 
further standard specification, and if so what.

"list reply" functionality in MUAs has come into existence, IMHO, 
because of weaknesses in the standards. And unfortunately has 
degraded functionality (for a minority of odd-balls who subscribe to 
/lots/ of lists, but degraded none the less).

> There is no standard for labeling or functionality of MUA 
> implementation response options (#4), and the IETF doesn't 
> generally attempt to impose such restrictions on implementations. 
> There might be some use for a glossary of terms and/or a 
> non-binding informational "white paper" for MUA developers, but 
> ultimately, MUA developers will do what they want in this area (and 
> some MUAs would change very slowly, if ever, even if there were a 
> "white paper" making specific recommendations).  Any assumption on 
> the part of a message originator about the features or capabilities 
> of recipients' MUAs is likely to fail for some subset of 
> recipients.

Sure. I agree.

There is nothing one can do about problems in existing 
implementations.

However there is no hope of influencing future implementations to do 
'the right thing' without some attempt to standardise what this 
'right thing' is. (To be specific, this "right thing" for me 
currently is a way to allow me to specify my unusual preference to be 
included in list replies).

> Some list expanders screw up originators' expressed preferences; 
> that is discouraged, and most lists don't do that.
>
> Some lists have per-subscriber options (#6) to suppress list messages
> sent to that subscriber if the subscriber's mailbox is listed verbatim
> in a message To or Cc field.

Yes. Unfortunately, this doesn't solve my problem as more and more 
MUAs implement 'list reply' functionality, and do not reply to 
originator.

> Obviously, a subscriber who wants both list and individual message 
> copies can't set that type of option. Slightly less obvious is the 
> fact that a list subscriber who is known to have such an option set 
> can be prevented from seeing a message (maliciously or otherwise) 
> by including that subscriber's mailbox in the To or Cc message 
> header fields (those fields of course have nothing to do with 
> actual message delivery).

Right.

> It sounds like you're starting from #1, but are getting hung up on 
> issues associated with #2-#4.

Yes, #1 is my only concern.

I very much wish to avoid getting stuck in #2-#4.

> About the best you can do is to indicate your preference with a 
> standard mechanism, and hope that that will be honored by 
> respondents who are able to do so.

That would be ideal.

I'm not concerned about current implementations. My concern is that 
in X years time there still will be no standard way of indicating 
this preference (once a standard exists, MUA implementors can be 
asked to implement it, and maybe one day majority of implementations 
will support it).

> You might try supplementing that with non-standard fields, but as 
> you have already found out, those fields are not widely noticed and 
> result in different behavior with different implementations which 
> do notice them.  They can also interact badly with the standard 
> mechanism, defeating your intent.

Indeed, I'm not at all happy with my MFT. But it's only way to deal 
with Mutt (it adversely affects users of other MUAs, which implement 
MFT strictly according to DJB spec, ability to reply to me and list - 
but those MUAs are /tiny/ group compared to mutt users)

> The List- convention is usually used for fields related to mailing lists
> and added by list expanders.  You might want to choose a different name
> to avoid stepping on that convention.

Ok. It can't be 'Mail-Copies-To' unfortunately, because it's already 
in use in (i think) NNTP, can it?

>> Which MTAs should retain in replies.
>
> MTAs play no direct role in responses; perhaps you mean MUAs?

Urr, yes :)

>> Which would clearly indicate my preference to be copied on list 
>> replies. That would allow my problem with how "list reply" context 
>> works in several recent MTA implementations to be solved.
>
> And what happens if a respondent wants a different set of 
> preferences for responses to *his* message?

The header can be additive, surely? As References are.

> Should he change the field?  Or not? If not, then how would he 
> indicate his preferences?  What about 3rd generation responses, 
> etc.?

Any user who would be like to be included in a discussion can simply 
add their mailbox to the header (or mailbox of any other party they 
think may be interested).

> When a discussion veers off track, as many do, how do you propose 
> stopping the copies (or don't you care?)?

You wouldn't be able to, without replying and removing your mailbox 
from the header and asking respondents to ensure same in other 
further replies of that thread. Same deal as with giant Cc lists 
really, but less of a problem because the "copy me" person took a 
/positive/ step to try influence others to copy them directly. They 
*want* to be copied. Other than that it's a netiquette problem.

Does that sound reasonable? (And should this supercede existing 
ad-hoc definition of Mail-Copies-To, or should that header name be 
used?). If so, I'll download xml2rfc..

> How many decades are you willing to wait for widespread deployment 
> of your proposal (some people still use /bin/mail)?

Try help a standard be formulated to address this problem and 
accepted, then wait a decade for implementors (possibly gently poking 
them), I can do.

Sit around for another decade doing nothing and just *wishing* 
someone else would try push for a "copy me please" header to be 
standardised and implemented, I can't any longer ;)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
If God had meant for us to be in the Army, we would have been born with
green, baggy skin.

To: [email-masked]
Xref: clerew local.mime:4696
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Date: Thu, 26 May 2005 11:40:40 GMT
Lines: 29
Sender: [email-masked]

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

>Bruce Lilly wrote:
>> 
>>    o The draft refers to RFC 2616, which is an HTTP specification that
>>      uses a different field syntax from the Internet Message Format.
>> 

>I did not find any other standard that defines the user agent field. The 
>"User-Agent" and "Mailer" fields used by email programs are not defined 
>in any standard that I was able to locate. Perhaps a new registration or 
>document for the user agent field should be written, OR the syntax 
>copied from RFC 2616 and included in this document in long hand.

You will find a definition of User-Agent, suitable for both News and Mail,
in draft-ietf-usefor-usefor-04.txt.

It is essentially the same as the one in RFC 2616, modulo a few niggles.

-- 
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: Bruce Lilly <[email-masked]>
Reply-To: Bruce Lilly <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Date: Thu, 26 May 2005 12:08:04 -0400
Cc: Yakov Shafranovich <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 22:33, Yakov Shafranovich wrote:

> In this specific case, additional registered fields need to specify the 
> type of feedback they are used for.

That's a design issue which should probably be revisited, particularly
in light of review comments regarding "other" and "any".

> By using BCP 90, there isn't  
> sufficient space to do that. Same goes for the DSN/MDN/MTSN fields which 
> need more than simple registration.

For DSN, MDN, MTSN fields, the BCP 90 registration "applicable protocol"
field could specify "DSN", "MDN", or "MTSN" as appropriate.
 
> Any particular reason why these fields were not included in the initial 
> header registry? Sounds rather strange to me.

Probably nobody got around to it yet; some message header fields aren't
yet registered and HTTP fields haven't yet been registered.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Date: Thu, 26 May 2005 12:01:18 -0400
Cc: Paul Jakma <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu May 26 2005 09:35, Paul Jakma wrote:

> I'm interested in solving the problem of a new reply context, "list 
> reply", which many MUAs offer now, for which context there is no good 
> way for originators to indicate a preference of "copy me directly on 
> replies".
> 
> AFAICT, all MUAs implementing such reply contexts default to "email 
> the list", where the list mailbox is either statically configured or 
> else deduced from the post-822 List-* headers. All these MUAs 
> (afaict), ignore reply-to in this context, some will allow themselves 
> by influenced by a non-standard Mail-Followup-To header.

There are several largely separate but intertwined issues:
1. What a message originator wishes to indicate as a preference
2. Where a respondent wishes to direct responses, which may be
   different from #1
3. What capabilities are present in a particular MUA
4. How MUA capabilities are labeled and what they actually do
5. What specific list management software does to a message's content
   when processing a list message
6. How specific list management software processes delivery of list
   messages for particular list recipients

The standard way to handle #1 is via the Reply-To field.  Sometimes
that's screwed up by #5, sometimes particular UAs screw it up (#3,4)

A respondent can choose where to send responses, and he might choose to
ignore or override the original message originators expressed preference.
if any.  Obviously, if a respondent chooses a "send only to list"
response option (if supported by #3, #4), that's where the response
will go, regardless of the original message originator's preference.

If a particular MUA doesn't provide an option to honor the original
message originator's expressed preference (#3,4) a respondent is left
with some other response choice (#2).  Some MUAs support non-standard
fields; most do not.  Given the fact that some MUAs do not support
standard functionality, an assumption that all MUAs support non-standard
fields would be ill-advised.

There is no standard for labeling or functionality of MUA implementation
response options (#4), and the IETF doesn't generally attempt to impose
such restrictions on implementations.  There might be some use for a
glossary of terms and/or a non-binding informational "white paper" for
MUA developers, but ultimately, MUA developers will do what they want
in this area (and some MUAs would change very slowly, if ever, even if
there were a "white paper" making specific recommendations).  Any
assumption on the part of a message originator about the features or
capabilities of recipients' MUAs is likely to fail for some subset of
recipients.

Some list expanders screw up originators' expressed preferences; that
is discouraged, and most lists don't do that.

Some lists have per-subscriber options (#6) to suppress list messages
sent to that subscriber if the subscriber's mailbox is listed verbatim
in a message To or Cc field.  Obviously, a subscriber who wants both
list and individual message copies can't set that type of option.
Slightly less obvious is the fact that a list subscriber who is known
to have such an option set can be prevented from seeing a message
(maliciously or otherwise) by including that subscriber's mailbox in
the To or Cc message header fields (those fields of course have nothing
to do with actual message delivery).

> That's the problem statement I'm concerned with, no more :).

It sounds like you're starting from #1, but are getting hung up on
issues associated with #2-#4.  About the best you can do is to indicate
your preference with a standard mechanism, and hope that that will be
honored by respondents who are able to do so.  You might try
supplementing that with non-standard fields, but as you have already
found out, those fields are not widely noticed and result in different
behavior with different implementations which do notice them.  They
can also interact badly with the standard mechanism, defeating your
intent.
 
> What I really want is a List-Copies-To type header...
> 
>  	List-Copies-To: [email-masked]

The List- convention is usually used for fields related to mailing lists
and added by list expanders.  You might want to choose a different name
to avoid stepping on that convention.
 
> Which MTAs should retain in replies.

MTAs play no direct role in responses; perhaps you mean MUAs?

> Which would clearly indicate my  
> preference to be copied on list replies. That would allow my problem 
> with how "list reply" context works in several recent MTA 
> implementations to be solved.

And what happens if a respondent wants a different set of preferences
for responses to *his* message?  Should he change the field?  Or not?
If not, then how would he indicate his preferences?  What about 3rd
generation responses, etc.?  When a discussion veers off track, as
many do, how do you propose stopping the copies (or don't you care?)?
How many decades are you willing to wait for widespread deployment of
your proposal (some people still use /bin/mail)?

Date: Thu, 26 May 2005 06:44:38 -0700
From: Bill Fenner <[email-masked]>
Reply-To: Bill Fenner <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Cc: ietf-822 <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On 5/25/05, [email-masked] <[email-masked]> wrote:
> > >    o References are normally unnumbered sections.
> 
> > Can you provide a reasoning for this or is this simply something the
> > community is used to?
> 
> It is what the RFC Editor requires. Adopting the format of the final RFC sooner
> rather than later often saves time.

The RFC Editor has explicitly said that they don't have a position on
numbered or unnumbered references sections.  RFC2223bis itself is not
consistent on this topic; when it mentions splitting
normative/informative it talks about sections s and s+1, but 2223bis
itself doesn't use numbered sections.

Looking at the 161 RFCs since RFC3900, 150 of them seem to have
'normative references' sections; 142 of them are numbered and 8 are
not.

forbin% grep -li '^[0-9][0-9.]* *normative references' rfc39??.txt
rfc4???.txt  | wc -l
     142
forbin% grep -li '^ *normative references' rfc39??.txt rfc4???.txt  | wc -l
       8

  Bill

Date: Thu, 26 May 2005 14:35:16 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: IETF RFC-822 list <[email-masked]>, [email-masked]
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi Adam,

(NB: I still have to finish reading through all the previous thread 
Bruce pointed me at).

On Thu, 26 May 2005, Adam M. Costello wrote:

> There are several things that would be useful to be able to express.

Note that I'm not particularly interested in generally changing how 
respondents reply to mails, and what cues they might have as to where 
to direct replies. It seems that discussion might be long and already 
well trodden.

I'm interested in solving the problem of a new reply context, "list 
reply", which many MUAs offer now, for which context there is no good 
way for originators to indicate a preference of "copy me directly on 
replies".

AFAICT, all MUAs implementing such reply contexts default to "email 
the list", where the list mailbox is either statically configured or 
else deduced from the post-822 List-* headers. All these MUAs 
(afaict), ignore reply-to in this context, some will allow themselves 
by influenced by a non-standard Mail-Followup-To header.

That's the problem statement I'm concerned with, no more :).

> Here are the ones that spring to my mind right now:
>
>  * What sorts of replies are allowed/encouraged:
>    - Prefer private reply.
>    - Prefer public reply.
>    - Public reply is the only option (From address is bogus).
>    - No preference.
>
>    (Mailing lists may want to supply a preference if the author did
>    not supply one, but they generally should not clobber the author's
>    preference if one was supplied.)

I think this debate is fraught with difficulties if one wishes to 
achieve consensus.

Note that Reply-To /sort of/ works ok for public reply, if one 
ignores the "list context reply" of some MUAs. Though, it's a very 
dangerous thing to set in an email to a list.

(presuming it's a sane list which does not munge Reply-To: to go to 
list).

>  * Where private replies should go:
>    - The From address vs. some other address(es).

>  * Where public replies should go:
>    - To the To/Cc addresses, or to some other addresses?  (For example,
>      replies to an announcement list might be directed to a discussion
>      list.)
>    - Should the private-reply address be excluded to avoid duplication
>      (because the public-reply addresses already cover it), or included
>      (because the public-reply addresses don't already cover it)?
>
> For a moment I thought about the ability to indicate that some of the
> To/Cc addresses should be excluded from public replies, but in that
> case, what are those addresses doing in the To/Cc field in the first
> place?
>
> What have I missed?

Not much, AFAICT. But this definitely has been covered previously in 
detail, without consensus AFAICT.

What I really want is a List-Copies-To type header...

 	List-Copies-To: [email-masked]

Which MTAs should retain in replies. Which would clearly indicate my 
preference to be copied on list replies. That would allow my problem 
with how "list reply" context works in several recent MTA 
implementations to be solved.

(I guess you could call it "Mail-Copies-To" - but I dont know what 
problems that header had, and a "List-Copies-To" header seems 
specific enough in its scope that it shouldn't trod on any of the 
difficult questions around Reply-To / MFT which seem impossible to 
achieve consensus on..)

> I'm confused by the Mail-Followup-To field in your message.  It 
> contains only your address, not the list address.  Doesn't that 
> mean that a "reply all" would go to you and nowhere else?  Surely 
> that's not what you intended?

> http://cr.yp.to/proto/replyto.html

Well, I have a vague notion that the old DRUMS I-D on MFT specified 
an inclusive behaviour on Reply-All, such that both MFT and To/Cc 
would be used to reply to. But I cant find a copy of the I-D anymore.

The DJB specification, the only one which google can guide one to 
with any easy, indeed would require me to include all relevant reply 
addresses in the MFT.

However, mutt seems to reply to MFT and list on list-reply, so it's 
good enough for me. I'd rather not to have set this vaguely defined 
and interpreted header though.

> I think you want both the list address and your address in
> Mail-Followup-To.

I don't want MFT at all. I just want people to include me in 
list-replies. ;)

> AMC

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Enjoy your life; be pleasant and gay, like the birds in May.

From: [email-masked]
Cc: ietf-822 <[email-masked]>, [email-masked], Yakov Shafranovich <[email-masked]>, [email-masked]
Date: Wed, 25 May 2005 21:44:38 -0700 (PDT)
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On Wed May 25 2005 18:32, [email-masked] wrote:
> > In any case, I agree that these are not
> > header fields and hence do not belong in the regular header field
> > registry.

> Discussion with Graham back when the registry documents were still
> in draft form seemed to indicate that it would be reasonable.

That may have been true at the time, but the IESG pushed back hard on having a
single general-purpose registry for all field names. What we ended up with
instead is a more specific registry for header fields in specific protocols.
There's no requirement that new protocols use the registry either.

> The
> use could be indicated via the registration form "applicable protocol"
> field.  The benefits would be as listed in RFC 3864:

>    Benefits of a central registry for message header field names
>    include:

>    o  providing a single point of reference for standardized and
>       widely-used header field names;

>    o  providing a central point of discovery for established header
>       fields, and easy location of their defining documents;

>    o  discouraging multiple definitions of a header field name for
>       different purposes;

These benefits arise from having a registy, not from having a common
registry.

>    o  helping those proposing new header fields discern established
>       trends and conventions, and avoid names that might be confused
>       with existing ones;

>    o  encouraging convergence of header field name usage across multiple
>       applications and protocols.

These benefits are to some extent linked to having a single registry. The
question, then, is whether these are real benefits for the fields at hand.
I don't think they are.

> Technically, of course, these aren't header fields,

Exactly.

> but sometimes fields
> don't stay put (MTAs insert empty lines, moving message fields into the
> body, for example).  And they do use the same syntax.

The behavior of egregiously broken software is hardly relevant.

> And note that some fields used in types similar to the one proposed in
> the draft under discussion are also used in message header fields (e.g.
> Original-Message-ID).  Benefits "discouraging multiple definitions
> for different purposes", "...discern established trends...", "encouraging
> convergence..." all are applicable.  The draft under discussion re.
> "User-Agent" is an example.

> With three related types already (DSN, MDN, MTSN), and some already
> existing common use (e.g. Original-Recipient, Final-Recipient), the
> benefits enumerated in 3864 seem clear.

Not when there's an existing registry, they don't.

				Ned

Date: Thu, 26 May 2005 04:15:41 +0000
From: "Adam M. Costello" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: mail-followup-to / mail-copies-to
Reply-To: IETF RFC-822 list <[email-masked]>, [email-masked]
Sender: [email-masked]

Paul Jakma <[email-masked]> wrote:

> We need some header to allow include-me-on-list-replies preference to
> be expressed, just as the List-* headers allow MUAs to 'pick' which
> address is the list address.

There are several things that would be useful to be able to express.
Here are the ones that spring to my mind right now:

  * What sorts of replies are allowed/encouraged:
    - Prefer private reply.
    - Prefer public reply.
    - Public reply is the only option (From address is bogus).
    - No preference.

    (Mailing lists may want to supply a preference if the author did
    not supply one, but they generally should not clobber the author's
    preference if one was supplied.)

  * Where private replies should go:
    - The From address vs. some other address(es).

  * Where public replies should go:
    - To the To/Cc addresses, or to some other addresses?  (For example,
      replies to an announcement list might be directed to a discussion
      list.)
    - Should the private-reply address be excluded to avoid duplication
      (because the public-reply addresses already cover it), or included
      (because the public-reply addresses don't already cover it)?

For a moment I thought about the ability to indicate that some of the
To/Cc addresses should be excluded from public replies, but in that
case, what are those addresses doing in the To/Cc field in the first
place?

What have I missed?

> Well personally I think Mail-Followup-To is problematic.

I'm confused by the Mail-Followup-To field in your message.  It contains
only your address, not the list address.  Doesn't that mean that a
"reply all" would go to you and nowhere else?  Surely that's not what
you intended?

http://cr.yp.to/proto/replyto.html

I think you want both the list address and your address in
Mail-Followup-To.

AMC

Date: Wed, 25 May 2005 20:30:12 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
cc: Bruce Lilly <[email-masked]>, [email-masked], ietf-822 <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Sender: [email-masked]

On Wed, 25 May 2005, Yakov Shafranovich wrote:

>> With three related types already (DSN, MDN, MTSN), and some already
>> existing common use (e.g. Original-Recipient, Final-Recipient), the
>> benefits enumerated in 3864 seem clear.
> ...
>
> Any particular reason why these fields were not included in the initial 
> header registry? Sounds rather strange to me.

1. Because Bruce does not agree with how they are used today
    - which btw your use in feedback-report would not be consistant with
    because so far I've not seen them in the content (mime) and only as
    part of mail header that undergone some special processing
2. Because of you register these, you'd end up thiking about registing all
    the other Original- header fields which pretty much means registration
    of corresponding original header field for every already registered
    (and some not registered) header fields, kind of tiresome...
3. If you don't want to register several dozen fields one-by-one then
    it'd have to be proposal to modify header field registration system
    and create special new subtype of header registry for "Prefix-x"
    (which I'd still like to do but can't quite get to it).

-- 
William Leibzon
Elan Networks
[email-masked]

Date: Wed, 25 May 2005 22:33:21 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: Bruce Lilly <[email-masked]>
CC: [email-masked], ietf-822 <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Sender: [email-masked]

Bruce Lilly wrote:
> On Wed May 25 2005 18:32, [email-masked] wrote:
> 
>>In any case, I agree that these are not
>>header fields and hence do not belong in the regular header field
>>registry.
> 
> 
> Discussion with Graham back when the registry documents were still
> in draft form seemed to indicate that it would be reasonable. The
> use could be indicated via the registration form "applicable protocol"
> field.  The benefits would be as listed in RFC 3864:
>
...

In this specific case, additional registered fields need to specify the 
type of feedback they are used for. By using BCP 90, there isn't 
sufficient space to do that. Same goes for the DSN/MDN/MTSN fields which 
need more than simple registration.

> 
> With three related types already (DSN, MDN, MTSN), and some already
> existing common use (e.g. Original-Recipient, Final-Recipient), the
> benefits enumerated in 3864 seem clear.
> 
...

Any particular reason why these fields were not included in the initial 
header registry? Sounds rather strange to me.

Yakov

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Date: Wed, 25 May 2005 21:57:20 -0400
Cc: [email-masked], Yakov Shafranovich <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed May 25 2005 18:32, [email-masked] wrote:
> In any case, I agree that these are not
> header fields and hence do not belong in the regular header field
> registry.

Discussion with Graham back when the registry documents were still
in draft form seemed to indicate that it would be reasonable. The
use could be indicated via the registration form "applicable protocol"
field.  The benefits would be as listed in RFC 3864:

   Benefits of a central registry for message header field names
   include:

   o  providing a single point of reference for standardized and
      widely-used header field names;

   o  providing a central point of discovery for established header
      fields, and easy location of their defining documents;

   o  discouraging multiple definitions of a header field name for
      different purposes;

   o  helping those proposing new header fields discern established
      trends and conventions, and avoid names that might be confused
      with existing ones;

   o  encouraging convergence of header field name usage across multiple
      applications and protocols.

Technically, of course, these aren't header fields, but sometimes fields
don't stay put (MTAs insert empty lines, moving message fields into the
body, for example).  And they do use the same syntax.

And note that some fields used in types similar to the one proposed in
the draft under discussion are also used in message header fields (e.g.
Original-Message-ID).  Benefits "discouraging multiple definitions
for different purposes", "...discern established trends...", "encouraging
convergence..." all are applicable.  The draft under discussion re.
"User-Agent" is an example.

With three related types already (DSN, MDN, MTSN), and some already
existing common use (e.g. Original-Recipient, Final-Recipient), the
benefits enumerated in 3864 seem clear.

There's also media features (RFC 2530) over MDN and DSN
(Media-Accept-Features).

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Date: Wed, 25 May 2005 20:25:17 -0400
Cc: Yakov Shafranovich <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed May 25 2005 15:26, Yakov Shafranovich wrote:

> There is no current IETF list for this type of stuff. The ietf-822 list 
> is not official at this point. When this spec becomes more mature, I 
> will discuss with the appropriate ADs the best avenue for moving this 
> forward. But for now, there is already a dedicated list for this.

Perhaps, but it rejects messages from non-subscribers.  And the mixed
use of ARF (reminds me of Little Orphan Annie [*]) and A F R (as in
abuse-feedback-report) is confusing.

* http://www.soarmd.org/BassNews/arf.html

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Date: Wed, 25 May 2005 19:50:24 -0400
Cc: Yakov Shafranovich <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Wed May 25 2005 15:26, Yakov Shafranovich wrote:
> 
> Bruce Lilly wrote:
> > 
> > Review of         draft-shafranovich-feedback-report-01      by B. Lilly
> > 
> ...
> 
> > 
> >    [X] The document should probably be split: registration of media
> >        types in the standards tree requires an RFC of any type.
> >        Registration procedures (which should be specified for
> >        registration of extension items) are typically specified in a BCP
> >        RFC.  Specifications with conformance criteria (which should be
> >        explicit) are typically Standards Track RFCs.
> > 
> 
> Can you elaborate as to why the document must be split? For example, RFC 
> 3464 includes the MIME registration in the same document. Why should 
> this document, which is also a child-of-RFC3462 be any different?

Note that I said "probably should", not "must". Note that there are
companion documents to 3464; RFCs 3461-3463. Likewise for the MTRK
documents, RFCs 3885-3888.  One reason to consider separating different
issues is to facilitate progress of the Standards Track part (those that
specify conformance criteria, syntax specifications, etc.).  If you mix
other issues and it becomes necessary to change the document, the status
on the Standards Track may be reset and/or the timer for advancement to
the next stage may be reset.  In particular, registration procedures do
not need the type of phased roll-in used for Standards Track; as long as
the procedure is acceptable to IESG and IANA, it can be a BCP document
and you don't have to worry about it anymore as the syntax etc.
specification gets revised as it progresses along the Standards Track.
 
> > The document suffers from the following serious defects:
> > 
> ...
> > 
> >    [X] missing or inadequate internationalization considerations
> > 
> 
> I am not sure what this is refering to. This is a message intended for 
> machines, not humans, and follows the same conventions as RFC 3462 from 
> which it descends. What internationalization issues have to be discussed?

You should then state that the keywords are case-independent protocol
elements.  See RFC 2277 section 2.
 
> >    [X] incompatible with one or more Internet Standards
> > 
> 
> Can you be more specific? What Internet standards is this document not 
> compatible with, what specific issues are there, etc.?

Specifying HTTP and (to a lesser extent) SMTP syntax for message fields
is incompatible with the message format.  The conflict with RFC 2822
Subject field semantics.  Conflicts between use of MUST and SHOULD re.
RFC 2119.  Missing BCP 90 registrations.  Inadequate security
considerations vs. RFC 2026.  The RFC 2277 issue noted above.  The good
news is that all of those things can be fixed.

> > Specific issues with the draft:
> > 
> ...
> 
> >    o The draft implies that "opt-out" is viable.  It is not, and the
> >      draft will meet some considerable resistance if it does not
> >      distance itself from that spammer-supported concept.  (opt-out is
> >      not viable because there are more than 10 billion potential senders
> >      of unsolicited material (nearly that many individuals, plus a large
> >      number of corporate entites).  Responding to a single message from
> >      each, at 5 seconds per response, working continuously, would take
> >      more than 1,500 years of uninterrupted effort.  How long do you
> >      plan to live, and do you wish to do something other than "opt-out"
> >      of unsolicited messages?)
> > 
> 
> This is a technical standard, not an editorial page. The "opt-out" 
> option is included to be used in feedback loops from ISPs to legit bulk 
> mailers such as SkyList, etc., not a general opt-out mechanism. It is 
> perfectly viable according to the ISPs and the bulk mailers I have 
> spoken to.

I'd expect to hear that from bulk emailers.  ISPs that I've talked to are
opposed to "opt-out" (as distinct from "opt-in").  If you intend for the
mechanism to be distinct from the other uses (only between ISPs and bulk
mailers, in contrast to other uses by individuals, etc. in reporting abuse),
then it's probably best to put it in a separate specification.  Incidentally,
the draft says "To inform email service provides [sic] about opt-out
requests", which sounds different from "from ISPs to [...] bulk mailers".
 
> >    o The draft states "this format is intended specifically for
> >      communications among providers", implying that a mere individual
> >      (not a provider) cannot use it to report abuse to a government
> >      agency (also not a provider), for example.
> > 
> 
> I will change it to read "this format is intended primarly for 
> communications among providers, but can also be used in other 
> situations". Would that be more clear?

It's an improvement, but explicitly listing examples or specifying
particular uses would be better still.  Otherwise you may find a
frequently-asked question "what other situations?".

> >    o The draft states "The first MIME part of the message contains a
> >      human readable description of the report" but does not state
> >      whether or not that part can be a MIME composite type (e.g.
> >      multipart/alternative).  Nor does it provide for (e.g.) an audio
> >      type, which might be appropriate if the recipient is known to be
> >      visually impaired.
> > 
> 
> This is a child-of-RFC3462. Whatever is specified there, applies here. 
> Last time I checked, I did not see any of those options there or in any 
> standards that descend from it such as DSNs and MSG-TRACK.

Well, these are comments on this draft, not on other documents.  It is
unclear from the draft what exactly is permitted.  The first sections
of DSNs, MDNs, and MTSNs are typically machine-generated.  It's unclear
whether you expect that to be the case for the reports described in the
draft under discussion.  If so, it's unclear where they would come from
(DSNs can be generated by MDAs, MDNs by MUAs); in this case a MUA won't
have access to SMTP MAIL FROM, and obviously an MDA or MTA isn't a UA, so
won't have anything to put in "User-Agent"...  If not, then that means
manually generated, and some people might want to provide multiple
formats (e.g. plain text plus formatted text), etc.

> >    o The draft states "it is RECOMMENDED that the entire original email
> >      message be included without any modification" but does not indicate
> >      how such a message containing a virus or other malware can be
> >      successfully conveyed in the presence of filtering (at the sender's
> >      site, in transit, or at the intended recipient's site) without
> >      encryption and/or encoding.
> > 
> 
> This issue was brought up by someone already. One option would be to 
> relay just the headers of the message (an option included in this 
> document). However, the consensus in the discussions that I had with 
> ISPs is that this is something out of scope for this document. Rather, 
> this is an issue for the abuse desks (sender and receiver) to deal with.
> 
> I do not see any other plausible solution short of mucking around with 
> the RFC3462 format and making this even more complicated. Both ISPs and 
> abuse desks have expressed their desire to keep this simple.

Dealing with the issue early is the best way to keep it simple for the
affected parties.  If the specification doesn't deal with the issue,
chances are that there won't be implementations that handle it.  And
users don't generally hand-craft complex MIME messages using
multipart/report -- they rely on implementations to do that.

> >    o The draft states "The subject line of the feedback report SHOULD be
> >      the same as the included email message", which conflicts with the
> >      defined semantics of the Subject field as stated in RFC 2822, viz.
> >      a description of the topic of the message containing it, not a
> >      purported description of a different message.
> > 
> 
> This was included due to the fact that smaller ISPs tend to use the 
> Subject line for manual processing. This is currently the accepted 
> convention and I don't know if mandating anything else will actually 
> accomplish something.
> 
> However, what about prefixing the subject as follows:
> 
> "[FEEDBACK REPORT:] subject"
> ?

See draft-malamud-subject-line-05.  As noted by another reviewer, the
original message Subject is available in the third part.
 
> >    o The draft refers to RFC 2616, which is an HTTP specification that
> >      uses a different field syntax from the Internet Message Format.
> > 
> 
> I did not find any other standard that defines the user agent field. The 
> "User-Agent" and "Mailer" fields used by email programs are not defined 
> in any standard that I was able to locate. Perhaps a new registration or 
> document for the user agent field should be written, OR the syntax 
> copied from RFC 2616 and included in this document in long hand.

HTTP's "separators" differ from RFC 2822's "specials", and there are other
differences (e.g. LWS vs. FWS).  You might want to instead consider
something like RFC 3798 Reporting-UA (though beware that that specification
is ambiguous).  Or maybe something like RFC 3464 Reporting-MTA (since, as
noted above, a UA won't have access to SMTP MAIL FROM).
 
> >    o In several proposed fields, e.g.  "Original-Mail-From:", the draft
> >      makes statements such as "The format of this field is defined in
> >      section 4.1.1.2 of RFC 2821", whereas there is no such definition
> >      of any such fields in the referenced RFCs.
> 
> It is refering to the following:
> 
> "MAIL FROM:" ("<>" / Reverse-Path)
>                         [SP Mail-parameters] CRLF

That's fine for a definition of the SMTP MAIL FROM command syntax, but
it's an SMTP command, not a message field.
 
> Specifically to everything that appears after MAIL FROM. The format is 
> probably the same as Return-Path header, but I wanted to reference the 
> original SMTP transaction directly.

Do you really mean no space or comments after the colon?  That's very
unusual for a structured message field.
 
> >    o The draft seeks to define a media type with multiple fields (but
> >      N.B. not *header* fields in this case), but does not provide enough
> >      detail:
> > 
> >       o Where's the syntax specification for the format?
> > 
> >       o What order should the fields appear in?
> > 
> >       o Is the order significant?
> > 
> >       o May empty lines appear between fields?
> > 
> 
> This is a child-of-RFC3462.

But other documents provide a reasonable specification (e.g.
RFC 3798 section 3, including all subsections).
 
> >       o What about the promised extensibility?
> > 
> 
> There is an extensibility section.

Are there any X- fields (as in 3798 section 3.3)?
 
> >       o Where are the syntax specifications for the fields?
> > 
> 
> Are you refering to ABNF?

ABNF or a similar formal syntax format, including a normative reference to
the formal syntax specification.  ABNF is usually used, as there are
validation tools available (sort of).

> >       o Where are the BCP 90 registration templates for the fields?
> > 
> 
> DNS and message tracking standards do not register their fields with BCP 
> 90 IANA registry. Since this is a similar child-of-RFC3462, I do not see 
> why it should be any different.

BCP 90 (a.k.a. RFC 3864) came after DNS and MDN specifications, and MTSN
was already in the queue when BCP 90 went into effect.  Your specification
comes after BCP 90.  Congratulations! You get to register fields (just as
RFC 4021 did, and a number of current drafts do).
 
> >    o The media type registration form doesn't say anything about a
> >      charset parameter, or about required charsets.  Can I send such a
> >      report in EBCDIC?
> > 
> 
> This is a child-of-RFC3462, everything that applies there applies here 
> as well (only 7bit ASCII).

It would help to say so.
 
> >    o The draft proposes establishing an IANA registry for header fields
> >      (actually fields which do not appear in a header).  There is
> >      already such a registry and corresponding registration procedure as
> >      established by BCP 90.  That mechanism could be used by extending
> >      BCP 90 in small ways to accommodate specifying applicability of
> >      fields to the defined media type proposed in the draft.
> > 
> 
> See above comment re BCP 90 (and take a look at the DSN and MSGTRACK 
> stuff as well).

Commented on above. 

> >    o There is no mention of architectural or internationalization
> >      considerations w.r.t. keywords.  Are keywords case-independent
> >      protocol elements or text?  Is it OK to use "Feedback-Type:
> >      Betrug"?
> > 
> 
> Are you refering to the feedback-type keywords?

Yes.  See the comments about RFC 2277 above.
 
> >    o The draft provides a catch-all "other - any other feedback that
> >      doesn't fit into other types".  How does one distinguish a
> >      subsequent extension from "other" (hint: only register types that
> >      have a specific definition)?
> > 
> 
> Other specifically refers to a case where the abuse reporter DOES NOT 
> want to specific a specific feedback type and leave that task for the 
> receiver.

Wouldn't it be simpler and less confusing to make the Feedback-Type field
optional?  Then a reporter can simply leave out the field if none of the
registered values apply.

> >    o There is provision for one specific type of malware -- "virus", but
> >      not other types (worms, dialers, keystroke loggers, logic bombs,
> >      etc.).  The Security Glossary FYI may be a useful reference.
> > 
> 
> I assumed that it includes all malware.

You might want to pick a more general term.  Or define more keywords to
cover the other cases.

> >    o The Security considerations section is completely unacceptable.
> > 
> 
> Obviously, this is only a draft at this point and has not been sent to 
> the IESG or anyone else for approval just yet. Rather, it is still 
> something that needs work, and specific suggestions would be highly 
> welcome. Blanket statements like the one above are not much helpful - of 
> course I am aware that this section is not finished yet. If you would 
> like to help writing it, I would be very happy.

A starting point would be to review what is specified in DSN, MDN, and
MTSN specifications, and review the guidelines to writing security
considerations sections.  Ultimately it's going to take some careful
thought.
 
> >    o References are normally unnumbered sections.
> > 
> 
> Can you provide a reasoning for this or is this simply something the 
> community is used to?

"Instructions to Requests for Comments (RFC) Authors",
draft-rfc-editor-rfc2223bis-08.txt.  Not a big deal.

> >    o Examples are badly broken.
> > 
> 
> Aside from the various 2822 problems highlited above, how so?

Those are the currently machine-detectable problems.  There seem to be
very many.  The excessively long lines are also a problem for the draft
format.  There may be problems in the examples related to the specified
format and its fields, but without a precise syntax specification, one
cannot build a validator to check that...  In particular, see the "no
space after colon" comment above re. "Original-Mail-From" and compare
to example A.3.

From: [email-masked]
Cc: Bruce Lilly <[email-masked]>, ietf-822 <[email-masked]>, [email-masked], [email-masked]
Date: Wed, 25 May 2005 15:32:45 -0700 (PDT)
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
To: Yakov Shafranovich <[email-masked]>
Sender: [email-masked]

> Bruce Lilly wrote:
> >
> > Review of         draft-shafranovich-feedback-report-01      by B. Lilly
> >
> ...

> >
> >    [X] The document should probably be split: registration of media
> >        types in the standards tree requires an RFC of any type.
> >        Registration procedures (which should be specified for
> >        registration of extension items) are typically specified in a BCP
> >        RFC.  Specifications with conformance criteria (which should be
> >        explicit) are typically Standards Track RFCs.
> >

> Can you elaborate as to why the document must be split? For example, RFC
> 3464 includes the MIME registration in the same document. Why should
> this document, which is also a child-of-RFC3462 be any different?

Registration != registration procedure. IMO it is perfectly reasonable to
include most sorts of registrations in practically any sort of document. There
certainly should not be any blanket prohibition saying, e.g., things cannot be
registered in an experimental specification.

Registration procedures may be another matter. These are administrative
practices, not protocol specifications. As such, they cannot be subjected to
the criteria for advancement along the standards track. (Indeed, the entire
idea of having a single consistent registry is somewhat at odds with the notion
of multiple independent implementations, isn't it?) Experiemental and
informational status are also clearly inappropriate, as neither have strict
enough criteria, and experience has shown that registration procedures need
careful review. BCP status, however, is a pretty good match, good enough that the
more important registration procedures in the IETF have been been published as
separate BCPs.

OTOH, having a separate document for a simple, rarely used registration
mechanism is overkill. So including such procedures in a standards-track
document is allowed, if not actually encouraged. See RFC 3464 for one such
example.

This document contains both registration procedures (for feedback types and
extension fields) as well as a media type registration. The latter clearly do
not require a separate document, the former are IMO simple enough that a
separate document isn't needed. I would suggest, however, that you check out
RFC 3464 and adopt the approach it uses for setting up the registries.

I also note that RFC 3462 is not an appropriate example since it only contains
registrations, not new registration procedures. (In fact it cleverly avoids
creating a separate registry for report types by piggybacking report types on
top of a MIME registration for the report format.)

> > The document suffers from the following serious defects:
> >
> ...
> >
> >    [X] missing or inadequate internationalization considerations
> >

> I am not sure what this is refering to. This is a message intended for
> machines, not humans, and follows the same conventions as RFC 3462 from
> which it descends. What internationalization issues have to be discussed?

The draft specifically talks about the format having human readable parts.
OTOH, it is unclear to me what needs to be said about internationalizing such
text.

> >    [X] incompatible with one or more Internet Standards
> >

> Can you be more specific? What Internet standards is this document not
> compatible with, what specific issues are there, etc.?

> >
> > Specific issues with the draft:
> >
> ...

> >    o The draft implies that "opt-out" is viable.  It is not, and the
> >      draft will meet some considerable resistance if it does not
> >      distance itself from that spammer-supported concept.  (opt-out is
> >      not viable because there are more than 10 billion potential senders
> >      of unsolicited material (nearly that many individuals, plus a large
> >      number of corporate entites).  Responding to a single message from
> >      each, at 5 seconds per response, working continuously, would take
> >      more than 1,500 years of uninterrupted effort.  How long do you
> >      plan to live, and do you wish to do something other than "opt-out"
> >      of unsolicited messages?)
> >

> This is a technical standard, not an editorial page. The "opt-out"
> option is included to be used in feedback loops from ISPs to legit bulk
> mailers such as SkyList, etc., not a general opt-out mechanism. It is
> perfectly viable according to the ISPs and the bulk mailers I have
> spoken to.

I concur.

> >    o The draft states "this format is intended specifically for
> >      communications among providers", implying that a mere individual
> >      (not a provider) cannot use it to report abuse to a government
> >      agency (also not a provider), for example.
> >

> I will change it to read "this format is intended primarly for
> communications among providers, but can also be used in other
> situations". Would that be more clear?

Seems like a reaonable change to me.

> >    o The draft states "The first MIME part of the message contains a
> >      human readable description of the report" but does not state
> >      whether or not that part can be a MIME composite type (e.g.
> >      multipart/alternative).  Nor does it provide for (e.g.) an audio
> >      type, which might be appropriate if the recipient is known to be
> >      visually impaired.
> >

> This is a child-of-RFC3462. Whatever is specified there, applies here.
> Last time I checked, I did not see any of those options there or in any
> standards that descend from it such as DSNs and MSG-TRACK.

The use of multipart/alternative as the first part of a report was discussed at
length during the design of RFC 1892 (now RFC 3462). AFAIK no agreement was
ever reached to describe such usage. OTOH, no agrement was reach to ban such
usage either.

We've suported the use of multpart/alternative in the first part of both DSNs
and MDNs for quite a while now. AFAIK nobody ever uses the capability. Given
that this usage is far more targetted than the use of DSNs and MDNs is, I
cannot see this being a problem.

> >    o The draft states "it is RECOMMENDED that the entire original email
> >      message be included without any modification" but does not indicate
> >      how such a message containing a virus or other malware can be
> >      successfully conveyed in the presence of filtering (at the sender's
> >      site, in transit, or at the intended recipient's site) without
> >      encryption and/or encoding.

> This issue was brought up by someone already. One option would be to
> relay just the headers of the message (an option included in this
> document). However, the consensus in the discussions that I had with
> ISPs is that this is something out of scope for this document. Rather,
> this is an issue for the abuse desks (sender and receiver) to deal with.

You need to describe the issue at least, because people won't think about it
and will end up with the notifications getting caught in some filter somewhere.
(I only wish I wasn't speaking from experience here.)

> I do not see any other plausible solution short of mucking around with
> the RFC3462 format and making this even more complicated. Both ISPs and
> abuse desks have expressed their desire to keep this simple.

Agreed.

> >    o The draft states "The subject line of the feedback report SHOULD be
> >      the same as the included email message", which conflicts with the
> >      defined semantics of the Subject field as stated in RFC 2822, viz.
> >      a description of the topic of the message containing it, not a
> >      purported description of a different message.

> This was included due to the fact that smaller ISPs tend to use the
> Subject line for manual processing. This is currently the accepted
> convention and I don't know if mandating anything else will actually
> accomplish something.

> However, what about prefixing the subject as follows:

> "[FEEDBACK REPORT:] subject"
> ?

Seems like a reasonable compromise to me. This is already done routinely
with DSNs and MDNs.

> >    o The draft refers to RFC 2616, which is an HTTP specification that
> >      uses a different field syntax from the Internet Message Format.

> I did not find any other standard that defines the user agent field. The
> "User-Agent" and "Mailer" fields used by email programs are not defined
> in any standard that I was able to locate. Perhaps a new registration or
> document for the user agent field should be written, OR the syntax
> copied from RFC 2616 and included in this document in long hand.

Probably best to copy it rather than reference HTTP.

> >    o In several proposed fields, e.g.  "Original-Mail-From:", the draft
> >      makes statements such as "The format of this field is defined in
> >      section 4.1.1.2 of RFC 2821", whereas there is no such definition
> >      of any such fields in the referenced RFCs.

> It is refering to the following:

> "MAIL FROM:" ("<>" / Reverse-Path)
>                         [SP Mail-parameters] CRLF

> Specifically to everything that appears after MAIL FROM. The format is
> probably the same as Return-Path header, but I wanted to reference the
> original SMTP transaction directly.

Then you need to make it clear you are importing a definition from a different
sort of protocol field.

> >    o The draft seeks to define a media type with multiple fields (but
> >      N.B. not *header* fields in this case), but does not provide enough
> >      detail:

> >       o Where's the syntax specification for the format?

> >       o What order should the fields appear in?

> >       o Is the order significant?

> >       o May empty lines appear between fields?

> This is a child-of-RFC3462.

Which doesn't define the format of the report part. You'd need to refer to RFC
3464 and its definition of message/delivery-status for this, assuming that you
actually want a report format with one block of stuff for the message and a
separate block for each recipient. (It isn't clear to me whether you want this
or not - the only field you defined that's per-recipient is original-rcpt-to.
Yet you say this field can only appear once...) Things can be simplified
considerably if there's only one block of information in the second part.

> >       o What about the promised extensibility?
> >

> There is an extensibility section.

That may be the intent, but absent a specification of the report format it is
hard to know if the field list is open-ended or not.

> >       o Where are the syntax specifications for the fields?
> >

> Are you refering to ABNF?

You currently define all the fields by text referecne to other specifications.
IMO it would be better to have ABNF for them all, importing ABNF productions
from other specifications as needed.

> >       o Where are the BCP 90 registration templates for the fields?

> DNS and message tracking standards do not register their fields with BCP
> 90 IANA registry. Since this is a similar child-of-RFC3462, I do not see
> why it should be any different.

I think you meant DSN, not DNS. In any case, I agree that these are not
header fields and hence do not belong in the regular header field
registry.

> >    o The media type registration form doesn't say anything about a
> >      charset parameter, or about required charsets.  Can I send such a
> >      report in EBCDIC?
> >

> This is a child-of-RFC3462, everything that applies there applies here
> as well (only 7bit ASCII).

Again, RFC 3462 only defineds the report framework, not the report content.
You either need to specify this stuff or refer to RFC 3464.

> >    o The draft provides a catch-all "other - any other feedback that
> >      doesn't fit into other types".  How does one distinguish a
> >      subsequent extension from "other" (hint: only register types that
> >      have a specific definition)?
> >

> Other specifically refers to a case where the abuse reporter DOES NOT
> want to specific a specific feedback type and leave that task for the
> receiver.

Having to infer the intent of the sender seems like a bad idea to me.

> >    o There is provision for one specific type of malware -- "virus", but
> >      not other types (worms, dialers, keystroke loggers, logic bombs,
> >      etc.).  The Security Glossary FYI may be a useful reference.
> >

> I assumed that it includes all malware.

> >    o The Security considerations section is completely unacceptable.

> Obviously, this is only a draft at this point and has not been sent to
> the IESG or anyone else for approval just yet. Rather, it is still
> something that needs work, and specific suggestions would be highly
> welcome. Blanket statements like the one above are not much helpful - of
> course I am aware that this section is not finished yet. If you would
> like to help writing it, I would be very happy.

It is never too soon to start working on your security considerations...

> >    o References are normally unnumbered sections.

> Can you provide a reasoning for this or is this simply something the
> community is used to?

It is what the RFC Editor requires. Adopting the format of the final RFC sooner
rather than later often saves time.

> >    o Discussion venue should be an IETF list for documents intended as
> >      IETF documents.

> There is no current IETF list for this type of stuff. The ietf-822 list
> is not official at this point. When this spec becomes more mature, I
> will discuss with the appropriate ADs the best avenue for moving this
> forward. But for now, there is already a dedicated list for this.

IMO discussing this on ietf-822 is fine. But that's just MO.

				Ned

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 15:43:48 -0500
Lines: 39
Cancel-Lock: sha1:ZkShL5iTkBl/Ikjrn31CzPiomxc=
Sender: [email-masked]

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

> In article <[email-masked]>, wayne
> <[email-masked]> writes
>
>>
>>Ok, I'm not entirely sure what you are saying here.  Let me rephrase
>>it as an example and see if my understanding is right.
>>
>>[...]
>
> I meant a scenario like this
>
>    [email-masked] sends an email to [email-masked]
>
> [...]

Ah, yes, you are correct.  I will fix up the draft to make note of it.

> BTW: whilst I'm being helpful, I'd suggest you the third sentence of the
> introduction:
>
>    While this feature is desirable in some circumstances, it is a major
>    obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam").
>
> and perhaps the next one as well.

I understand your concerns here.  The first half of the sentence,
however, I think is appropriate because there are circumstances when
it is desirable.  The second half of the sentence, and the following
one give justifications why it is not desirable.

Both sentences have been debated far more than I would have imagined
before I became an I-D editor.  The debates, so far, have centered on
things like the definition of "spam" and grammar.  Right now, I think
if I removed them, it would generate more problems for me than leaving
them in.

-wayne

Date: Wed, 25 May 2005 15:26:28 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: Bruce Lilly <[email-masked]>
CC: ietf-822 <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Sender: [email-masked]

Bruce Lilly wrote:
> 
> Review of         draft-shafranovich-feedback-report-01      by B. Lilly
> 
...

> 
>    [X] The document should probably be split: registration of media
>        types in the standards tree requires an RFC of any type.
>        Registration procedures (which should be specified for
>        registration of extension items) are typically specified in a BCP
>        RFC.  Specifications with conformance criteria (which should be
>        explicit) are typically Standards Track RFCs.
> 

Can you elaborate as to why the document must be split? For example, RFC 
3464 includes the MIME registration in the same document. Why should 
this document, which is also a child-of-RFC3462 be any different?

> The document suffers from the following serious defects:
> 
...
> 
>    [X] missing or inadequate internationalization considerations
> 

I am not sure what this is refering to. This is a message intended for 
machines, not humans, and follows the same conventions as RFC 3462 from 
which it descends. What internationalization issues have to be discussed?

>    [X] incompatible with one or more Internet Standards
> 

Can you be more specific? What Internet standards is this document not 
compatible with, what specific issues are there, etc.?

> 
> Specific issues with the draft:
> 
...

>    o The draft implies that "opt-out" is viable.  It is not, and the
>      draft will meet some considerable resistance if it does not
>      distance itself from that spammer-supported concept.  (opt-out is
>      not viable because there are more than 10 billion potential senders
>      of unsolicited material (nearly that many individuals, plus a large
>      number of corporate entites).  Responding to a single message from
>      each, at 5 seconds per response, working continuously, would take
>      more than 1,500 years of uninterrupted effort.  How long do you
>      plan to live, and do you wish to do something other than "opt-out"
>      of unsolicited messages?)
> 

This is a technical standard, not an editorial page. The "opt-out" 
option is included to be used in feedback loops from ISPs to legit bulk 
mailers such as SkyList, etc., not a general opt-out mechanism. It is 
perfectly viable according to the ISPs and the bulk mailers I have 
spoken to.

>    o The draft states "this format is intended specifically for
>      communications among providers", implying that a mere individual
>      (not a provider) cannot use it to report abuse to a government
>      agency (also not a provider), for example.
> 

I will change it to read "this format is intended primarly for 
communications among providers, but can also be used in other 
situations". Would that be more clear?

>    o The draft states "The first MIME part of the message contains a
>      human readable description of the report" but does not state
>      whether or not that part can be a MIME composite type (e.g.
>      multipart/alternative).  Nor does it provide for (e.g.) an audio
>      type, which might be appropriate if the recipient is known to be
>      visually impaired.
> 

This is a child-of-RFC3462. Whatever is specified there, applies here. 
Last time I checked, I did not see any of those options there or in any 
standards that descend from it such as DSNs and MSG-TRACK.

>    o The draft states "it is RECOMMENDED that the entire original email
>      message be included without any modification" but does not indicate
>      how such a message containing a virus or other malware can be
>      successfully conveyed in the presence of filtering (at the sender's
>      site, in transit, or at the intended recipient's site) without
>      encryption and/or encoding.
> 

This issue was brought up by someone already. One option would be to 
relay just the headers of the message (an option included in this 
document). However, the consensus in the discussions that I had with 
ISPs is that this is something out of scope for this document. Rather, 
this is an issue for the abuse desks (sender and receiver) to deal with.

I do not see any other plausible solution short of mucking around with 
the RFC3462 format and making this even more complicated. Both ISPs and 
abuse desks have expressed their desire to keep this simple.

>    o The draft states "The subject line of the feedback report SHOULD be
>      the same as the included email message", which conflicts with the
>      defined semantics of the Subject field as stated in RFC 2822, viz.
>      a description of the topic of the message containing it, not a
>      purported description of a different message.
> 

This was included due to the fact that smaller ISPs tend to use the 
Subject line for manual processing. This is currently the accepted 
convention and I don't know if mandating anything else will actually 
accomplish something.

However, what about prefixing the subject as follows:

"[FEEDBACK REPORT:] subject"
?

> 
>    o The draft refers to RFC 2616, which is an HTTP specification that
>      uses a different field syntax from the Internet Message Format.
> 

I did not find any other standard that defines the user agent field. The 
"User-Agent" and "Mailer" fields used by email programs are not defined 
in any standard that I was able to locate. Perhaps a new registration or 
document for the user agent field should be written, OR the syntax 
copied from RFC 2616 and included in this document in long hand.

> 
>    o In several proposed fields, e.g.  "Original-Mail-From:", the draft
>      makes statements such as "The format of this field is defined in
>      section 4.1.1.2 of RFC 2821", whereas there is no such definition
>      of any such fields in the referenced RFCs.

It is refering to the following:

"MAIL FROM:" ("<>" / Reverse-Path)
                        [SP Mail-parameters] CRLF

Specifically to everything that appears after MAIL FROM. The format is 
probably the same as Return-Path header, but I wanted to reference the 
original SMTP transaction directly.

> 
>    o The draft seeks to define a media type with multiple fields (but
>      N.B. not *header* fields in this case), but does not provide enough
>      detail:
> 
>       o Where's the syntax specification for the format?
> 
>       o What order should the fields appear in?
> 
>       o Is the order significant?
> 
>       o May empty lines appear between fields?
> 

This is a child-of-RFC3462.

>       o What about the promised extensibility?
> 

There is an extensibility section.

>       o Where are the syntax specifications for the fields?
> 

Are you refering to ABNF?

>       o Where are the BCP 90 registration templates for the fields?
> 

DNS and message tracking standards do not register their fields with BCP 
90 IANA registry. Since this is a similar child-of-RFC3462, I do not see 
why it should be any different.

>    o The media type registration form doesn't say anything about a
>      charset parameter, or about required charsets.  Can I send such a
>      report in EBCDIC?
> 

This is a child-of-RFC3462, everything that applies there applies here 
as well (only 7bit ASCII).

> 
>    o The draft proposes establishing an IANA registry for header fields
>      (actually fields which do not appear in a header).  There is
>      already such a registry and corresponding registration procedure as
>      established by BCP 90.  That mechanism could be used by extending
>      BCP 90 in small ways to accommodate specifying applicability of
>      fields to the defined media type proposed in the draft.
> 

See above comment re BCP 90 (and take a look at the DSN and MSGTRACK 
stuff as well).

> 
>    o There is no mention of architectural or internationalization
>      considerations w.r.t. keywords.  Are keywords case-independent
>      protocol elements or text?  Is it OK to use "Feedback-Type:
>      Betrug"?
> 

Are you refering to the feedback-type keywords?

> 
>    o The draft provides a catch-all "other - any other feedback that
>      doesn't fit into other types".  How does one distinguish a
>      subsequent extension from "other" (hint: only register types that
>      have a specific definition)?
> 

Other specifically refers to a case where the abuse reporter DOES NOT 
want to specific a specific feedback type and leave that task for the 
receiver.

>    o There is provision for one specific type of malware -- "virus", but
>      not other types (worms, dialers, keystroke loggers, logic bombs,
>      etc.).  The Security Glossary FYI may be a useful reference.
> 

I assumed that it includes all malware.

>    o The Security considerations section is completely unacceptable.
> 

Obviously, this is only a draft at this point and has not been sent to 
the IESG or anyone else for approval just yet. Rather, it is still 
something that needs work, and specific suggestions would be highly 
welcome. Blanket statements like the one above are not much helpful - of 
course I am aware that this section is not finished yet. If you would 
like to help writing it, I would be very happy.

>    o References are normally unnumbered sections.
> 

Can you provide a reasoning for this or is this simply something the 
community is used to?

>    o Examples are badly broken.
> 

Aside from the various 2822 problems highlited above, how so?

>    o Discussion venue should be an IETF list for documents intended as
>      IETF documents.
> 

There is no current IETF list for this type of stuff. The ietf-822 list 
is not official at this point. When this spec becomes more mature, I 
will discuss with the appropriate ADs the best avenue for moving this 
forward. But for now, there is already a dedicated list for this.

Yakov

Date: Wed, 25 May 2005 14:52:54 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, 25 May 2005, Paul Jakma wrote:

> Given that List-* allows MUAs to now behave differently if list 
> context is detected (typically: mail only list), I'd like a way for 
> originator to affect behaviour of responding MUAs in that context.

> I'll read that thread.

Having done that (partly - still reading), to self-correct:

Ok, seems those MUAs possibly must be /configured/ for list-context - 
rather than deducing it from List-* headers. Doesn't mean an MUA 
couldn't, nor is either behaviour make any external difference.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You will gain money by an immoral action.

Date: Wed, 25 May 2005 13:11:56 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, 24 May 2005, Bruce Lilly wrote:

> Try starting with John Klensin's message "draft-moore-mail-nr-fields-00"
> dated August 26 2004.  The discussion ran until near the end of the year
> under various subject headings.

Ah, yes. Thank you. I'll read through that.

> Different UAs have different sets of reply options, and ones named
> similarly often do different things in different UAs.  Right now
> I'm using Kmail, which has:

> 1. Reply...
> 2. Reply To All
> 3. Reply To Author
> 4. Reply To Mailing List

> along with various "Forward" options.  All options allow editing the
> set of recipients.  Reply To Author is supported by several UAs, and
> allows replies to the author(s) -- as listed in the original message's
> header From field -- overriding Reply-To.

The problem is that with the introduction of List-* header, several 
MUAs now have a "list reply" function, which will only reply to the 
list mailbox. The multiple Reply-To trick doesnt work.

Given that List-* allows MUAs to now behave differently if list 
context is detected (typically: mail only list), I'd like a way for 
originator to affect behaviour of responding MUAs in that context.

I'll read that thread.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Life is divided into the horrible and the miserable.
 		-- Woody Allen, "Annie Hall"

Date: Wed, 25 May 2005 05:11:30 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: [email-masked]
Subject: Comments and objections on MARID-related drafts
Sender: [email-masked]

The following are my comments made to IESG today regarding several 
documents under their review. Majority of these comments are directly 
related to RFC2822 and possible improper use of some mail header fields
(i.e. like Resent- use for automated forwarding and mail lists) so 
discussion of these issues on ietf-822 list seems appropriate.

---------- Forwarded message ----------
Date: Wed, 25 May 2005 04:23:01 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: [email-masked]
Subject: Comments and objections on MARID-related drafts

On Mon, 23 May 2005, Ted Hardie wrote:
> William,
>       The best route for you to send comments is directly
> to the IESG; the reviewers act as a sounding board for us as
> APPs ADs, but they have no independent role.

As suggested by Ted Hardie I'm sending you my comments regarding possible 
incompatibilities and other problems in the MARID-related documents.

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

I. Draft says that SID authorizes the message

Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt

| 4. Decision Model
|
|  Sender ID enables receiving e-mail systems to answer the question:
|  Given an e-mail message, and given an IP address from which it has
|  been (or will be) received, is the SMTP client at that IP address
|  authorized to send that e-mail message?

The above statement is way too wide and is not valid in security terms.
SPF and SID do not tell if the client is authorized to send any kind of
email message. What they do is answer the question on if the client is
authorized to use given address in specific identity of the mail message,
i.e. pass result of SPF lookup on example.com would answer the question on if 
SMTP client is authorized to use address within domain example.com as MAIL FROM 
/ bounce address in the email it is about to send.

For SID the question would be if client is authorized to use address as
part of PRA identity. There is however a wider problem because PRA consists of 
multiple headers and so this identity is very ambiguous.
[Submitter address being one field identity does not have this problem]

None of those statements are the same as saying that somebody is authorized
to send email [any email] message on behalf of somebody else, that would be a 
lot stronger and lot more general assertion.

II. Experimental Draft makes recommendations for entire Internet Email System

Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt

| 7. Implementation Guidance
| |   This section describes the actions that certain members of the
|   Internet e-mail ecosystem must take to be compliant with this
|   specification.

This draft is going for experimental status. It is not appropriate for
it to make recommendations to internet community as a whole, only those
who wish to participate in experiment should be targeted. The entire
section (in fact SID authorization system in general) would require
those who are not participant of the experiment to comply and change
their behavior in order for those who participate to get positive results.

III. Draft makes recommendations to forwarders incompatible with RFC2822

Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt

| 7.2 E-Mail Forwarders
|
|   In order to pass the PRA variant of the test, a program that forwards
|   received mail to other addresses MUST add an appropriate header that
|   contains an e-mail address that it is authorized to use.  Such
|   programs SHOULD use the Resent-From header for this purpose.

The above is is incompatible with the section 3.6.6 of RFC2822:

Ref: http://www.ietf.org/rfc/rfc2822.txt

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

This objection was discussed at MARID and was found to be valid based on the 
answer by Pete Resnick and in subsequent discussion in jabber conference.

Note: Same objection applies to section 7.3 of senderid-core document

IV. Draft uses Resent-* headers for automatic action which is incompatible
     with RFC2822

Ref: http://www.ietf.org/rfc/rfc2822.txt (section 3.6.6):

|   Resent fields are
|   strictly informational.  They MUST NOT be used in the normal
|   processing of replies or other such automatic actions on messages.

I take "automatic action" to include rejection and bouncing of messages and 
http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
recommends when PRA address derived from Resent- header is not authorized
base on corresponding SPF record check, then message is to be rejected
by mail system in automated manner.

V. PRA algorithm fails when message is RFC822 compliant but not RFC2822

Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-pra-01.txt

|  Where messages conform to RFC822 rather than RFC2822, it is possible
|  for the algorithm to give unexpected results.  An RFC822 message
|  should not normally contain more than one set of resent headers;
|  however the placement of those headers is not specified, nor are they
|  required to be contiguous.  It is hence possible that the Resent-From
|  header will be selected even though a Resent-Sender header is present. | 
Such cases are expected to be rare or non-existent in practice

The problem is acknowledged in the draft, however I'm uncertain that it
should be ignored quite so easily. Consider this also as one more reason
why use of Resent- headers as specified in this draft is bad idea in general.

VI. Zonecuts

Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt

|   If the PRA version of the test is being performed and no records
|   remain, the requirement in [SPF] to find the Zone Cut and repeat the
|   above steps is OPTIONAL.

Zonecut use has been removed fron spf draft because the use maybe dangerous
and lead to incorrectly targeted dns queries. It is still, however, present
in senderid-core-01 draft.

VII. Use of v=spf1 for SenderID PRA identity checking is not appropriate

Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt

|   Sender ID implementations
|   SHOULD interpret the version prefix "v=spf1" as equivalent to
|   "spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists.

The existing v=spf1 records have been published exclusively by those who have 
participated in SPF experiment for checking of SMTP2821 MAIL FROM
identity (MFROM scope). The senderid-core-01 draft would make them 
automatically participating in another experiment (that they may not
have agreed with) and subject to PRA test which may not lead to the
same results and may cause email rejection where otherwise there would
not have been.

VIII. SUBMITTER is required to be equal to PRA

Ref: http://www.ietf.org/internet-drafts/draft-katz-submitter-01.txt

| SMTP clients MUST set the SUBMITTER parameter value to the purported
| responsible address of the message as defined in [PRA].  This also
| applies to messages containing a null reverse-path.

While this is not a technical standard non-compliance objection, I do not
believe it is in the best interest of email community to require SUBMITTER
to have to be equal to PRA. Submitter has a value in itself as way to identify 
during SMTP session address of the person responsible for email
transmission on the SMTP client network but I'm not certain the address
(which is hop-specific) must necessarily be included and indicated in
message headers. This is like EHLO name - we do not after-all have
message header field that corresponds to EHLO name and if somebody
proposed it, that would be considered pretty stupid idea (since its
so hop-specific) but we do have Received trace headers and those
headers record per-hop specific EHLO name. I believe something like
that is better for SUBMITTER because it shares similarities with
EHLO (the difference is that EHLO is server-name specific data where
as SUBMITTER is network-specific and does not have to correspond to
that specific server and maybe name or address of person associated
with that network responsible for transmission at that specific hop).

IX. SPF uses TXT too much

Ref: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt

SPF system is relying too much on TXT records which are general records
not purposed for it (plus use of TXT records directly in the root of domain 
tree is also likely to lead to collisions). While draft calls for assignment of 
new SPF dns record type, I believe that not enough effort is made in the draft 
text to explain to new users that once it becomes EXPERIMENTAL RFC it would be 
its goal to move to using this new record type as soon as possible. Some of 
what could be done is specific note about this and that use of SPF record type 
is always preferable to use of TXT as well as changing examples to use "SPF" 
instead of "TXT".

X. PRA and SID change semantics of Sender identity

I've done some research on this issue and came to the conclusion that
neither path authentication (like SPF) nor cryptographic mail signatures
(like DK) can work on their own to protect email system because of the
way current email architecture is setup [SPF fails with forwarding and crypto 
fails with mail lists]. Either we need to change email architecture (which cant 
be done quickly) or we'll need to use more then one authorization
system to compensate in case of failure of another and further research
showed that the only way more then one authorization system can work without 
being exploited is if different authorization systems work
with same identity.

The most important identity to protect is From/Sender header (From
used if Sender is not present) as that is what is abused with phishing
and that is in fact claimed to be focus of SID as well, but instead of 
protecting Sender, SID invents new identity which sometimes corresponds
to email sender and sometimes to recipient (remember that forwarders act on 
behalf of recipient not on behalf of the email sender). This changing and 
unpredictable nature of PRA makes it impossible to be used in
conjunction with other methods and wider use of PRA may in fact
undermine those efforts by changing nature of Sender identity.

Note, that I'm not against checking RFC2822 From/Sender header fields
with path authentication such as SPF - I think its great way to help
whitelist known good email, but it'll never on its own be good enough
to actually reject bad messages and the same is true about PRA except
that unlike doing strict Sender authorization, its results are less
predictable and in process the actual system violates RFC2822.

I'll publish web paper on this issue within next 15-30 days on ASRG for those 
of you who follow that list, you might be interest that research.

XI. Some drafts use trademarked SenderID name

Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
      http://www.ietf.org/internet-drafts/draft-lyon-senderid-pra-01.txt
      http://www.ietf.org/internet-drafts/draft-katz-submitter-01.txt

Despite a clear not recommended warning about it from MARID WG chair at:
  http://www.imc.org/ietf-mxcomp/mail-archive/msg05042.html
the drafts by Microsoft still use "SenderID" name including as name of the 
draft itself and I have yet heard nothing to indicate that permission has been 
granted to IETF from trademark owner to use SenderID name in its
documents. So this may put IETF and ISOC if it approves these documents in the 
dangerous situation and make them liable for damages as well as those who may 
want to use the specification in some parts of the world.

-- 
William Leibzon
Elan Networks
[email-masked]

Date: Wed, 25 May 2005 12:31:37 +0100 (IST)
From: Paul Jakma <[email-masked]>
Reply-To: [email-masked], [email-masked]
To: Charles Lindsey <[email-masked]>
cc: [email-masked]
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, 25 May 2005, Charles Lindsey wrote:

> It was discussed extensively on this list some months back, but 
> died because two people were opposed to the idea (for diametrically 
> opposed reasons), although many people were happy with it in 
> principle.

Well personally I think Mail-Followup-To is problematic.

> For sure, I agree that using Reply-To is a pretty poor substitute for
> doing the job properly.

Yeah, it definitely it is.

> So what it needs is for someone to sit down and write an internet 
> draft for the Mail-Followup-To header. There was a draft published 
> some years ago by Jacob Palme which could form a basis, though it 
> was not quite right as it stood. I would be willing to cooperate in 
> such a venture, but I don't have the resources to edit such a draft 
> at the moment.

I am willing to do whatever it takes to solve this problem.

Slowly but surely MUAs and email list users are changing "reply to 
list" (which is not specified in 822 AIUI, just reply-all) into 
"reply to just the list".

The List-* headers made this possible. We need some header to allow 
include-me-on-list-replies preference to be expressed, just as the 
List-* headers allow MUAs to 'pick' which address is the list 
address.

Personally, I like the Mail-Copies-To idea.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
'Martyrdom' is the only way a person can become famous without ability.
 		-- George Bernard Shaw

To: [email-masked]
Xref: clerew local.mime:4681
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Date: Wed, 25 May 2005 10:26:44 GMT
Lines: 34
Sender: [email-masked]

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

>Hi,

>Is anyone doing work on some kind of header to allow senders to 
>indicate reply preferences (particularly for list mail)?

>There appear to be a variety of implementations now recognising 
>Mail-Followup-To, unfortunately with various incompatible 
>interpretations of it.

It was discussed extensively on this list some months back, but died
because two people were opposed to the idea (for diametrically opposed
reasons), although many people were happy with it in principle.

For sure, I agree that using Reply-To is a pretty poor substitute for
doing the job properly.

So what it needs is for someone to sit down and write an internet draft
for the Mail-Followup-To header. There was a draft published some years
ago by Jacob Palme which could form a basis, though it was not quite right
as it stood. I would be willing to cooperate in such a venture, but I
don't have the resources to edit such a draft at the moment.

-- 
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: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: [email-masked], ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Date: Tue, 24 May 2005 22:01:02 -0400
Sender: [email-masked]

On Tue May 24 2005 20:27, Paul Jakma wrote:

> On Tue, 24 May 2005, Bruce Lilly wrote:
> > This has been discussed in detail some months ago on the ietf-822 list.
> 
> Ah. would you be able to say roughly when? (or what the subject line 
> may have contained?).

Try starting with John Klensin's message "draft-moore-mail-nr-fields-00"
dated August 26 2004.  The discussion ran until near the end of the year
under various subject headings.

> That distinction is possibly far too subtle though. If there is a 
> distinction in how Reply-To should be interpreted between 'reply-all' 
> and 'reply-author' MUA functionality, then for the latter, which of 
> the From or multiple Reply-To mailboxes should a respondent use?
> 
> Would you know the answer, or be able to direct me to it?

Different UAs have different sets of reply options, and ones named
similarly often do different things in different UAs.  Right now
I'm using Kmail, which has:
1. Reply...
2. Reply To All
3. Reply To Author
4. Reply To Mailing List
along with various "Forward" options.  All options allow editing the
set of recipients.  Reply To Author is supported by several UAs, and
allows replies to the author(s) -- as listed in the original message's
header From field -- overriding Reply-To.

Date: Wed, 25 May 2005 02:22:25 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Paul Jakma <[email-masked]>, ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, 25 May 2005, Paul Jakma wrote:

> I'm sceptical the Reply-To approach would work - I think i'll try an 
> experiment and see how it works in practice.

Early results suggest Reply-To is not a good idea: Gnus and 
Thunderbird use Reply-To always (Reply and Reply-all).

The classic "Reply-To considered harmful" argument on list mail 
applies to this usage of Reply-To surely?

(Pine is slightly better, it tends to ask whether the Reply-To should 
be followed).

There's also the problem that the Reply-To isn't transitive. Any 
reply will (likely) be:

From: respondent
To: sender, list

Anyone who replies to /this/ mail on the list likely will reply to 
just respondent and list - indeed, it could just be to the list 
(there's seems to be list netiquette developing of stripping out all 
addresses bar the list. Or MUAs like Mutt use the List-* headers to 
only include list if the "list reply" functionality is used, and also 
copying Mail-Followup-To listed mailboxes - hence why I list that 
problematic header in my mail).

I wonder, if one considers:

- Reply-To is one shot, not transitive through a thread

- Reply-To makes it difficult for people to /not/ reply to the
   Reply-To. (I know the position on this, MUAs should be
   fixed, but..)

- MUAs exist (Mutt, Apple Mail) which offer a "list reply" function,
   some of which use ad-hoc and incompatible ways to allow originators
   to specify their preference for replies to list mail

That it might be time to consider a list-reply-preference type 
header? The "no choice / always Reply-To without question" behaviour 
of many MUAs aspect particularly worries me and makes me wary of 
using it to indicate list-reply preference.. (i've seen what 
happens).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
There are no emotional victims, only volunteers.

Date: Wed, 25 May 2005 01:27:59 +0100 (IST)
From: Paul Jakma <[email-masked]>
Reply-To: Paul Jakma <[email-masked]>, ietf-822 <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi Bruce,

On Tue, 24 May 2005, Bruce Lilly wrote:

> The Reply-To header field will do what you want.  It is specifically
> designed to indicate a list of addresses for responses (RFC 2822):
>
>   When the "Reply-To:" field is present, it
>   indicates the mailbox(es) to which the author of the message suggests
>   that replies be sent.
>
> So, in your case, setting
>  Reply-To: [email-masked], [email-masked]
> would have indicated your stated preference.

Hmm, possibly yes.

> This has been discussed in detail some months ago on the ietf-822 list.

Ah. would you be able to say roughly when? (or what the subject line 
may have contained?).

I have read of short descriptions of the problem, eg:

http://pm-doc.sourceforge.net/pm-tips-body.html#replyto_header

Which refers to the subtle distinction of interpreting Reply-To as 
the direction for a 'full' reply.

That distinction is possibly far too subtle though. If there is a 
distinction in how Reply-To should be interpreted between 'reply-all' 
and 'reply-author' MUA functionality, then for the latter, which of 
the From or multiple Reply-To mailboxes should a respondent use?

Would you know the answer, or be able to direct me to it?

I'm sceptical the Reply-To approach would work - I think i'll try an 
experiment and see how it works in practice.

> For an older description of the field and its uses, see RFC 822 section
> 4.4.3, and note that a mailing list is "text message teleconferencing".

Ah, indeed.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Date: Tue, 24 May 2005 18:01:47 -0400
Cc: Paul Jakma <[email-masked]>
Sender: [email-masked]

On Tue May 24 2005 14:52, Paul Jakma wrote:

> Is anyone doing work on some kind of header to allow senders to 
> indicate reply preferences (particularly for list mail)?
[...]
> It's an absolute mess, one which (as one of the seemingly few people 
> who prefer to receive both list and 'direct' copies on list replies) 
> causes me a lot of pain, as I have no way to indicate my preference 
> in a reliable fashion

The Reply-To header field will do what you want.  It is specifically
designed to indicate a list of addresses for responses (RFC 2822):

   When the "Reply-To:" field is present, it
   indicates the mailbox(es) to which the author of the message suggests
   that replies be sent.

So, in your case, setting
  Reply-To: [email-masked], [email-masked]
would have indicated your stated preference.

This has been discussed in detail some months ago on the ietf-822 list.

For an older description of the field and its uses, see RFC 822 section
4.4.3, and note that a mailing list is "text message teleconferencing".

Date: Tue, 24 May 2005 19:52:09 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: [email-masked]
Subject: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

Is anyone doing work on some kind of header to allow senders to 
indicate reply preferences (particularly for list mail)?

There appear to be a variety of implementations now recognising 
Mail-Followup-To, unfortunately with various incompatible 
interpretations of it.

Also, at least one implementation appears (depending on 
configuration, or the version - i'm not sure) to consider a /lack/ of 
an MFT to mean that the sender of an email being "list-reply" 
deliberately did not insert an MFT and hence does not wish to be 
included in a reply.

Other implementations treat MFT to be the exclusive address to 
follow-up to.

It's an absolute mess, one which (as one of the seemingly few people 
who prefer to receive both list and 'direct' copies on list replies) 
causes me a lot of pain, as I have no way to indicate my preference 
in a reliable fashion and as many people now use MUAs which suppress 
personal copies by default.

The IETF should, IMHO, work on clarifying the matter, be it:

- that MFT will never be standardised and implementations should
   *not* interpret it

or

- Standardise the behaviour of Mail-Followup-To and/or Mail-Copies-To

Anyone have views on this? (In particular, could anyone give me a 
potted history - this apparently comes up regularly, but nothing ever 
seems to make it to standards track..)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Entropy requires no maintenance.
 		-- Markoff Chaney

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Date: Mon, 23 May 2005 13:14:05 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Mon May 23 2005 12:19, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > Spam Spam Spam
> 
> Using your header checker on a reported spam is unnecessary,

The validating message parser was used to point out errors in the
example(s) in the draft under discussion.  You do understand that
it's not a genuine "reported spam"...

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Date:  Mon, 23 May 2005 18:19:38 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 73
Sender: [email-masked]

Bruce Lilly wrote:

> Spam Spam Spam

Using your header checker on a reported spam is unnecessary,
spammers are famous for not playing by the rules, and attempts
to "fix" the header of a reported spam would be a bad idea, as
long as the line lengths are still MIME compatible.  I had some
trouble when I tried to report a spam with more than 4096
characters in the Subject (one line) to fda.gov.

> http://www.rfc-editor.org/pipermail/rfc-interest/2005-January/000235.html

Oops, tnx for info.

> The draft states "The first MIME part of the message
> contains a human readable description of the report" but does
> not state whether or not that part can be a MIME composite
> type (e.g. multipart/alternative).

My own definition of "feedback expected to make it to an abuse
desk" is "they MUST support RfC 2049" (otherwise RFCI, Admin-C,
ICANN WDPRS. nanas, the works, in that order), and especially
message/rfc822 or multipart/digest.

The actual problem / complaint / feedback (like say "abuse@...
submitted to rfc-ignorant.org") is stated in the subject, the
body is the forwarded evidence.

I found that that format has a serious chance to survive.  Of
course all B64 parts replaced by REMOVED, all suspicious file
types like pif in name= values replaced by pif.REMOVED, and
all strings "<iframe " replaced by "<!frame ".  If it's still
bounced I get seriously angry.

> The draft states "it is RECOMMENDED that the entire original
> email message be included without any modification"

Omigod, try this with say abuse@wanadoo.  Or with a 2 MB Nimda.
Or with 50 identical Sober-P, or any unmodified mail worm.  Or
with the mere string "<iframe " in the body.  It's hopeless.

> The draft states "The subject line of the feedback report
> SHOULD be the same as the included email message", which
> conflicts with the defined semantics of the Subject field

Utter dubious, the original spam subjects never make it, and I
need the subject for the problem / complaint / feedback.  They
are contained in the forwarded message/rfc822 part(s).

> Security considerations are supposed to appear before IANA
> considerations [R3.Instruct].

| except that the order shown for the sub-items 7a-7f within
| Body of Memo is generally recommended but not required.

7c security, 7d IANA considerations.  No nitpicking intended, I
don't have it in that order in an I-D, but fortunately it's not
required.

> Discussion venue should be an IETF list for documents
> intended as IETF documents.

There was also an IRTF ASRG list, but it is dead like almost
everything in the IRTF ASRG after MARID was opened and later
closed:  abuse-rep AT asrg.sp.am

>    [X] [R34.Errata]

How about replacing all [X] [Rxx.yyyy] (followed later by the
[Rxx.yyyy]) by just listing the relevant [Rxx.yyyy] ?  Plus an
URL to your complete Rxx list.  It's rather long.  Bye, Frank

To: [email-masked]
Xref: clerew local.mime:4670
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ABNF experts sought for OpenPGP header definition
Date: Mon, 23 May 2005 11:28:49 GMT
Lines: 82
Sender: [email-masked]

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

>Dear all,

>We would like help with improving the ABNF for our OpenPGP mail/news
>header.  The document and some more info is available from
><http://josefsson.org/openpgp-header/>.  FYI, version -01 was just
>submitted.

>The ABNF section currently reads:

>   openpgp   :=  "OpenPGP:" id-or-url /
>                            (openpgp-parameter *(";" openpgp-parameter))
>                            CRLF

>   id-or-url := id / url

>   openpgp-parameter
>              := ("id" "=" id) /
>                 ("url" "=" url) /
>                 parameter   ; See RFC 2045 for definition of parameter.

>This is rather incomplete; for one it doesn't include CFWS at the
>necessary spots.  Further, it doesn't permit quoting, such as:

You have esentially two problems:

A. To establish exactly what the syntax of parameter is.

B. To specify the syntax of openpgp-parameter or whatever.

Regarding A, the syntax of parameter actually now comes from RFC 2231, and
it is not the world's clearest piece of syntax (moreover, it has a bug
documented in the RFC errata). But it is still based on RFC 822 rather
than RFC 2822, and so inherits the RFC 822 folding/comments rules.

So you need to do some handwaving to explain this. Alternatively, you
could recast the whole syntax in RFC 2822 style, but if you do that make
it in the form of an explanation "for convenience" and not normative. The
overall result should be that [CFWS] is allowed at either end, plus on
either side of the '='.

Regarding B, you have two choices:

B1. Give the syntax as you have shown, and then write some more textual
handwaving to explain that it is really more complicated than it looks.

B2. Write the syntax in the following form:

openpgp-parameter = id-param / url-param ; etc. etc.
id-param  = <a <parameter> with attribute "id" and some <id> as its value>
url-param = <a <parameter> with attribute "url" and some <url> as its value>
id        = .....
url       = .....

That makes use of <parameter> as already defined by your handwaving under
A. Maybe the nested '<...>' is not such a good idea, and might be avoided.

And finally, out of kindness to your reader, a NOTE explaining that this
makes quoting available, and even necessary in some cases.

And may I support Frank's suggestion that you should include [FWS] at
suitable places within your syntax for <url>, so that is can be folded
without the necessity of invoking the gibbous multiline conventions from
RFC 2231 (which you should probably then deprecate). That practice is
indeed recommended in RFC 3986 (STD 66), which also recommends enclosing
the complete urls within "<...>".

And, to be very pedantic, it should be <uri> rather than <url>.

-- 
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: Mon, 23 May 2005 16:36:31 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

In article <[email-masked]>, Richard Clayton
<[email-masked]> writes

>BTW: whilst I'm being helpful, I'd suggest you the third sentence of the
>introduction:

<FX: sigh>     /you the/you remove the/

it wasn't that helpful, the way I put it :-(   apologies

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

Date: Mon, 23 May 2005 16:09:38 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

In article <[email-masked]>, wayne
<[email-masked]> writes

>>>   To put it another way, the
>>>   only people who see malicious explanation strings are people whose
>>>   messages claim to be from domains that publish such strings in their
>>>   SPF records.
>>
>> the other people who will see them are people who know nothing of SPF
>> but forward them to a machine that applies SPF to the forwarded email;
>> their MTA will display the SMTP conversation in the DSN generated, which
>> they will receive. Text that was misleading could then mislead :(
>
>
>Ok, I'm not entirely sure what you are saying here.  Let me rephrase
>it as an example and see if my understanding is right.
>
>
>Say [email-masked] sends email to [email-masked] and
>forwarder.org rewrites the MAIL FROM to
>[email-masked], and forwards it on to
>where Bob directed it to go.  

I was specifically assuming that the mail would not be forwarded with
fancy new things like # marks and crypto-tokens...

I meant a scenario like this

   [email-masked] sends an email to [email-masked]

naive.org have never heard of SPF (so who can say who really sent the
email? just trust me, it was probably Alice herself). They accept the
email. However, when they decide where to deliver it they find that they
should forward all of Bob's email automatically to [email-masked]

BigIsp have indeed heard of SPF and take one look at the incoming email
and see that foulmouth.org's policy is very restrictive. They refuse the
email because naive.org is not a suitable place for it to come from. The
MTA at naive.org now generates a DSN, and manages (huzzah!) to deliver
this to Bob (who they know from internal state was "responsible" for the
forwarding and hence is the right person to receive the DSN; forwarding
systems _can_ get this sort of thing right and not back-scatter!)

Bob receives:    We said:       MAIL FROM: [email-masked]
                 they said:     OK
                 we said        RCPT TO: [email-masked]
                 they said:     SPF fail: not handling email for idiots

Bob is one of insulted, confused, and potentially entirely misled. With
some thought I suspect you could do some interesting social engineering
with URLs...

If you're really unhappy about where the DSN goes then consider the
postmaster at naive.org receiving it instead of Bob...

The deep problem here is that you're getting one machine to repeat a
message on behalf of another. This is always risky and arguing that only
the recipient sees it is not really fixing it all that much. Everyone
thought that having badly constructed HTML reflected back to people
wasn't a problem until people discovered "cross-site scripting" :(

>When the email reaches
>[email-masked], it for some reason fails the SPF check and
>the explanation string from forwarder.org is used.  This DSN is then
>sent back to forwarder.org, which returns it to [email-masked].

in a world where forwarding has been souped up maybe it does go back to
Alice ... I rather think your document needs to explain what can happen
in this world as well

BTW: whilst I'm being helpful, I'd suggest you the third sentence of the
introduction:

   While this feature is desirable in some circumstances, it is a major
   obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam").

and perhaps the next one as well.

I think the sentence is unnecessarily contentious and adds nothing to
the rest of the document. You're proposing a scheme to tackle
impersonation, no more no less -- I don't think you need to go out of
your way at all to provoke an argument as to whether it is good for
anything.

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: "ietf-822" <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt
Date: Mon, 23 May 2005 10:29:31 -0400
Sender: [email-masked]

--Boundary-00=_MjekCw8DEJzWand
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Mon May 16 2005 15:38, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: An Extensible Format for Email Feedback Reports
> 	Author(s)	: Y. Shafranovich
> 	Filename	: draft-shafranovich-feedback-report-01.txt
> 	Pages		: 19
> 	Date		: 2005-5-16
> 	
> This document defines an extensible format and MIME type that may be
>    used by network operators to report feedback about received email to
>    other parties.  This format is intended as a machine readable
>    replacement for various existing report formats currently used in
>    Internet email.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-shafranovich-feedback-report-01.txt

This draft probably warrants some discussion on the ietf-822 list.

--Boundary-00=_MjekCw8DEJzWand
Content-Type: text/plain;
  charset="us-ascii";
  name="draft-shafranovich-feedback-report-01-review.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename="draft-shafranovich-feedback-report-01-review.txt"

Review of         draft-shafranovich-feedback-report-01      by B. Lilly

Internet-Drafts and RFCs are required to meet certain criteria:
[R1.Checklist] (see also references in that document), [R2.ID],
[R3.Instruct].  These can be checked by using the "idnits" tool:
[R4.idnits].  That tool noted the following regarding the document:

idnits 1.71 (02 May 2005)

draft-shafranovich-feedback-report-01.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

    Checking conformance with RFC 3978/3979 boilerplate...
    the boilerplate looks good.
  * There are 15 instances of too long lines in the document, the longest
    one being 44 characters in excess of 72.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

    Nothing found here (but these checks does not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:

    None.

    Run idnits with the --verbose option for more detailed information.

The document contains:

   [ ] ABNF [R5.RFC2234]

   [X] Internet message (or fragment)

   Verification tools are available at [R6.verify] and/or [R7.mparse].

   Verification tools yielded the following results (for brevity, only
   one example is shown):

From: <[email-masked]>
Date: Thu, 8 Mar 2005 17:40:36 EDT
X-NG: Thu<- RFC 822 [5.2] prohibits date inconsistency (day-of-week) (Tue)
X-NG: Thu<- RFC 2822 [3.3] prohibits date inconsistency (day-of-week) (Tue)
X-Warning:                   ->EDT RFC 2822 [3.3] prohibits (when generating
 messages) obsolete zone
Subject: FW: Earn money
To: <[email-masked]>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report; boundary="part1_13d.2e68ed54_boundary"
X-Warning: RFC 2822 [2.1.1, 2.3, 3.5] strongly recommends against line length
 > 78 octets (99)
X-Err: RFC 2821 [4.4] requires exactly one field (0 Return-Path)

--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

This is an email abuse report for an email message received from IP 10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT.
For more information about this format please see http://www.mipassoc.org/arf/.

--part1_13d.2e68ed54_boundary
X-Warning: RFC 2822 [2.1.1, 2.3, 3.5] strongly recommends against line length
 > 78 octets (113)
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 0.1

--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline

From: <[email-masked]>
To: <Undisclosed Recipients>
Subject: Earn money
Date: Thu, 02 Sep 2004 12:31:03 -0500

Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
--part1_13d.2e68ed54_boundary--

The formatting of the document needs work. See [R8.formatting] and
[R9.formatting] and
http://www.rfc-editor.org/pipermail/rfc-interest/2005-January/000235.html
.

The (intended) status of the document is:

   [X] Not indicated

   [ ] Experimental

   [ ] Informational

   [ ] Proposed Standard

   [ ] Draft Standard

   [ ] Internet Standard

   [ ] Best Current Practice

   However, the status as defined in [R10.BCP9] should be:

   [ ] Experimental (typically denotes a specification that is part of
       some research or development effort, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [ ] Informational (published for the general information of the
       Internet community, does not represent an Internet community
       consensus or recommendation, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [ ] Proposed Standard (generally stable, has resolved known design
       choices, is believed to be well-understood, has received
       significant community review, appears to enjoy enough community
       interest to be considered valuable, has no known technical
       omissions)

   [ ] Draft Standard (at least two independent and fully interoperable
       implementations from different code bases have been developed,
       sufficient successful operational experience has been obtained,
       unused options and features have been removed, well-understood,
       known to be quite stable both in its semantics and as a basis for
       developing an implementation, must have been Proposed Standard
       for at least six months)

   [ ] Internet Standard (significant implementation and successful
       operational experience has been obtained, characterized by a high
       degree of technical maturity and by a generally held belief that
       the specified protocol or service provides significant benefit to
       the Internet community, must have been Draft Standard for at
       least four months)

   [ ] Historic (A specification that has been superseded by a more
       recent specification or is for any other reason considered to be
       obsolete, must have been Standards Track)

   [ ] Best Current Practice (a way to standardize practices and the
       results of community deliberations, subject to the same basic set
       of procedures as standards track documents, the community's best
       current thinking on a statement of principle or on what is
       believed to be the best way to perform some operations or IETF
       process function, common guidelines for policies and operations
       which are generally different in scope and style from protocol
       standards, not well suited to the phased roll-in nature of the
       three stage standards track and instead generally only make sense
       for full and immediate instantiation)

   [X] The document should probably be split: registration of media
       types in the standards tree requires an RFC of any type.
       Registration procedures (which should be specified for
       registration of extension items) are typically specified in a BCP
       RFC.  Specifications with conformance criteria (which should be
       explicit) are typically Standards Track RFCs.

The document suffers from the following serious defects:

   [X] missing or inadequate security considerations

   [X] missing or inadequate internationalization considerations

   [X] incompatible with one or more Internet Standards

   [X] uses non-standard terminology which may lead to confusion,
       misinterpretation, and loss of interoperability.  Specifically,
       "header" is used where the term "header field" should be used,
       "header field" is used in places where fields in a specific media
       type are being referenced but where that type has no header,
       "content type" is used where the standard term "media type"
       should be used, and the term "address" is used in at least one
       place where the standard term "mailbox" should instead be used.
       Several non-standard terms used are nowhere defined.

   [X] [R11.BCP14] is referenced, but keywords are used inappropriately,
       and/or words which appear to be keywords are nowhere defined

The document could benefit from spell checking and careful proofreading.
A quick check reveals that the following are suspect:

                          sucessful
                          intented
                          encourages
                          is it allow
                          overtime
                          setup
                          can only registered

Specific issues with the draft:

   o The term "feedback" is undefined.  As the stated intent of the
     media type is primarily for reporting email abuse, perhaps "email-
     abuse" should be substituted for "feedback".

   o The draft implies that "opt-out" is viable.  It is not, and the
     draft will meet some considerable resistance if it does not
     distance itself from that spammer-supported concept.  (opt-out is
     not viable because there are more than 10 billion potential senders
     of unsolicited material (nearly that many individuals, plus a large
     number of corporate entites).  Responding to a single message from
     each, at 5 seconds per response, working continuously, would take
     more than 1,500 years of uninterrupted effort.  How long do you
     plan to live, and do you wish to do something other than "opt-out"
     of unsolicited messages?)

   o The draft states "this format is intended specifically for
     communications among providers", implying that a mere individual
     (not a provider) cannot use it to report abuse to a government
     agency (also not a provider), for example.

   o The draft says "seeks to define a standard" and "the actual
     standard is defined in the next sections".  The term standard
     should be avoided when referring to an Internet-Draft [R2.ID].

   o The draft states "The first MIME part of the message contains a
     human readable description of the report" but does not state
     whether or not that part can be a MIME composite type (e.g.
     multipart/alternative).  Nor does it provide for (e.g.) an audio
     type, which might be appropriate if the recipient is known to be
     visually impaired.

   o The term "munge" is used, but is nowhere defined.

   o The draft states "it is RECOMMENDED that the entire original email
     message be included without any modification" but does not indicate
     how such a message containing a virus or other malware can be
     successfully conveyed in the presence of filtering (at the sender's
     site, in transit, or at the intended recipient's site) without
     encryption and/or encoding.

   o The draft states "The subject line of the feedback report SHOULD be
     the same as the included email message", which conflicts with the
     defined semantics of the Subject field as stated in RFC 2822, viz.
     a description of the topic of the message containing it, not a
     purported description of a different message.

   o The draft refers to "formatted according to the ABNF of RFC 822
     [14]"; RFC 822 uses EBNF, not ABNF.  A more appropriate reference
     would be RFCs 2234 (ABNF) and 2822 (Internet Message Format).  Note
     that RFC 822 is listed as being obsoleted by 2822.

   o The draft does not provide any ABNF or suitable formal syntax
     format for defining the fields that it claims to define.  There is
     insufficient information for an implementation.  Indeed, it is not
     possible to thoroughly review the draft proposal in the absence of
     some concrete definitions.

   o The draft refers to RFC 2616, which is an HTTP specification that
     uses a different field syntax from the Internet Message Format.

   o The draft refers to a version number, and specifies "0.1", but:

      o what does it mean?

      o Is it a floating point number, a serial number, etc.?

      o Is it decimal, hexadecimal, octal, or binary?

      o How are versions compared?

      o What is supposed to happen when a generated version is not
        recognized by a receiving implementation?

      o May comments, whitespace, and/or line folding appear within the
        version designation (as with RFC 2045 MIME-Version) or not?  See
        also RFC 2234 section 3.1.

   o In several proposed fields, e.g.  "Original-Mail-From:", the draft
     makes statements such as "The format of this field is defined in
     section 4.1.1.2 of RFC 2821", whereas there is no such definition
     of any such fields in the referenced RFCs.

   o Optional fields are proposed for reporting domain names and for
     reporting URIs.  Many URIs contain domain names, but the draft does
     not specify whether or not domain names appearing in URIs should
     also be reported *as* domain names.

   o The draft seeks to define a media type with multiple fields (but
     N.B. not *header* fields in this case), but does not provide enough
     detail:

      o Where's the syntax specification for the format?

      o What order should the fields appear in?

      o Is the order significant?

      o May empty lines appear between fields?

      o What about the promised extensibility?

      o Where are the syntax specifications for the fields?

      o Where are the BCP 90 registration templates for the fields?

   o The media type registration form doesn't say anything about a
     charset parameter, or about required charsets.  Can I send such a
     report in EBCDIC?

   o The media type registration form says: "Macintosh File Type
     Code(s): none".  MacOS file type codes are 4 characters.  Do you
     mean that the MacOS file type code is the four character sequence
     "none"?

   o The draft proposes establishing an IANA registry for header fields
     (actually fields which do not appear in a header).  There is
     already such a registry and corresponding registration procedure as
     established by BCP 90.  That mechanism could be used by extending
     BCP 90 in small ways to accommodate specifying applicability of
     fields to the defined media type proposed in the draft.

   o The draft uses the capitalized term "REQUIRE", which is not a
     BCP 14 keyword and the meaning of which is not defined in the
     draft.

   o The draft needs to be reviewed for inconsistencies.  For example,
     the media type registration states "implementors MUST ignore any
     fields they do not support", whereas a subsequent section states
     "implementors SHOULD ignore any fields they do not support".  Is it
     a requirement per keyword usage guidelines in BCP 14, or a mere
     recommendation?

   o There is no mention of architectural or internationalization
     considerations w.r.t. keywords.  Are keywords case-independent
     protocol elements or text?  Is it OK to use "Feedback-Type:
     Betrug"?

   o Security considerations are supposed to appear before IANA
     considerations [R3.Instruct].

   o Please don't break a line in the middle of a media type
     designation.

   o "Feedback-Type: any" appears several times, and there does not
     appear to be any registration of "any", which is otherwise
     syntactically valid as a keyword.  The design needs to be carefully
     rethought (hint: define an alternative which is clearly not an
     single keyword, such as "*").  Likewise for "N/A".

   o The term "phishing" appears, but is nowhere defined.

   o The draft provides a catch-all "other - any other feedback that
     doesn't fit into other types".  How does one distinguish a
     subsequent extension from "other" (hint: only register types that
     have a specific definition)?

   o There is provision for one specific type of malware -- "virus", but
     not other types (worms, dialers, keystroke loggers, logic bombs,
     etc.).  The Security Glossary FYI may be a useful reference.

   o The Security considerations section is completely unacceptable.

   o References are normally unnumbered sections.

   o Examples are badly broken.

   o Discussion venue should be an IETF list for documents intended as
     IETF documents.

   o Regarding "outstanding issues" and encoding, beware of the
     restrictions specified in RFC 2045 section 6.4.

Please carefully review the references and resources indicated:

   [X] [R1.Checklist]

   [X] [R2.ID]

   [X] [R3.Instruct]

   [X] [R4.idnits]

   [X] [R5.RFC2234]

   [X] [R6.verify]

   [X] [R7.mparse]

   [X] [R8.formatting]

   [X] [R9.formatting]

   [X] [R10.BCP9]

   [X] [R11.BCP14]

   [X] [R12.FYI18]

   [X] [R13.FYI36]

   [X] [R14.STD11]

   [X] [R15.BCP18]

   [X] [R16.BCP22]

   [X] [R17.BCP26]

   [X] [R18.BCP61]

   [X] [R19.BCP72]

   [X] [R20.BCP82]

   [X] [R21.BCP90]

   [X] [R22.RFC1796]

   [X] [R23.RFC1925]

   [X] [R24.RFC1958]

   [X] [R25.RFC1982]

   [X] [R26.RFC2223]

   [X] [R27.RFC2822]

   [X] [R28.RFC3426]

   [X] [R29.RFC3439]

   [X] [R30.RFC3444]

   [X] [R31.RFC3536]

   [X] [R32.RFC3724]

   [X] [R33.RFC3930]

   [X] [R34.Errata]

   [X] [R35.Fields]

The following applies to the document being reviewed:

   [X] The document seems promising, but needs work.

References:

   [R1.Checklist]  Wijnen, B., "Checklist for Internet-Drafts (IDs)
                   submitted for RFC publication", February 2005,
                   http://www.ietf.org/ID-Checklist.html

   [R2.ID]         Fenner, B., "Guidelines to Authors of
                   Internet-Drafts", March 2005,
                   ftp://ftp.ietf.org/ietf/1id-guidelines.txt

   [R3.Instruct]   Reynolds, J. and R. Braden, "Instructions to Request
                   for Comments (RFC) Authors"
                   (draft-rfc-editor-rfc2223bis-08.txt), July 2004.

   [R4.idnits]     http://ietf.levkowetz.com/tools/idnits/

   [R5.RFC2234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
                   Specifications: ABNF", RFC 2234, November 1997.

   [R6.verify]     TOOLS, "Available Verification Tools",
                   http://tools.ietf.org/verif-tools

   [R7.mparse]     Internet Message Format validating parser,
                   http://users.erols.com/blilly/mparse/index.html

   [R8.formatting] RFC Editor, "Formatting RFCs and Internet Drafts",
                   http://www.rfc-editor.org/formatting.html

   [R9.formatting] Lilly, B., "Writing Internet-Drafts and Requests For
                   Comments using troff and nroff"
                   (draft-lilly-using-troff-04.txt),
                   (draft-lilly-using-troff-04.ps),
                   (draft-lilly-using-troff-04.pdf), May 2005.

   [R10.BCP9]      Bradner, S., "The Internet Standards Process --
                   Revision 3", BCP 9, RFC 2026, October 1996.

   [R11.BCP14]     Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [R12.FYI18]     Malkin, G., "Internet Users' Glossary", RFC 1983,
                   August 1996.

   [R13.FYI36]     Shirey, R., "Internet Security Glossary", RFC 2828,
                   May 2000.

   [R14.STD11]     Crocker, D., "Standard for the format of ARPA
                   Internet text messages", STD 11, RFC 822, August
                   1982.

   [R15.BCP18]     Alvestrand, H., "IETF Policy on Character Sets and
                   Languages", BCP 18, RFC 2277, January 1998.

   [R16.BCP22]     Scott, G., "Guide for Internet Standards Writers",
                   BCP 22, RFC 2360, June 1998.

   [R17.BCP26]     Narten, T. and H. Alvestrand, "Guidelines for Writing
                   an IANA Considerations Section in RFCs", BCP 26,
                   RFC 2434, October 1998.

   [R18.BCP61]     Schiller, J., "Strong Security Requirements for
                   Internet Engineering Task Force Standard Protocols",
                   BCP 61, RFC 3365, August 2002.

   [R19.BCP72]     Rescorla, E. and B. Korver, "Guidelines for Writing
                   RFC Text on Security Considerations", BCP 72,
                   RFC 3552, July 2003.

   [R20.BCP82]     Narten, T., "Assigning Experimental and Testing
                   Numbers Considered Useful", BCP 82, RFC 3692, January
                   2004.

   [R21.BCP90]     Klyne, G., Nottingham, M., and J. Mogul,
                   "Registration Procedures for Message Header Fields",
                   BCP 90, RFC 3864, September 2004.

   [R22.RFC1796]   Huitema, C., Postel, J., and S. Crocker, "Not All
                   RFCs are Standards", RFC 1796, April 1995.

   [R23.RFC1925]   Callon, R., "The Twelve Networking Truths", RFC 1925,
                   April 1996.

   [R24.RFC1958]   Carpenter, B., "Architectural Principles of the
                   Internet", RFC 1958, June 1996.

   [R25.RFC1982]   Elz, R. and R. Bush, "Serial Number Arithmetic",
                   RFC 1982, August 1996.

   [R26.RFC2223]   Postel, J. and J. Reynolds, "Instructions to RFC
                   Authors", RFC 2223, October 1997.

   [R27.RFC2822]   Resnick, P., "Internet Message Format", RFC 2822,
                   April 2001.

   [R28.RFC3426]   Floyd, S., "General Architectural and Policy
                   Considerations", RFC 3426, November 2002.

   [R29.RFC3439]   Bush, R. and D. Meyer, "Some Internet Architectural
                   Guidelines and Philosophy", RFC 3439, December 2002.

   [R30.RFC3444]   Pras, A. and J. Schoenwaelder, "On the Difference
                   between Information Models and Data Models",
                   RFC 3444, January 2003.

   [R31.RFC3536]   Hoffman, P., "Terminology Used in
                   Internationalization in the IETF", RFC 3536, May
                   2003.

   [R32.RFC3724]   Kempf, J., Austein, R., and IAB, "The Rise of the
                   Middle and the Future of End-to-End: Reflections on
                   the Evolution of the Internet Architecture",
                   RFC 3724, March 2004.

   [R33.RFC3930]   Eastlake 3rd, D., "The Protocol versus Document
                   Points of View in Computer Protocols", RFC 3930,
                   October 2004.

   [R34.Errata]    RFC-Editor errata page,
                   http://www.rfc-editor.org/errata.html

   [R35.Fields]    Lilly, B., "Implementer-friendly Specification of
                   Message and MIME-Part Header Fields and Field
                   Components" (draft-lilly-field-specification-03.txt),
                   May 2005.

Reviewer's Address

   Bruce Lilly

   Email: [email-masked]

--Boundary-00=_MjekCw8DEJzWand--

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Sun, 22 May 2005 13:02:27 -0500
Lines: 97
Cancel-Lock: sha1:9O05wZDjm1hMNZjCkY2tpHIA67w=
Sender: [email-masked]

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

> In article <[email-masked]>, wayne
> <[email-masked]> writes
>
>>There is a new I-D for the SPF email anti-forgery system available for
>>review.  This draft tries to document the current practices of the
>>~1,000,000[1] published SPF records and ~10,000[1] deployed SPF
>>systems that are checking 20-100million emails per day.
>
> not that I'm not impressed, but this isn't a huge amount yet :)

As Frank mentioned, these numbers aren't intended to convince people
that SPF is universally used, just that it is used enough that it is
not really experimental or a theoretical system.  I wasn't very clear
on this though.

>>I realize that the whole subject of SPF (and similar systems) has a
>>certain amount of controversy to it, but for the purposes of this
>>draft, I am very reluctant to try debate these issues.  The goal is to
>>document a de-facto standard.
>
> OK .. to be helpful then
>
>>10.5.  Untrusted Information Sources
>>
>>   When the authorization check fails, an explanation string may be
>>   included in the reject response.  Both the sender and the rejecting
>>   receiver need to be aware that the explanation was determined by the
>>   publisher of the SPF record checked and, in general, not the
>>   receiver.  The explanation may contain malicious URLs, or it may be
>>   offensive or misleading.  This is probably less of a concern than it
>>   may initially seem since such messages are returned to the sender,
>>   and the source is the SPF record published by the domain in the
>>   identity claimed by that very sender. 
>
> OR a domain that the check is redirected to

You are correct, there could be more than one record published, but
that really don't change the point that it is the domain owner who
controls this.

I've changed this with:
  s/the SPF record published/the sender policy published/

> assuming I've understood 6.2 correctly. BTW: the note at the end of 6.2
> has the concept "target domain" in it. Uniquely. I suspect this is the
> concept defined in 4.8 that is to be called "<target-name>"

Good catch.  Fixed.  Thanks.

>>   To put it another way, the
>>   only people who see malicious explanation strings are people whose
>>   messages claim to be from domains that publish such strings in their
>>   SPF records.
>
> the other people who will see them are people who know nothing of SPF
> but forward them to a machine that applies SPF to the forwarded email;
> their MTA will display the SMTP conversation in the DSN generated, which
> they will receive. Text that was misleading could then mislead :(

Ok, I'm not entirely sure what you are saying here.  Let me rephrase
it as an example and see if my understanding is right.

Say [email-masked] sends email to [email-masked] and
forwarder.org rewrites the MAIL FROM to
[email-masked], and forwards it on to
where Bob directed it to go.  When the email reaches
[email-masked], it for some reason fails the SPF check and
the explanation string from forwarder.org is used.  This DSN is then
sent back to forwarder.org, which returns it to [email-masked].

In this case, if forwarder.org creates a misleading explanation
string, Alice will see it.

If this is what you are saying then:

* You are correct, the text quoted above is wrong because it isn't
  *only* the folks who use the forwarder.org domain that could see
  it.

* But, if forwarder.org was evil and wanted to create a misleading
  DNS, they wouldn't need SPF explanation strings to do that, so this
  really isn't a security hole or anything.

Please let me know if I'm on target here.  If so, I'll update the text
to correct this.

-wayne

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: ABNF experts sought for OpenPGP header definition
Date: Sat, 21 May 2005 13:14:34 -0400
Cc: Simon Josefsson <[email-masked]>
Sender: [email-masked]

On Fri May 20 2005 15:39, Simon Josefsson wrote:
> 
> Dear all,
> 
> We would like help with improving the ABNF for our OpenPGP mail/news
> header.  The document and some more info is available from
> <http://josefsson.org/openpgp-header/>.  FYI, version -01 was just
> submitted.

Before diving into ABNF, some questions:

1. How does this relate to the openpgp working group?
   http://www.ietf.org/html.charters/openpgp-charter.html

2. Example & question: what's it good for?:
   From: Trust Me <[email-masked]>
   To: undisclosed recipients:;
   Subject: free offer for valued customers
   OpenPGP: DEADBEEF; url=http://www.spammers-r-us.com/key.txt

   Free offer! Click here!
   This isn't spam.  Honest.  You can verify it using PGP!

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: ABNF experts sought for OpenPGP header definition
Date:  Sat, 21 May 2005 10:36:46 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 59
Sender: [email-masked]

Simon Josefsson wrote:

> We would like help with improving the ABNF

Above all bookmark <http://rtg.ietf.org/~fenner/abnf.cgi>

> The various provisions of RFC 2045 apply.

Amended by RfC 2231, you get some pretty obscure stuff with
2231, e.g. parameter names must be unique.  Okay, you have
that already.

>    id-or-url := id / url
>    id        := *HEXDIG

Like zero digits ?

>    url       := absoluteURI  ; Defined in RFC 2396.

Obsoleted by STD 66 (3986).  If you ckeck an RfC number at
<http://www.rfc-editor.org> you get the status + updates.

> for one it doesn't include CFWS at the necessary spots.

Add [CFWS} after the colon, before and after the "=", and
before the CRLF.  Just an idea.  Check out RfC 3834, it's
my favourite example for "how stuff works".

> Further, it doesn't permit quoting, such as:

> OpenPGP: "B565716F"

Do you need / want this ?  How long can it be ?  Less than
998 doesn't need folding, unless it's an encoded word (but
it's not).

> OpenPGP: "http://josefsson.org/key.txt"

Here RfC 2231 won't help you for excessively long URLs.

> OpenPGP: url="http://josefsson.org/key.txt"

Here it could, in theory.  Another observation might help,
an URI never contains any FWS.  Therefore you can insert
folding white space when needed (again for the 998 limit),
and later remove it to get the unfolded URL.

For a pretty simple application see RfC 2017.  Any credits
for every single bit I said here should go to Bruce Lilly
and Bill Fenner (unless I screwed up of course ;-)

See also draft-lilly-field-specification-03

> Suggestions for only partial improvements are appreciated.

Bill proposed a nicer way to import rules:  use prose-val,
as defined in 2234bis.
                      Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Sat, 21 May 2005 10:04:39 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 42
Sender: [email-masked]

Richard Clayton wrote:
 
> not that I'm not impressed, but this isn't a huge amount yet :)

Indeed, but after my own ISP published a SPF FAIL sender policy
more than a year ago, and it wasn't exactly an "early adopter",
the "experimental" phase is now done.

One important point about it, it's a voluntary system.  Unless
they get tons of "backscatter" normal domain owners can ignore
it.  And of course some domains like say aol.com have more mail
users than others.

> ISC says there were 317 million hosts in January

For SPF you'd need a good guess of domains used in mail, and
then add voluntary participants (= victims of backscatter)
plus spammers thinking (incorrectly) that a PASS result helps.

The adoption rate is still a bit diappointing.  It's probably
a side-effect of the MARID disaster with its confusion about
v=spf1 and spf2.0/pra (they are different and incompatible).

And of course the insane hype about SPF as some "FUSSP" died -
in fact that's good, but won't attract clueless masses anymore.

> So << 1% ?  (even less if spammers use SPF, which they do)

The last German rightwing propagada worm (Sober-Q) ignored SPF,
in other words it forged also my vanity host catch-all address
despite of its SPF FAIL.

OTOH this was the first case of "backscatter" (less than 100) I
got in the last eight months.  Sites checking SPF have rejected
this crap with my addresses, and mail worms don't bounce.

The idea is to stop forgeries.  If you see zero percent of spam
with forged addresses ("forged" as defined by SPF, DK, etc.) 
this battle is over.  Don't hold your breath, and of course it
doesn't mean zero spam.
                            Bye, Frank

Date: Fri, 20 May 2005 23:38:38 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

In article <[email-masked]>, wayne
<[email-masked]> writes

>There is a new I-D for the SPF email anti-forgery system available for
>review.  This draft tries to document the current practices of the
>~1,000,000[1] published SPF records and ~10,000[1] deployed SPF
>systems that are checking 20-100million emails per day.

not that I'm not impressed, but this isn't a huge amount yet :)

Domains:
        ISC says there were 317 million hosts in January
        Netcraft says there were 62 million web servers in April
        Name Intelligence says 52 million domains in com/net/org/etc
        and they count 2311 million IP addresses in use
        So 1% ?  (since SPF may be below the second level!)

Mail servers:
        Qmail claimed to have 700,000 sites in October 2001
        and to be the second most popular MTA
            but I can't immediately locate any other claims :( either
            for other MTAs or more recent info for this one 
            amazing how few numbers for this there are out there!
        So < 1% ?

Emails/Day:
        Radicati said in April, 130000 million emails/day sent
        but 2/3 are spam (viz: 40000 million not)
        So << 1% ?  (even less if spammers use SPF, which they do)

>I realize that the whole subject of SPF (and similar systems) has a
>certain amount of controversy to it, but for the purposes of this
>draft, I am very reluctant to try debate these issues.  The goal is to
>document a de-facto standard.

OK .. to be helpful then

>10.5.  Untrusted Information Sources
>
>   When the authorization check fails, an explanation string may be
>   included in the reject response.  Both the sender and the rejecting
>   receiver need to be aware that the explanation was determined by the
>   publisher of the SPF record checked and, in general, not the
>   receiver.  The explanation may contain malicious URLs, or it may be
>   offensive or misleading.  This is probably less of a concern than it
>   may initially seem since such messages are returned to the sender,
>   and the source is the SPF record published by the domain in the
>   identity claimed by that very sender. 

OR a domain that the check is redirected to

assuming I've understood 6.2 correctly. BTW: the note at the end of 6.2
has the concept "target domain" in it. Uniquely. I suspect this is the
concept defined in 4.8 that is to be called "<target-name>"

>   To put it another way, the
>   only people who see malicious explanation strings are people whose
>   messages claim to be from domains that publish such strings in their
>   SPF records.

the other people who will see them are people who know nothing of SPF
but forward them to a machine that applies SPF to the forwarded email;
their MTA will display the SMTP conversation in the DSN generated, which
they will receive. Text that was misleading could then mislead :(

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

To: [email-masked]
From: wayne <[email-masked]>
Subject:  SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Fri, 20 May 2005 15:10:06 -0500
Lines: 49
Cancel-Lock: sha1:iwgvPjls56qbmqov39Kp+8nBOKs=
Sender: [email-masked]

fyi;

There is a new I-D for the SPF email anti-forgery system available for
review.  This draft tries to document the current practices of the
~1,000,000[1] published SPF records and ~10,000[1] deployed SPF
systems that are checking 20-100million emails per day.

See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt

Discussions about this, and previous, drafts have been taking place on
the [email-masked] mailing list.  To subscribe or read
the archives, see http://spf.pobox.com/mailinglist.html

While I have been reading this mailing list for many months and will
note any comments posted here, sending email to the spf-discuss list
or to me personally is probably better than flooding this list.

I realize that the whole subject of SPF (and similar systems) has a
certain amount of controversy to it, but for the purposes of this
draft, I am very reluctant to try debate these issues.  The goal is to
document a de-facto standard.  Debates about better techniques, why
SPF is evil, etc. are probably best discussed on things like the IRTF
ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a
separate thread/subject.

While SPF mostly deals with the [2]821 SMTP level, there are some
[2]822 issues, in particular, the Received-SPF header.  To be quite
honest, this header has kind of been neglected and could use more
refinement than most other parts of the draft.  One thing I just
tracked down (after this I-D was already submitted) was that I don't
specify a CRLF at the end of the header.  Ooops.

My intention is that after a two week review, I will make a "final"
revised draft and ask the IESG to consider it for a Proposed Standard
status. 

-wayne

[1] These numbers are estimates as of earlier this year.  They were
pretty solid back then, and have probably grown since.  I have data
to back them up and they are almost certainly underestimating the real
numbers.

From: Dave Crocker <[email-masked]>
To: ietf-822 <[email-masked]>, ietf-822 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Fri, 20 May 2005 16:08:47 -0400
Subject: Re: ABNF
Sender: [email-masked]

> >  However, like so many ideas, the real question is whether the community
> >  requires it, thereby justifying the effort to invent the solution and
> >  rev the specification.
> >
>  You have missed the point(s):
>  1. As written, parsing ABNF requires arbitrarily-large lookahead
>  2. Because of the ambiguity, a parser which appears to be parsing ABNF
>  (as that is specified) may in fact be parsing a different grammar (one
>  without that ambiguity), and would not be suitable as a fully-conforming
>  implementation for the purpose of advancement of the specification to
>  Draft status.

Well, yes, those sound pretty serious. So serious, that I'm sure there is a 
strong community desire to have changes made.

Unfortunately, I have not noticed community support for your assessment.  So 
the rest of the community does not share your views.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: ABNF experts sought for OpenPGP header definition
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 20 May 2005 21:39:14 +0200
Sender: [email-masked]

Dear all,

We would like help with improving the ABNF for our OpenPGP mail/news
header.  The document and some more info is available from
<http://josefsson.org/openpgp-header/>.  FYI, version -01 was just
submitted.

The ABNF section currently reads:

   This header is of a "structured" type (see section 2.2.2 of RFC
   2822).  In general, the structure consist of one or more parameters,
   each consisting of one attribute and one value.  The terminology and
   format of the header was inspired by MIME [2].  The various
   provisions of RFC 2045 apply.  In particular, the value part of all
   parameters may be quoted; whitespace, foldoing and comments may occur
   in the middle of parameters.  The provisions of MIME [3] also apply;
   in particular it deals with handling parameters of excessive length.
...
   Unrecognized parameters MUST be ignored.  The grammar permit them to
   allow for future extensions.  This header SHOULD NOT appear more than
   once within a message.  A given parameter type (i.e., "id" or "url")
   may appear no more than once.

   openpgp   :=  "OpenPGP:" id-or-url /
                            (openpgp-parameter *(";" openpgp-parameter))
                            CRLF

   id-or-url := id / url

   id        := *HEXDIG

   url       := absoluteURI  ; Defined in RFC 2396.

   openpgp-parameter
              := ("id" "=" id) /
                 ("url" "=" url) /
                 parameter   ; See RFC 2045 for definition of parameter.

This is rather incomplete; for one it doesn't include CFWS at the
necessary spots.  Further, it doesn't permit quoting, such as:

OpenPGP: "B565716F"
OpenPGP: "http://josefsson.org/key.txt"
OpenPGP: url="http://josefsson.org/key.txt"

and maybe more similar items that I'm not familiar with.

How to best formulate the ABNF to be in style with RFC 2822 and MIME?
Suggestions for only partial improvements are appreciated.

Thanks in advance,
Simon

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: ABNF
Date:  Tue, 17 May 2005 08:09:59 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

Charles Lindsey wrote:
 
> If RFC 2234 (or its bis) actually says that a grammar which
> is expressed using other than CRLF to separate its lines is
> non-compliant, then RFC 2234 (or its bis) is a ass.

There's no way to get a single CTL into any valid ABNF, even
an isolated CR or LF is impossible, the only exception is CRLF.

What you locally do is strictly your business and no problem,
as long as it has the same effect as CRLF on a line printer.

> it needs to be fixed

It could be written without defining CR or LF at all.  Maybe
Dave tries this for the future "full standard" incarnation.

                        Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: ABNF
Date: Mon, 16 May 2005 13:33:39 -0400
Cc: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

On Mon May 16 2005 07:23, Charles Lindsey wrote:

> If RFC 2234 (or its bis) actually says that a grammar which is expressed
> using other than CRLF to separate its lines is non-compliant, then RFC
> 2234 (or its bis) is a ass.

The -02 draft says:

           rulelist       =  1*( rule / (*c-wsp c-nl) )

           rule           =  rulename defined-as elements c-nl
                                  ; continues if next line starts
                                  ;  with white space

           rulename       =  ALPHA *(ALPHA / DIGIT / "-")

           defined-as     =  *c-wsp ("=" / "=/") *c-wsp
                                  ; basic rules definition and
                                  ;  incremental alternatives

           elements       =  alternation *c-wsp

           c-wsp          =  WSP / (c-nl WSP)

           c-nl           =  comment / CRLF
                                  ; comment or newline

           comment        =  ";" *(WSP / VCHAR) CRLF
[...]
           CR             =  %x0D
                                  ; carriage return

           CRLF           =  CR LF
                                  ; Internet standard newline
[...]
           LF             =  %x0A

and (elsewhere)

           CRLF        =  %d13.10

There is no question about what it says, that ABNF uses only CRLF line
endings, and that without at least one CR in CRLF somewhere, there is
nothing that can possibly qualify as an ABNF rulelist.

> If the material in question
> should ever find itself being conveyed on some "wire" in accordance with
> IETF protocols, then it had better be a genuine CRLF.

HTTP is a protocol specified in IETF RFC 1945, and it imposes no such condition.
Indeed:

   Media subtypes of the "text" type use CRLF as the text line break
   when in canonical form. However, HTTP allows the transport of text
   media with plain CR or LF alone representing a line break when used
   consistently within the Entity-Body. HTTP applications must accept
   CRLF, bare CR, and bare LF as being representative of a line break in
   text media received via HTTP.

RFC 1945 predates BCP 14, but the meaning of "must" is crystal clear.

> And if I download 
> some RFC containing some ABNF from ietf.org, then it had better arrive
> with genuine CRLFs throughout.

Downloading RFC 1945 via the RFC-Editor's web site search seems appropriate
given the discussion.  Some Ethereal IP capture excerpts:

0040  3a 20 48 54 54 50 2f 31  2e 30 20 33 30 32 20 4d   : HTTP/1 .0 302 M
0050  6f 76 65 64 20 54 65 6d  70 6f 72 61 72 69 6c 79   oved Tem porarily
0060  0d 0a 53 65 72 76 65 72  3a 20 4e 65 74 73 63 61   ..Server : Netsca
0070  70 65 2d 45 6e 74 65 72  70 72 69 73 65 2f 33 2e   pe-Enter prise/3.
0080  36 20 53 50 33 0d 0a 44  61 74 65 3a 20 4d 6f 6e   6 SP3..D ate: Mon
0090  2c 20 31 36 20 4d 61 79  20 32 30 30 35 20 31 36   , 16 May  2005 16
00a0  3a 35 37 3a 33 32 20 47  4d 54 0d 0a 4c 6f 63 61   :57:32 G MT..Loca
00b0  74 69 6f 6e 3a 20 66 74  70 3a 2f 2f 66 74 70 2e   tion: ft p://ftp.
00c0  72 66 63 2d 65 64 69 74  6f 72 2e 6f 72 67 2f 69   rfc-edit or.org/i
00d0  6e 2d 6e 6f 74 65 73 2f  72 66 63 31 39 34 35 2e   n-notes/ rfc1945.
00e0  74 78 74 0d 0a 43 6f 6e  74 65 6e 74 2d 74 79 70   txt..Con tent-typ
00f0  65 3a 20 74 65 78 74 2f  68 74 6d 6c 0d 0a 0d 0a   e: text/ html....

N.B. the HTML served has CRLF... so does the FTP greeting (ftp having been
specified in the referred URI above -- FTP is an IETF Standard protocol
(STD 9)):

0040  49 c4 32 32 30 20 66 74  70 2e 69 73 69 2e 65 64   I.220 ft p.isi.ed
0050  75 20 4e 63 46 54 50 64  20 53 65 72 76 65 72 20   u NcFTPd  Server 
0060  28 66 72 65 65 20 65 64  75 63 61 74 69 6f 6e 61   (free ed ucationa
0070  6c 20 6c 69 63 65 6e 73  65 29 20 72 65 61 64 79   l licens e) ready
0080  2e 0d 0a                                           ...              

but here's the start of the actual RFC 1945 FTP download:

0040  4e 20 0a 0a 0a 0a 0a 0a  4e 65 74 77 6f 72 6b 20   N ...... Network 
0050  57 6f 72 6b 69 6e 67 20  47 72 6f 75 70 20 20 20   Working  Group   
0060  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                    
0070  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                    
0080  20 20 54 2e 20 42 65 72  6e 65 72 73 2d 4c 65 65     T. Ber ners-Lee
0090  0a 52 65 71 75 65 73 74  20 66 6f 72 20 43 6f 6d   .Request  for Com
00a0  6d 65 6e 74 73 3a 20 31  39 34 35 20 20 20 20 20   ments: 1 945     
00b0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                    
00c0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                    
00d0  20 20 4d 49 54 2f 4c 43  53 0a 43 61 74 65 67 6f     MIT/LC S.Catego

No 0x0d anywhere in sight.

> But if I then choose to store it locally 
> using some other convention (e.g. just LF on some UNIX system), then the
> RFC and the ABNF within it do not suddenly become invalid.

The RFC certainly doesn't become invalid.  But there is nothing (N.B. on
the wire as shown above, or) in the stored file that meets the ABNF syntax,
as there is no CR.

> And if RFC 2234 
> (or its bis) is actually trying to say otherwise then it is, as I have
> alread said "a ass", and it needs to be fixed.

We're agreed on that (doesn't happen often, does it?).

From: Dave Crocker <[email-masked]>
To: Charles Lindsey <[email-masked]>, <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Mon, 16 May 2005 09:39:59 -0700
Subject: Re: ABNF
Sender: [email-masked]

>  Clearly, in the real world, "CRLF" is a euphemism for whatever the system
>  concerned uses to distinguish line endings.

the purpose of an interoperability standard is to specify things so that the 
idiosyncrasies of individual systems are not a factor.  that is the reason for 
declaring canonical representations.

people can use "whatever the system concern uses" without bother to 
suffer the cost of standards.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

To: [email-masked]
Xref: clerew local.mime:4658
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ABNF
Date: Mon, 16 May 2005 11:23:57 GMT
Lines: 39
Sender: [email-masked]

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

>That's nice, but it's not the format of I-Ds and RFCs, which is where ABNF
>is used.  Those documents might or might not have CR.  The recent IESG
>statement 
>http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01196.html
>recommends automated validation, and an RFC 2234 (or draft successor)
>parser will reject "ABNF" w/o CR (or, conversely, any "ABNF" parser that
>does not reject content w/o CR is not compliant with 2234 et seq. and
>cannot be used as one of the fully conforming implementations for the
>purpose of advancing the specification to Draft), and is therefore
>useless for validating ABNF in I-Ds and RFCs, since I-Ds and RFCs in the
>IETF and RFC-Editor archives do not have CRs.

If RFC 2234 (or its bis) actually says that a grammar which is expressed
using other than CRLF to separate its lines is non-compliant, then RFC
2234 (or its bis) is a ass.

Clearly, in the real world, "CRLF" is a euphemism for whatever the system
concerned uses to distinguish line endings. If the material in question
should ever find itself being conveyed on some "wire" in accordance with
IETF protocols, then it had better be a genuine CRLF. And if I download
some RFC containing some ABNF from ietf.org, then it had better arrive
with genuine CRLFs throughout. But if I then choose to store it locally
using some other convention (e.g. just LF on some UNIX system), then the
RFC and the ABNF within it do not suddenly become invalid. And if RFC 2234
(or its bis) is actually trying to say otherwise then it is, as I have
alread said "a ass", and it needs to be fixed.

-- 
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]
From: Frank Ellermann <[email-masked]>
Subject:  Re: ABNF, and miscellany
Date:  Sun, 15 May 2005 09:24:45 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Bill Fenner wrote:
 
> The green isn't quite bold enough for single characters like
> parenthesis

It's nice, I tested it with a legacy browser (no CSS) and Lynx.
Very visible with Lynx, for LWSP I get something like this:

Canonical LWSP = *( WSP / _(_ CRLF WSP ) _)_
It's not  LWSP = *( WSP / _(_ CRLF WSP _)_ )

Similar   x = a /     b c (d e) [f g]     / (     h i) j k
Canonical x = a / _(_ b c (d e) [f g] _)_ / ( _(_ h i) j k _)_

But in both cases and your example a = b / c d / e it's clear
where to add the recommended grouping.  Thanks and bye, Frank

Date: Sat, 14 May 2005 10:47:40 -0700
From: Bill Fenner <[email-masked]>
Reply-To: Bill Fenner <[email-masked]>
To: Frank Ellermann <[email-masked]>
Subject: Re: ABNF, and miscellany
Cc: [email-masked]
Sender: [email-masked]

On 5/13/05, Frank Ellermann <[email-masked]> wrote:
> Or maybe you could add it as warning to your parser

I chose to create a "canonical" output format and let the web tool
show the differences between the input and the "canonical" format. 
Try, for example, putting

a = b / c d / e

(is that "(b/c) (d/e)" or "b / (c d) / e"?)

or foo = 3*5[bar]

into http://rtg.ietf.org/~fenner/abnf.cgi

(The green isn't quite bold enough for single characters like parenthesis)

  Bill

Date: Sat, 14 May 2005 19:22:55 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ABNF, and miscellany
Cc: Bruce Lilly <[email-masked]>, Frank Ellermann <[email-masked]>
Sender: [email-masked]

Bruce Lilly writes:
> On Sat May 14 2005 11:28, Frank Ellermann wrote:
>> Blocking port 25 is utter dubious, find a better ISP with an abuse 
>> desk, not spamcast.
>
> You have again missed the point; when in an airport lounge, one cannot 
> "find a better ISP".

Isn't "finding a better ISP" exactly what VPNs do?

Arnt

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: ABNF, and miscellany
Date: Sat, 14 May 2005 13:11:42 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Sat May 14 2005 11:28, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > the issue is sending mail
> 
> Yes, that's possible with Webmail.

Not if it's not available.

> >> You can use the MSA of your provider.
> > Which provider?
> 
> Your mail provider, the one you send and receive mails with.

No MSA (unless they privately consider their server on port 25
to be an MSA rather than MTA -- it's impossible to tell).

> > or that it is accessible (port 25 blocking)?
> 
> Blocking port 25 is utter dubious, find a better ISP with an
> abuse desk, not spamcast.

You have again missed the point; when in an airport lounge, one
cannot "find a better ISP".

> For an MSA you'd use port 587.  See 
> chapter 4 in draft-hutzler-spamops-04:
> 
> | Best practices are:
> | o  MSAs MUST support the SUBMISSION port, for MUAs accessing
> |    from outside the MSA's local environment.

That conflicts with RFC 2476, drafts have no standing, and nobody
is going to enforce such nonsense.

> >> don't publish a "sender policy".
> > Associated with which domain
> 
> All your domains, don't publish a "sender policy" if you don't
> know what it means.  Now that's obvious, isn't it ?

"My" domains have very little to do with sending mail, as viewed
anywhere on the Internet.  Domains which appear in a reverse path
are not "mine"; ditto for ones put in HELO/EHLO by typical MUAs.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: ABNF, and miscellany
Date: Sat, 14 May 2005 11:42:45 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Sat May 14 2005 10:56, Frank Ellermann wrote:

> I've never visited an internet cafe, I've no idea.  In the rare
> cases when I needed something similar I simply used the Webmail
> interface of my mail provider.
> 
> For Bruce's scenario the new 2476bis should do it.  Bye, Frank

No, I suspect that you fail to grasp the nature of the problem.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: ABNF, and miscellany
Date:  Sat, 14 May 2005 17:28:20 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 37
Sender: [email-masked]

Bruce Lilly wrote:

> the issue is sending mail

Yes, that's possible with Webmail.  One of my mail providers
uses "squirrelmail", it's quite nice after I found all places
to disable JavaScript.

>> You can use the MSA of your provider.
> Which provider?

Your mail provider, the one you send and receive mails with.
If you have more than one it's fine, at one time I had six,
now only three (a minimum to bypass DNSBL problems is two).

> Who says that that provider has an MSA

Just ask them, or check their mail FAQ for "roaming".  We're
talking about SMTP, and while some details are hairy it's in
essence still S = Simple.

> or that it is accessible (port 25 blocking)?

Blocking port 25 is utter dubious, find a better ISP with an
abuse desk, not spamcast.  For an MSA you'd use port 587.  See
chapter 4 in draft-hutzler-spamops-04:

| Best practices are:
| o  MSAs MUST support the SUBMISSION port, for MUAs accessing
|    from outside the MSA's local environment.

>> don't publish a "sender policy".
> Associated with which domain

All your domains, don't publish a "sender policy" if you don't
know what it means.  Now that's obvious, isn't it ?  Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: ABNF, and miscellany
Date:  Sat, 14 May 2005 16:56:55 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 13
Sender: [email-masked]

william(at)elan.net wrote:

> Frank, you wanna tell me which airport you've seen that has
> internet kiosk that works like that? Just curious because
> I've used a few of their internet access kiosks and none can
> do it...

I've never visited an internet cafe, I've no idea.  In the rare
cases when I needed something similar I simply used the Webmail
interface of my mail provider.

For Bruce's scenario the new 2476bis should do it.  Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: ABNF, and miscellany
Date: Sat, 14 May 2005 10:32:12 -0400
Cc: "william(at)elan.net" <[email-masked]>
Sender: [email-masked]

On Sat May 14 2005 08:43, william(at)elan.net wrote:
> 
> On Sat, 14 May 2005, Bruce Lilly wrote:

> >> You can use the MSA of your provider.
> >
> > Which provider? The one that I use for *receiving* mail?  Who says
> > that that provider has an MSA (as opposed to an MTA), or that it
> > is accessible (port 25 blocking)?
> 
> How is that related to that draft if it is specifically regarding
> SUBMIT (587),

SUBMIT != port 587. Quoting RFC 2476:

   A site MAY choose to use port 25 for message submission,
   by designating some hosts to be MSAs and others to be MTAs.

> and just in case somebody got the wrong idea that 587 would  
> now be like port 25, the draft says that providers MUST NOT block port 587.

Drafts are not binding, and even if they were, there is no enforcement
arm of the IETF.

Date: Sat, 14 May 2005 05:43:13 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: ABNF, and miscellany
Sender: [email-masked]

On Sat, 14 May 2005, Bruce Lilly wrote:

[ Note: these comments appear to be in regards to draft-hutzler-spamops-04]

>> You can use the MSA of your provider.
>
> Which provider? The one that I use for *receiving* mail?  Who says
> that that provider has an MSA (as opposed to an MTA), or that it
> is accessible (port 25 blocking)?

How is that related to that draft if it is specifically regarding
SUBMIT (587), and just in case somebody got the wrong idea that 587 would 
now be like port 25, the draft says that providers MUST NOT block port 587.

| Frank Ellermann previous wrote:

>> You can even use the airport-smart-host if that beast accepts
>> error messages for what you sent (maybe forwarding it later to
>> you).

Frank, you wanna tell me which airport you've seen that has internet kiosk 
that works like that? Just curious because I've used a few of their 
internet access kiosks and none can do it...

-- 
William Leibzon
Elan Networks
[email-masked]

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: ABNF, and miscellany
Date: Sat, 14 May 2005 08:19:17 -0400
Sender: [email-masked]

On Sat May 14 2005 03:11, Frank Ellermann wrote:

> Bruce Lilly wrote:

> > No, it and many others will do nothing to curtail spam, but
> > will adversely affect legitimate mobile users.
> 
> I disagree.
[...]
> You can use Webmail.

No, the issue is sending mail, not looking at web pages of mangled
messages.

> You can use the MSA of your provider.

Which provider? The one that I use for *receiving* mail?  Who says
that that provider has an MSA (as opposed to an MTA), or that it
is accessible (port 25 blocking)?
 
> You can even use the airport-smart-host if that beast accepts
> error messages for what you sent (maybe forwarding it later to
> you).

Huh?

> If that's not good enough for you I recommend that you 
> don't publish a "sender policy".

Associated with which domain -- the one that an MUA puts in HELO/EHLO --
which comes for the mailbox for *receiving* mail, and which may be
under control of some third party?

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>, Dave Crocker <[email-masked]>
Subject: Re: ABNF
Date: Sat, 14 May 2005 08:11:35 -0400
Sender: [email-masked]

On Wed May 11 2005 22:40, Dave Crocker wrote:

> It's a little worse than that, I think.  The idea of correlating a comment 
> with a particular bit of ABNF strikes me as clever, like so many ideas.
> 
> However, like so many ideas, the real question is whether the community 
> requires it, thereby justifying the effort to invent the solution and rev the 
> specification.  

You have missed the point(s):
1. As written, parsing ABNF requires arbitrarily-large lookahead
2. Because of the ambiguity, a parser which appears to be parsing ABNF
   (as that is specified) may in fact be parsing a different grammar (one
   without that ambiguity), and would not be suitable as a fully-conforming
   implementation for the purpose of advancement of the specification to
   Draft status.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: ABNF
Date: Sat, 14 May 2005 08:06:30 -0400
Cc: [email-masked]
Sender: [email-masked]

On Wed May 11 2005 20:37, [email-masked] wrote:

> > The difference is that Internet Messages and MIME have a canonical form,
> > whereas Internet-Drafts and RFCs are not required to use CR characters
> > (and in fact do not in the IETF/RFC Editor archives).  There are a
> > number of ways to handle this; I've suggested one.  It's just plain
> > silly to require CRLF line endings on ABNF lines in an I-D or RFC whose
> > other lines use only a newline.
> 
> And on the system I use lines are stored as counted strings, padded to an even
> byte. The count can be either big or little endian.

That's nice, but it's not the format of I-Ds and RFCs, which is where ABNF
is used.  Those documents might or might not have CR.  The recent IESG
statement 
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01196.html
recommends automated validation, and an RFC 2234 (or draft successor)
parser will reject "ABNF" w/o CR (or, conversely, any "ABNF" parser that
does not reject content w/o CR is not compliant with 2234 et seq. and
cannot be used as one of the fully conforming implementations for the
purpose of advancing the specification to Draft), and is therefore
useless for validating ABNF in I-Ds and RFCs, since I-Ds and RFCs in the
IETF and RFC-Editor archives do not have CRs.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: ABNF, and miscellany
Date:  Sat, 14 May 2005 09:11:44 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 70
Sender: [email-masked]

Bruce Lilly wrote:

 3*5*1(foo).
> That would be a syntax error.

Weird language, but now I'm warned.

> The rule in this case is in the RFC 2026 requirements for
> advancement to draft, which includes the removal of unused
> features.

Both repetition and optional are useful, only combining these
beasts is odd.  Or rather their priority if I got this finally
right.

> 2234 still permits prose instead of a formal specification.

If it's used to import rules or instead of a "TBD" it's okay.

>>> USEFOR has gone so far down a rathole as to be unsalvageable

>> The last usefor-03 draft was very close to ready from my
>> POV.  Otherwise I intend to salvage at least its msg-id
>> syntax with an "updates: 1036, 2822", if you're interested I
>> can post it here.

> Last I heard, the current and past USEFOR Chairs were adamant
> that the USEFOR WG has no authority to "update" 2822.

Sure, but I've the authority to submit this as I-D if USEFOR is
closed.  And for obvious reasons any USEFOR msg-id will be the
only existing msg-id in practice (= least common denominator).

>> draft-hutzler-spamops-04, a perfectly sane future BCP.

> No, it and many others will do nothing to curtail spam, but
> will adversely affect legitimate mobile users.

I disagree.  SMTP has to be fixed, and it will be fixed.  And
of course strategies like blocking open relays have adversely
affected some legit users, as we've seen it was also no FUSSP.

The important point is that it _can_ be fixed without killing
or replacing SMTP completely.

>> for all host names (FQDNs) under your control you are free
>> to publish which IPs they use if they say HELO in an SMTP
>> session.

> No, because IP addresses are unpredictable

For e.g. xyzzy.dnsalias.org I could say "a" = "whatver its IPs
are when you check it in a SMTP session", or "mx" = "whatever
the IP(s) of its MX(s) are", etc.  As I said, it works like a
charm, and of course the IPs of mailouts are generally static.

> (airport lounges, cafes, etc.).

You can use Webmail.  You can use the MSA of your provider.
You can even use the airport-smart-host if that beast accepts
error messages for what you sent (maybe forwarding it later to
you).  If that's not good enough for you I recommend that you
don't publish a "sender policy".

It's a voluntary system, and obviously you don't get the idea
without 100,000 bounces caused by forgeries => no problem, it's
only important that spammers and the secondary victims get it.

                             Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: ABNF, and miscellany
Date:  Sat, 14 May 2005 06:08:41 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 26
Sender: [email-masked]

Bill Fenner wrote:

 3*5[foo].
> Each [foo] may be empty or may be a foo.  So, you can get
| any number between 0 and 5 by having some empty [foo]s and
> some non-empty [foo]s.

Apparently _this_ is "repetition before optional/grouping" (?)
Often "A op (B)" means "determine B' := (B), then (A op B')"

> If I wanted 0, 3, 4 or 5 foos I think I'd say [3*5foo].

Yes.  Maybe Dave could add Bruce's example, it's fascinating.

Or maybe you could add it as warning to your parser, like old
C compilers "do you mean equality ?".  As an option, I recall
too many "of course I mean equality" curses, and some "oops".

And another warning could catch all "strongly advised to use
grouping" like LWSP.  E.g. in REXX "say 44 / 2 2" says "22 2",
and gawk "print 44 / 2 2" prints "222".  

I'd need "say 44 / (2 || 2)" or "print 44 / (2 2)" to get "2".

                             Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: ABNF, and miscellany
Date: Fri, 13 May 2005 21:35:50 -0400
Sender: [email-masked]

On Fri May 13 2005 01:45, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:

> > e.g. the unused
> >   3*5[foo]
> > construct.  After some thought, you may realize that that's
> > equivalent to *5foo
> 
> I'd expect 0, 3, 4, or 5 foo.  If what you say is true it has
> "a high astonishing factor", one of the taboos in my religion.
[...] 
> You probably interpret "is equivalent to" as "syntactically
> equivalent", everywhere, in all contexts, i.e. 3*5*1(foo).

That would be a syntax error.

> OTOH it says "repetition before optional", and "optional" has
> the same priority as "grouping",  So that's 3, 4, or 5 of an
> optional foo => 0, 3, 4, or 5 foo.  If it ain't broken...

[foo] is equivalent to (has the same meaning as) 0*1foo. 3*5[foo]
is equivalent to [foo][foo][foo][[foo][foo]], which has the same
meaning (matches the same text) as *5foo, i.e. 0, 1, 2, 3, 4, or 5
instances of foo.

> > next thing you know nobody is following the rules.
> 
> BTW, empty rules

The rule in this case is in the RFC 2026 requirements for advancement
to draft, which includes the removal of unused features.

>      atom        =  1*<any CHAR except specials, SPACE and CTLs>
> 
> ...is hard to read, a proper enumeration like atext in RfC 2822
> with the prose as comment is IMHO better.

Note that RFC 2234 still permits prose instead of a formal
specification.

> > USEFOR has gone so far down a rathole as to be unsalvageable
> 
> The last usefor-03 draft was very close to ready from my POV.
> Otherwise I intend to salvage at least its msg-id syntax with an
> "updates: 1036, 2822", if you're interested I can post it here.

Last I heard, the current and past USEFOR Chairs were adamant that
the USEFOR WG has no authority to "update" 2822.
 
> > My, how blithely you wave away other people's real problems. See
> > http://www1.ietf.org/mail-archive/web/asrg/current/msg12017.html
> 
> That was about draft-hutzler-spamops-04, a perfectly sane future
> BCP.

No, it and many others will do nothing to curtail spam, but will
adversely affect legitimate mobile users.

> Of course.  But for all host names (FQDNs) under your control
> you are free to publish which IPs they use if they say HELO in
> an SMTP session.

No, because IP addresses are unpredictable (DHCP, different
access (airport lounges, cafes, etc.).

And there is no way to match the MAIL FROM notification path
domain to an IP address; that domain remains unchanged as a message
is transferred by multiple MATS on its way to its destination,
each of which will have a different IP address.

> > it will inconvenience many legitimate senders.
> 
> That's why it's a voluntary system for those wo really want it.

No, because (as I already mentioned) it conflates sending of mail
with a domain name for receiving mail.

Date: Fri, 13 May 2005 08:51:30 -0700
From: Bill Fenner <[email-masked]>
Reply-To: Bill Fenner <[email-masked]>
To: Frank Ellermann <[email-masked]>
Subject: Re: ABNF, and miscellany
Cc: [email-masked]
Sender: [email-masked]

On 5/12/05, Frank Ellermann <[email-masked]> wrote:
> 
> Bruce Lilly wrote:
> > e.g. the unused
> >   3*5[foo]
> > construct.  After some thought, you may realize that that's
> > equivalent to *5foo
> 
> I'd expect 0, 3, 4, or 5 foo.  If what you say is true it has
> "a high astonishing factor", one of the taboos in my religion.
...
> 
> Same idea for 3*5*1(foo) => 3*5(*1(foo)) => 0, 3, 4, or 5 foo.
> That's what I expected, how do you get *5(foo) ?  I don't see
> 1*2(foo).  But I love syntax puzzles ;-)

Frank,

  I get *5foo too - it's one of the "canonicalizations" that my parser does.

mango% ./bap
a = 3*5[foo]
; foo UNDEFINED
a = *5foo

I think of it this way: you're saying you have between 3 and 5 [foo]s.
 Each [foo] may be empty or may be a foo.  So, you can get any number
between 0 and 3 inclusive by having some empty [foo]s and some
non-empty [foo]s.

If I wanted 0, 3, 4 or 5 foos I think I'd say [3*5foo].

  Bill

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: ABNF, and miscellany
Date:  Fri, 13 May 2005 07:45:31 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 154
Sender: [email-masked]

Bruce Lilly wrote:

> I suspect that they move on to other documents.

Yes, most likely.  And while I didn't study all details in
Bill's nice PDF there was no 2234bis entry.  BTW, noted as
the 2nd PDF I've seen for ages working even on my OS/2 box.

> e.g. the unused
>   3*5[foo]
> construct.  After some thought, you may realize that that's
> equivalent to *5foo

I'd expect 0, 3, 4, or 5 foo.  If what you say is true it has
"a high astonishing factor", one of the taboos in my religion.

You probably interpret "is equivalent to" as "syntactically
equivalent", everywhere, in all contexts, i.e. 3*5*1(foo).

I've no idea how to interpret a hypothetical 3*5*1(foo), it's
a bit like 2^3^2 or 2**3**2, 64 or 512 ?  If in doubt LTR, 64.

Same idea for 3*5*1(foo) => 3*5(*1(foo)) => 0, 3, 4, or 5 foo.
That's what I expected, how do you get *5(foo) ?  I don't see
1*2(foo).  But I love syntax puzzles ;-)

BTW, to fix this, if it's at all a problem, it would be enough
to replace "*1(foo bar)" by "(*1(foo bar))", similar in 3.7.

OTOH it says "repetition before optional", and "optional" has
the same priority as "grouping",  So that's 3, 4, or 5 of an
optional foo => 0, 3, 4, or 5 foo.  If it ain't broken...

> Now nobody is going to exploit ABNF oddities

You mean nobody excluding you and me ?  <gd&r>

> next thing you know nobody is following the rules.

BTW, empty rules, I knew how Keith did it in RfC 3834, another
solution is:  prose-val = "<" *(%x20-3D / %x3F-7E) ">"

Credits to Bill Fenner, I was blind.  But I'm determined that
the drafts I'm interested in follow all rules.  That could be
another problem in your review form, it mixes formal issues
and technical issues.

Of course both kinds are interesting and relevant, but in the
case of say 2368bis it might be better to split it.  OTOH as
long as the author doesn't answer reviews, dito here on this
list his Archived-At I-D => DNP :-(

> Yes, as in RFC 822:
>    CHAR        =  <any ASCII character>

Okay, if it's used to import stuff like RfC 20, but a line...

     atom        =  1*<any CHAR except specials, SPACE and CTLs>

...is hard to read, a proper enumeration like atext in RfC 2822
with the prose as comment is IMHO better.

And in my parallel universe three IESG members MAY overrule you,
see <http://mid.gmane.org/[email-masked]> ;-)

> USEFOR has gone so far down a rathole as to be unsalvageable

The last usefor-03 draft was very close to ready from my POV.
Otherwise I intend to salvage at least its msg-id syntax with an
"updates: 1036, 2822", if you're interested I can post it here.

> "reverse-path which can be used to report errors" (STD 10)

Yes, it "specifies who the mail is from", "a return route (which
may be used to return a message to the sender when an error
occurs with a relayed message)", "contains the source mailbox",
"a reverse source routing list of hosts and source mailbox",
"a source route from the current location of the message to the
originator of the message)".   Finally "send it to the originator
of the undeliverable mail (as indicated by the reverse-path)".

Want more ?  I skipped some less CLEAR "should", but when I said
*_criminal negligence_* about any "bounces-to" I was NOT joking.

> My, how blithely you wave away other people's real problems. See
> http://www1.ietf.org/mail-archive/web/asrg/current/msg12017.html

That was about draft-hutzler-spamops-04, a perfectly sane future
BCP.  The spiritus rector of the "bounces-to" friends is one of
its co-authors, it does nowhere mention a "reverse path".  Let's
discuss this on the SMTP list.

> see JCK's recent message on ietf-smtp.
Earlier:  <http://mid.gmae.org/[email-masked]>

>> HELO FQDN (otherwise "neutral" => forget it, see above).
> Many times not under the control of the sender.

Of course.  But for all host names (FQDNs) under your control
you are free to publish which IPs they use if they say HELO in
an SMTP session.  For more details check the list of authors in
draft-ietf-marid-cvs-csa-02 and draft-ietf-mardid-intro-02

There are many details where STD 10 / RMX fans like me and the
"bounces-to" fans actually agree.

> That won't slow down spam

It certainly slows bounces to innocent bystanders, "my" spammer
got the idea after about four months.  With a V.90 line I know
that there's a difference between zero and 1000 bounces per day.
Not *1000( foo ) but really *1( 1000( foo ))

> it will inconvenience many legitimate senders.

That's why it's a voluntary system for those wo really want it.

> It is widely known that spammers are early adopters of SPF and
> similar wacky schemes.

Yes, it's not voluntary for spammers, they are forced to respect
it if they want to reach their primary victims.  Read:  No more
"bounces to" protected secondary victims (forged reverse paths).

> Several billions of bacteria eat feces; that doesn't make it
> a good idea for all organisms.

I'm not sure about the "voluntary" in your example.

>>  [at the end of 4.1.1.2]
>> | "MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF

> That's nice. And when you make "final delivery", what will you
> put in the Return-Path field?

| notification MUST be sent using a null ("<>") reverse path

Found in 6.1.  Okay, maybe it's not exactly clear.  The STD 10
syntax has the same issue, <mailbox> can't be empty.

>>> have you ever tried to change what your "Mozilla 3.0" uses?

>> Sure.  It assumes that I have an FQDN or get lost.

> I suspect you'll find that it uses the RHS of your mailbox as
> the HELO domain.

AFAIK it uses the output of "hostname.exe" aka gethostame() (?)

Any mail provider expecting 100% accurate FQDNs in the HELO of
his own users (on the "ours" side) will be soon out of business.

                             Bye, Frank

From: Dave Crocker <[email-masked]>
To: ietf-822 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Wed, 11 May 2005 19:40:59 -0700
Subject: Re: ABNF
Sender: [email-masked]

> > >  and you had a concern about being able
> > >  to determine from the grammar what rule a comment is attached to,
> > >
> >  1) that depends on the specific application. 

>  I find none of these at all persuasive.

It's a little worse than that, I think.  The idea of correlating a comment 
with a particular bit of ABNF strikes me as clever, like so many ideas.

However, like so many ideas, the real question is whether the community 
requires it, thereby justifying the effort to invent the solution and rev the 
specification.  

I do not recall anyone else requesting this feature over the 30 year history 
of ABNF.

Perhaps I missed the groundswell of demand for it.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

From: [email-masked]
Cc: ietf-822 <[email-masked]>, [email-masked]
Date: Wed, 11 May 2005 17:37:04 -0700 (PDT)
Subject: Re: ABNF
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On Wed May 11 2005 12:24, [email-masked] wrote:

> > and you had a concern about being able
> > to determine from the grammar what rule a comment is attached to, which I find
> > uninteresting since I reject the notion that comment binding needs to be
> > determinable from the grammar.

> 1) that depends on the specific application. For example, topologically
>    sorting rules in a ruleset -- keeping comments with the correct rules --
>    requires being able to determine which rule (if any) a particular
>    comment belongs to
> 2) in principle, the ABNF grammar shouldn't have such gross ambiguities
> 3) it's difficult to definitively state whether or not a particular
>    implementation of ABNF parsing is fully "interoperable" (a requirement
>    for Draft status) if one implementation does "comment binding"
>    differently from another.  Granted, the Internet won't collapse, but
>    there is a principle involved, and if we're going to ignore it for this
>    specification, then we ought to be even-handed and ignore it for all
>    specifications.

I find none of these at all persuasive.

> > Oh, and then there was the business about line terminators used in stored
> > copies of specifications. This I also find to be of no relevance. It is well
> > understood that local storage conventions vary but CRLF is our chosen canonical
> > form for line terminators. Hopefully we can avoid another round of interminable
> > discussion of this, repeating what happened with the MIME specification over 10
> > years ago.

> The difference is that Internet Messages and MIME have a canonical form,
> whereas Internet-Drafts and RFCs are not required to use CR characters
> (and in fact do not in the IETF/RFC Editor archives).  There are a
> number of ways to handle this; I've suggested one.  It's just plain
> silly to require CRLF line endings on ABNF lines in an I-D or RFC whose
> other lines use only a newline.

And on the system I use lines are stored as counted strings, padded to an even
byte. The count can be either big or little endian. Care to support that as
well? Where does it end?

This is simply silly.

				Ned

Date: Wed, 11 May 2005 16:24:23 -0400
From: Keith Moore <[email-masked]>
To: ietf-822 <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: ABNF, and miscellany
Sender: [email-masked]

> No, there are other problems that were mentioned on rfc-interest
> but not subsequently; e.g. the unused
>   3*5[foo]
> construct.  After some thought, you may realize that that's
> equivalent to *5foo (i.e. the first number is meaningless -- it
> could be anything, and the brackets as well).  Normally when
> advancing a specification to Draft status, unused features are
> removed -- they tend to result in interoperability problems and
> are a ripe source of security exploits.  

Excellent point.  For that matter, it seems like some changes to
mathematical notation are long overdue.  For instance, in the
construct

[0 * (foo + bar)] 

the whole (foo + bar) expression is irrelevant.  It should be 
forbidden to write such constructs.   And yet this bug has been
allowed to persist for several centuries!  Surely this has resulted
in massive failures in engineering and economics, and widespread
misunderstanding in science.

Don't even get me started about dividing by zero, roots of 
negative numbers, etc.  These are products of deranged minds.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: ABNF, and miscellany
Date: Wed, 11 May 2005 15:55:03 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Wed May 11 2005 08:45, Frank Ellermann wrote:

> > The RFC Editor will hold up publication as an RFC until
> > all normative references are published.
> 
> As long as his queue is really a queue it should work.

I'm not certain, but I suspect that the RFC Editor staff doesn't
sit on their collective thumbs when one document hits a roadblock.
Considering that there are documents in the queue dating to 2002
and there are recent documents emerging with assigned RFC numbers,
I suspect that they move on to other documents.

> I've seen your discussions with Dave and Scott on the rfc-
> interests list, and thought that all problems are resolved.

No, there are other problems that were mentioned on rfc-interest
but not subsequently; e.g. the unused
  3*5[foo]
construct.  After some thought, you may realize that that's
equivalent to *5foo (i.e. the first number is meaningless -- it
could be anything, and the brackets as well).  Normally when
advancing a specification to Draft status, unused features are
removed -- they tend to result in interoperability problems and
are a ripe source of security exploits.  Now nobody is going to
exploit ABNF oddities, but if we have a process for advancement
(RFC 2026), and that process calls for removal of unused features,
then we ought to be following that process.  Otherwise, we make
an exception here and another there, and next thing you know
nobody is following the rules.

>  [2045]
> > That's EBNF
> 
> 1*<verbose text> is EBNF ?

Yes, as in RFC 822:
     CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)

> That's a piece of prose in angle 
> brackets.  Yes, I knew the bit about some missing slashes, but
> didn't know that it's another case of "erratum lost in space".

Yep. Found it about a year ago when looking at something to do
with USEFOR (User-Agent, IIRC).  Doesn't really matter now, I
suppose, as USEFOR has gone so far down a rathole as to be
unsalvageable, and its time has run out:
  Apr 05      ReCharter or conclude
 
> > the only domain associated with sending SMTP mail is that 
> > which may be specified in HELO/EHLO, when a domain literal
> > is not used.
> 
> That's one domain, as you say maybe.  The other domain is what
> you find in the reverse path after removing the route and the
> local part.  Somewhere it all started, from the POV of SMTP,
> and that's the responsible party.

No, the path for delivery notifications:
         "reverse-path which can be used to report errors" (STD 10)

> > MUAs are also [E]SMTP clients, and many MUAs do not have the
> > ability to set the name proffered during SMTP sessions.
> 
> MUAs in trouble will find a smart host or an MSA.

My, how blithely you wave away other people's real problems. See
http://www1.ietf.org/mail-archive/web/asrg/current/msg12017.html

> And if they'd say "HELO computer" that corresponds to a result
> "neutral" in the discussed I-D, because "computer" is no FQDN

and therefore illegal -- see JCK's recent message on ietf-smtp.

> > which doesn't work because of DHCP, NAT, multi-homed hosts,
> > and IP-less and/or domain-parked domain names.
> 
> No, that's not the idea.  In any SMTP session the client has
> an IP, logged in the timestamp line.  Sometimes it also has a
> HELO FQDN (otherwise "neutral" => forget it, see above).

Many times not under the control of the sender.

> Caveat, no shortcut, the I-D isn't about IP(client) = IP(FQDN).
> For the draft it's only relevant to find an "authentication
> policy of some kind".  If not found => "neutral" => forget it.
> 
> But if you find this obscure policy it will list permitted IPs,
> and if the SMTP IP of the client is not in this list => gotcha.

That won't slow down spam, but it will inconvenience many
legitimate senders.  It is widely known that spammers are
early adopters of SPF and similar wacky schemes.

> >> There's nothing wrong with this idea.
> > There's plenty wrong with it; it presumes a specific model
> > that simply doesn't apply in many cases.
> 
> It assumes that SMTP and DNS exist, state of the art STD 10 is
> good enough.

It fails to account for legitimate situations as descriped by GEP. 

> > There is absolutely no reason to attempt any sort of
> > "authentication" of a reverse path domain
> 
> Several hundreds of thousands domain owners strongly disagree.

Several billions of bacteria eat feces; that doesn't make it a
good idea for all organisms.
 
> > Moreover, that reverse path can be null
> 
> We had this already, if there is no FQDN, then there is also no
> policy, and the result is "neutral".

And the effect on spammers will also be null.
 
> > even though RFC 2821 fails to provide for that case in its 
> > ABNF.
> 
>  [at the end of 4.1.1.2]
> | "MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF

That's nice. And when you make "final delivery", what will you
put in the Return-Path field? 

> > for example it has an IP address of 123.45.67.89 and it
> > responds to the greeting with HELO [123.45.67.89]
> 
> Very sane, but no FQDN => no policy => "neutral" => forget it.
> 
> You could still reject a domain literal if the IPs don't match,
> but that's your decision and no "sender policy".  And if you
> reject mails you don't need a header field, but an error code.
> 
> > 1) you don't have any "FQDN1"
> 
> xyzzy.dnsalias.org

No, in the example.

So a spammer (or collective of spammers) can register any domain
name with no "policy", or simply use domain literals and spam at
will -- no effect on spammers, big problems for legitimate users.

> > 2) there exists no Standards Track mechanism for "defined the
> >    set of IPs used by his MTAs". Not even an Experimental RFC
> 
> Dozens of I-Ds

Internet-Drafts are not standards.
 
> > have you ever tried to change what your "Mozilla 3.0" uses?
> 
> Sure.  It assumes that I have an FQDN or get lost.

I suspect you'll find that it uses the RHS of your mailbox as
the HELO domain.  Now try taking a laptop with such a client,
with a domain who has a fascist "policy", to an airport courtesy
lounge, an Internet cafe, etc. -- especially one that blocks outbound
port 25 and requires using a local relay.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: ABNF
Date: Wed, 11 May 2005 14:40:01 -0400
Cc: [email-masked]
Sender: [email-masked]

On Wed May 11 2005 12:24, [email-masked] wrote:

> and you had a concern about being able
> to determine from the grammar what rule a comment is attached to, which I find
> uninteresting since I reject the notion that comment binding needs to be
> determinable from the grammar.

1) that depends on the specific application. For example, topologically
   sorting rules in a ruleset -- keeping comments with the correct rules --
   requires being able to determine which rule (if any) a particular
   comment belongs to
2) in principle, the ABNF grammar shouldn't have such gross ambiguities
3) it's difficult to definitively state whether or not a particular
   implementation of ABNF parsing is fully "interoperable" (a requirement
   for Draft status) if one implementation does "comment binding"
   differently from another.  Granted, the Internet won't collapse, but
   there is a principle involved, and if we're going to ignore it for this
   specification, then we ought to be even-handed and ignore it for all
   specifications.

> Oh, and then there was the business about line terminators used in stored
> copies of specifications. This I also find to be of no relevance. It is well
> understood that local storage conventions vary but CRLF is our chosen canonical
> form for line terminators. Hopefully we can avoid another round of interminable
> discussion of this, repeating what happened with the MIME specification over 10
> years ago.

The difference is that Internet Messages and MIME have a canonical form,
whereas Internet-Drafts and RFCs are not required to use CR characters
(and in fact do not in the IETF/RFC Editor archives).  There are a
number of ways to handle this; I've suggested one.  It's just plain
silly to require CRLF line endings on ABNF lines in an I-D or RFC whose
other lines use only a newline.

From: [email-masked]
Cc: ietf-822 <[email-masked]>
Date: Wed, 11 May 2005 09:24:51 -0700 (PDT)
Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On Tue May 10 2005 04:50, Frank Ellermann wrote:
> >
> > Bruce Lilly wrote:
> >
> > >> Scott H. wants us to use the new 2234bis in the References.
> >
> > > A normative reference would hold up publication, as the 2234
> > > successor isn't yet a published RFC.
> >
> > <http://mid.gmane.org/[email-masked]>
> >
> > It's not that I necessarily agree, but it's also not an issue
> > where I'd risk a debate with an AD if I care about the draft.

> "Pay the AD now or pay the RFC Editor later".  The RFC Editor will
> hold up publication as an RFC until all normative references are
> published.  Expect a change in policy or delays in publication of
> documents with ABNF.  Note that there are some serious problems
> with the ABNF draft (admittedly also in 2234):
> http://www1.ietf.org/mail-archive/web/ietf/current/msg34855.html

I have to say I found none of the problems you described were "serious" in the
sense I understand the term. You found a bunch of typos, all of which can be
fixed during the author 48 hour period, and you had a concern about being able
to determine from the grammar what rule a comment is attached to, which I find
uninteresting since I reject the notion that comment binding needs to be
determinable from the grammar.

Oh, and then there was the business about line terminators used in stored
copies of specifications. This I also find to be of no relevance. It is well
understood that local storage conventions vary but CRLF is our chosen canonical
form for line terminators. Hopefully we can avoid another round of interminable
discussion of this, repeating what happened with the MIME specification over 10
years ago.

				Ned

Date: Wed, 11 May 2005 11:26:27 -0400
From: Keith Moore <[email-masked]>
To: Bill Fenner <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt
Sender: [email-masked]

Personally I don't see why a protocol specification shouldn't reference an old 
version of the ABNF spec, so long as we believe that the old ABNF specification 
is unambiguous enough to facilitate interoperability of the protocol specification.
There shouldn't be an imposed requirement to use the "latest and greatest"
notation just for the sake of fashion.

For some situations RFC 822's ABNF is superior to any of those which succeed it.

Keith

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt
Date:  Wed, 11 May 2005 14:45:59 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 180
Sender: [email-masked]

Bruce Lilly wrote:
 
> The RFC Editor will hold up publication as an RFC until
> all normative references are published.

As long as his queue is really a queue it should work.  They
have already identified the queue delay as major issue on the
general list, let's see how they fix it.  For "they" read
e.g. the articles by Margaret, and if Bill and Scott team up
to discuss this with the RfC editor I can only hope that his
last will is up to date.  The "new errata" procedure is also
not yet convincing.

> there are some serious problems with the ABNF draft
> (admittedly also in 2234):
> http://www1.ietf.org/mail-archive/web/ietf/current/msg34855.html

I've seen your discussions with Dave and Scott on the rfc-
interests list, and thought that all problems are resolved.

I don't see a "serious" problem in your article, some typos,
a nice to have non-essential idea how to improve comments -
which might be not backwards compatible, and who cares about
the semantics of standalone comments - and something about
CrLf on the IETF ftp-server, as far as I'm concerned that's
an issue of the ftp-server, not in 2234bis.

Any hint in the direction of [CR] LF instead of CRLF is IMHO
_dangerous_ - and I'm not talking about some angry MAC users
wanting (( CR [LF] ) / ( [Cr] Lf )) instead of [CR] LF.

For a nitpicking contest I'd submit LWSP = *(WSP / CRLF WSP)
together with "strongly advised to use grouping notation".

 [2045]
> That's EBNF

1*<verbose text> is EBNF ?  That's a piece of prose in angle
brackets.  Yes, I knew the bit about some missing slashes, but
didn't know that it's another case of "erratum lost in space".

> 3834 does refer to 2045 and does not attempt to redefine
> "token" as an empty rule.

ACK, that was my real question, how to import terms defined
elsewhere.  And "token" can't be imported from 2045, see above.

>> For terms redefined by RfC 2231 I'd prefer rocket science ;->
> It's been done.

Keep your implementation, it's desperately needed when they'll
ever try to find two independent RfC 2231 implementations. <eg>

 [1958] 
> Informational RFC written by the IAB, not FYI.  It addresses
> the end-to-end issue.

Not in conjunction with the MX concept in SMTP.  It addresses
also KISS, and the RMX idea is pure KISS.  Never mind that the
really existing incarnations of RMX are more baroque than KISS:
In essence it's still the same simple idea, publish mailouts.

> the only domain associated with sending SMTP mail is that 
> which may be specified in HELO/EHLO, when a domain literal
> is not used.

That's one domain, as you say maybe.  The other domain is what
you find in the reverse path after removing the route and the
local part.  Somewhere it all started, from the POV of SMTP,
and that's the responsible party.

> MUAs are also [E]SMTP clients, and many MUAs do not have the
> ability to set the name proffered during SMTP sessions.

MUAs in trouble will find a smart host or an MSA.  Otherwise I
don't care about their fate if they try to send direct-to-MX.

And if they'd say "HELO computer" that corresponds to a result
"neutral" in the discussed I-D, because "computer" is no FQDN
with an "authentication policy of some kind".  Dito any domain
literal.

> the MTA identification *is* the domain used in HELO/EHLO.
> Unless of course you try to tie that to IP addresses

Yes, that's the idea, you will have some difficulties if you
try HELO xyzzy.claranet.de

> which doesn't work because of DHCP, NAT, multi-homed hosts,
> and IP-less and/or domain-parked domain names.

No, that's not the idea.  In any SMTP session the client has
an IP, logged in the timestamp line.  Sometimes it also has a
HELO FQDN (otherwise "neutral" => forget it, see above).

Caveat, no shortcut, the I-D isn't about IP(client) = IP(FQDN).
For the draft it's only relevant to find an "authentication
policy of some kind".  If not found => "neutral" => forget it.

But if you find this obscure policy it will list permitted IPs,
and if the SMTP IP of the client is not in this list => gotcha.

>> There's nothing wrong with this idea.
> There's plenty wrong with it; it presumes a specific model
> that simply doesn't apply in many cases.

It assumes that SMTP and DNS exist, state of the art STD 10 is
good enough.

> There is absolutely no reason to attempt any sort of
> "authentication" of a reverse path domain

Several hundreds of thousands domain owners strongly disagree.

Including mere catch-all vanity domains like "my" @xyzzy.  I've
had more than enough bogus "bounces-to", about 1000 per day for
six months.  The "bounces-to" concept is _criminal_ negligence.

There are terabytes of reasons.  And THAT is an architectural
question.  Voluntary and KISS, you can't demand more.  Fixing
real bugs etc. is all fine, but the essential idea is sane.

> Moreover, that reverse path can be null

We had this already, if there is no FQDN, then there is also no
policy, and the result is "neutral".

> even though RFC 2821 fails to provide for that case in its 
> ABNF.

 [at the end of 4.1.1.2]
| "MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF

> As noted, the draft needs a great deal of work before it can
> be reviewed thoroughly.

Here we agree, it was about the first thing I said on mxcomp
(the former MARID list) when the -00 version was published.

Something with the boilerplate to create this I-D is odd, e.g.
the "Table of Contents" is empty.

> for example it has an IP address of 123.45.67.89 and it
> responds to the greeting with HELO [123.45.67.89]

Very sane, but no FQDN => no policy => "neutral" => forget it.

You could still reject a domain literal if the IPs don't match,
but that's your decision and no "sender policy".  And if you
reject mails you don't need a header field, but an error code.

> 1) you don't have any "FQDN1"

xyzzy.dnsalias.org (no smtpd, no sender policy, but in theory)

> 2) there exists no Standards Track mechanism for "defined the
>    set of IPs used by his MTAs". Not even an Experimental RFC

Dozens of I-Ds, the discussed I-D doesn't list them.  One of
these I-Ds is very stable and more popular than say RfC 3865.

> 3) IPs change, due to DHCP among other reasons

Yes.  One of the reasons why they've invented DNS.  It's not
necessary to be precise, you can use names and/or CIDRs.  You
can even permit all IPs excluding some IPs.  As dynamic as you
wish.  And if you don't like it just don't participate, it's a
voluntary system.

> have you ever tried to change what your "Mozilla 3.0" uses?

Sure.  It assumes that I have an FQDN or get lost.  And it also
assumes that I have one or more smart hosts (today we'd say
MSA, but my monster is too stupid for this idea).  But it's my
monster, I love it, I know how to use it, and it never talks
to strangers (= any MX) without my permission.  It's always on
the "ours" side of business, no crash mail, this isn't Fidonet
or UUCP.
                             Bye, Frank

Date: Tue, 10 May 2005 19:41:38 -0700
From: Bill Fenner <[email-masked]>
Reply-To: Bill Fenner <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt
Sender: [email-masked]

On 5/10/05, Bruce Lilly <[email-masked]> wrote:
> 
> On Tue May 10 2005 04:50, Frank Ellermann wrote:
> >
> > Bruce Lilly wrote:
> >
> > >> Scott H. wants us to use the new 2234bis in the References.
> >
> > > A normative reference would hold up publication, as the 2234
> > > successor isn't yet a published RFC.
> >
> > <http://mid.gmane.org/[email-masked]>
> >
> > It's not that I necessarily agree, but it's also not an issue
> > where I'd risk a debate with an AD if I care about the draft.
> 
> "Pay the AD now or pay the RFC Editor later".  The RFC Editor will
> hold up publication as an RFC until all normative references are
> published.

Seems unlikely that any newly-approved document is going to leapfrog
the already-approved 2223bis in the RFC Editor's queue, and then get
blocked by it.

http://www.rfc-editor.org/queue.html#crocker-abnf-rfc2234bis

It's true that in the reference, it's not obivous that it's as stable
and has as much of the IETF-approved imprimateur as the RFC does; this
is at least partly a symptom of the RFC publication process taking so
long =(

  Bill

Date: Tue, 10 May 2005 16:31:02 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: [email-masked]
Subject: Review draft-leibzon-content-author-originator-00.txt
Sender: [email-masked]

I'd like to request review of my recently published draft:
  http://www.ietf.org/internet-drafts/draft-leibzon-content-author-originator-00.txt
  http://www.elan.net/~william/emailsecurity/draft-leibzon-content-author-originator-00.html

The draft proposes two new header fields Content-Author and Content-Originator
for use with specific message data parts (note: 'message' is not limited 
to SMTP as HTTP transmission is considered valid message) and identification 
of the author of the data content and person responsible for originating 
transmission of the data part. Examples in the draft are good illustration
of what I mean.

I'd like to also receive comments as to the security considerations that 
should be mentioned (if any) as I do not believe my current text is 
sufficient or appropriate.

-- 
William Leibzon
Elan Networks
[email-masked]

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt
Date: Tue, 10 May 2005 11:41:57 -0400
Sender: [email-masked]

On Tue May 10 2005 04:50, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> >> Scott H. wants us to use the new 2234bis in the References.
> 
> > A normative reference would hold up publication, as the 2234
> > successor isn't yet a published RFC.
> 
> <http://mid.gmane.org/[email-masked]>
> 
> It's not that I necessarily agree, but it's also not an issue
> where I'd risk a debate with an AD if I care about the draft.

"Pay the AD now or pay the RFC Editor later".  The RFC Editor will
hold up publication as an RFC until all normative references are
published.  Expect a change in policy or delays in publication of
documents with ABNF.  Note that there are some serious problems
with the ABNF draft (admittedly also in 2234):
http://www1.ietf.org/mail-archive/web/ietf/current/msg34855.html
Further note that the ID-Checklist specifies a normative reference
to 2234, not an informative reference and not a reference to some
other document.

> >> how should we reference terms defined elsewhere ?
> 
> > a) use a term defined elsewhere, including the source as a
> >    normative reference.
> 
> Is this also possible for something like "token", where even
> the source RfC 2045 offers no proper syntax, let alone ABNF ?

RFC 2045:
     token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                 or tspecials>

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="
                   ; Must be in quoted-string,
                   ; to use within parameter values

That's EBNF, so change ":=" to "=", "SPACE" to "SP", etc., fix
the missing "/" at the end of the second line of the tspecials
rule (erratum submitted and approved, but not yet published).
Also, current recommended practice is to specify the set of
permitted characters rather than an exclusion list.
 
> Serious question, I was surprised to find this trick in 3834,
> where I guess that it must have passed your review (and we're
> still discussing related 2045-issues in USEFOR).

3834 isn't a critical issue; "token" is used in extensions, not
a fundamental part of the syntax.  3834 does refer to 2045 and
does not attempt to redefine "token" as an empty rule.
 
> > b) write the necessary ABNF. It's not rocket science.
> 
> For terms redefined by RfC 2231 I'd prefer rocket science ;->

It's been done.

> Okay, no problem for Murray, he uses "token", not "parameter".
> 
> > see the specific references to RFC 1958
> 
> That's an FYI, and it doesn't talk about "border MTA" issues.

Informational RFC written by the IAB, not FYI.  It addresses the
end-to-end issue.
 
> > all one can say about non-local content is that it's not
> > local '"not-ours"'.
> 
> If the domain owner of an address used in "not-ours" makes a
> statement which MTAs he uses when sending mail to "strangers"
> from his POV, then you can check this at your "border MTA"
> and note the result of this check.

No, and this is one of the fundamental flaws with many anti-spam
schemes.  Pay attention: the only domain associated with sending
SMTP mail is that which may be specified in HELO/EHLO, when a
domain literal is not used.  The first problem with that is that
MUAs are also [E]SMTP clients, and many MUAs do not have the
ability to set the name proffered during SMTP sessions.  The more
serious problem is that your "domain owner ... makes a statement
which MTAs he uses" amounts to a circular argument; the MTA
identification *is* the domain used in HELO/EHLO.  Unless of course
you try to tie that to IP addresses, which doesn't work because of
DHCP, NAT, multi-homed hosts, and IP-less and/or domain-parked
domain names. 

> There's nothing wrong with this idea.

There's plenty wrong with it; it presumes a specific model that
simply doesn't apply in many cases.

> BTW, nothing forces you 
> to use it if you don't like it for whatever reason.  What you
> like or not is strictly your business, but don't confuse it
> with the "Internet Architecture".

The Internet Architecture applies to the end-to-end issues.

> > Ditto for the domain part of reverse paths.
> 
> The discussed draft nowhere says that the domain part of the
> reverse path must / should have an IP, all it needs is either
> a published (quote) "authentication policy of some kind" or no
> such policy.

There is absolutely no reason to attempt any sort of "authentication"
of a reverse path domain; that has nothing to do with the sender per
se, it is (and always has been) a path for delivery-related
notification messages (RFCs 788, 821, 2821).  Moreover, that reverse
path can be null, even though RFC 2821 fails to provide for that case
in its ABNF.
 
> IMHO the phrase (quote) "sending domain" should be explained,
> but that's not related to your review.

As noted, the draft needs a great deal of work before it can be
reviewed thoroughly.

> >> The last MTA used on the "not ours" side has an IP.
> 
> > So what? "it came from somewhere". No unsigned content from
> > there (in particular, any plaintext assertions of prior
> > authentication) is trustworthy.
> 
> I don't disagree with your last statement.  But I disagree
> with your second statement, the "border MTA" (MX) is in the
> position to identify a "not-ours" SMTP client, and this beast
> has an IP, it says HELO FQDN1, and MAIL FROM:<local@FQDN2> or
> MAIL FROM:<> among other things.

So, for example it has an IP address of 123.45.67.89 and it responds
to the greeting with
HELO [123.45.67.89]

Perfectly legal and consistent with RFCs 821, 2821. So what?
 
> So if the owner of FQDN1 or FQDN2 defined the set of IPs used
> by his MTAs when talking to the MX of a "stranger" (receiver),

Sorry,
1) you don't have any "FQDN1"
2) there exists no Standards Track mechanism for "defined the
   set of IPs used by his MTAs". Not even an Experimental RFC
   AFAIK.
3) IPs change, due to DHCP among other reasons
4) as noted above, the name proffered in HELO/EHLO is often
   outside of the control of the sender -- have you ever tried
   to change what your "Mozilla 3.0" uses?

> then the receiver can check this at his "border MTA".

Sorry, there are serious problems with the presumptions; the receiver
has nothing reliable to check, and no Standards Track mechanism with
which to do so.

> Works 
> like a charm,

Unless you happen to be a mobile user with an MUA that insists on
using some specific string, connected to a network that blocks
outbound port 25 except to the network operator's MTA, the name
proffered by the MUA happens to resemble a domain name, and the
non-standard records maintained by the corresponding domain name
holder don't happen to include DHCP-assigned IP addresses doled
out by the mobile network you happen to be connected to. This is
another fundamental flaw in many similar anti-spam schemes; they
conflate the domain name which is associated with a mailbox (for
receipt of mail) with the process of sending mail.  Pay attention
again: the domain name associated with the mailbox(es) where I
receive mail has nothing whatsoever to do with IP addresses from
which I send mail.

> if you get details like "not ours" and "border" 
> right.  Now here's "no rocket science".

Agreed "no rocket science", but for reasons other than you think. 
"Rocket science" implies "science", whereas "get details ... right"
apparently involves voodoo like conflating sending and receipt of
messages and the pretension that NAT, DHCP, port blocking, domain
parks, non-configurable MUAs, and multi-homed hosts don't exist.

> > The draft proposes *deletion* of message header content
> 
> Oops, yes, (quote) "for security reasons".  I had the "MAY
> appear more than once" in mind.  The only case I know where
> a header field could be replaced is the Return-Path.  That's
> at the MDA, not in transit.  And of course gateways might do
> wild and wonderful things, but the discussed draft is about
> a "border MTA", not gateways.

And the point is that if it's not about gateways and not about
final delivery (MDAs) then modification of content other than
adding Received fields is ausschließlich verboten. [and adding
trace fields to the message content rather than to a separate
wrapper is a poor design choice that we've been suffering with
for more than two decades]
 
> > Mere drafts (e.g. "2234bis") are less desirable where there
> > is a suitable stable reference.
> 
> It's approved and in the in-queue.  When are these famous 48
> hours in this case, could it still be changed ?

48 hours is a minimum author's review period, after the RFC Editor
has edited the RFC.  It has been known to take months.  In this
case, let's hope there are changes, otherwise there will be a
round of repeated comments, suggested errata, probably a six-month
wait, and a likely reset to Proposed.  So, yes, it can still be
changed, and is therefore not itself stable, and lacking an assigned
number has no stable reference.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt
Date:  Tue, 10 May 2005 10:50:27 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 92
Sender: [email-masked]

Bruce Lilly wrote:

>> Scott H. wants us to use the new 2234bis in the References.

> A normative reference would hold up publication, as the 2234
> successor isn't yet a published RFC.

<http://mid.gmane.org/[email-masked]>

It's not that I necessarily agree, but it's also not an issue
where I'd risk a debate with an AD if I care about the draft.

>> how should we reference terms defined elsewhere ?

> a) use a term defined elsewhere, including the source as a
>    normative reference.

Is this also possible for something like "token", where even
the source RfC 2045 offers no proper syntax, let alone ABNF ?

Serious question, I was surprised to find this trick in 3834,
where I guess that it must have passed your review (and we're
still discussing related 2045-issues in USEFOR).

> b) write the necessary ABNF. It's not rocket science.

For terms redefined by RfC 2231 I'd prefer rocket science ;->
Okay, no problem for Murray, he uses "token", not "parameter".

> see the specific references to RFC 1958

That's an FYI, and it doesn't talk about "border MTA" issues.

> all one can say about non-local content is that it's not
> local '"not-ours"'.

If the domain owner of an address used in "not-ours" makes a
statement which MTAs he uses when sending mail to "strangers"
from his POV, then you can check this at your "border MTA"
and note the result of this check.

There's nothing wrong with this idea.  BTW, nothing forces you
to use it if you don't like it for whatever reason.  What you
like or not is strictly your business, but don't confuse it
with the "Internet Architecture".  Maybe you need another
choice in your review-form:  [X] I really don't like this idea

> Ditto for the domain part of reverse paths.

The discussed draft nowhere says that the domain part of the
reverse path must / should have an IP, all it needs is either
a published (quote) "authentication policy of some kind" or no
such policy.

IMHO the phrase (quote) "sending domain" should be explained,
but that's not related to your review.

>> The last MTA used on the "not ours" side has an IP.

> So what? "it came from somewhere". No unsigned content from
> there (in particular, any plaintext assertions of prior
> authentication) is trustworthy.

I don't disagree with your last statement.  But I disagree
with your second statement, the "border MTA" (MX) is in the
position to identify a "not-ours" SMTP client, and this beast
has an IP, it says HELO FQDN1, and MAIL FROM:<local@FQDN2> or
MAIL FROM:<> among other things.

So if the owner of FQDN1 or FQDN2 defined the set of IPs used
by his MTAs when talking to the MX of a "stranger" (receiver),
then the receiver can check this at his "border MTA".  Works
like a charm, if you get details like "not ours" and "border"
right.  Now here's "no rocket science".

> The draft proposes *deletion* of message header content

Oops, yes, (quote) "for security reasons".  I had the "MAY
appear more than once" in mind.  The only case I know where
a header field could be replaced is the Return-Path.  That's
at the MDA, not in transit.  And of course gateways might do
wild and wonderful things, but the discussed draft is about
a "border MTA", not gateways.

> Mere drafts (e.g. "2234bis") are less desirable where there
> is a suitable stable reference.

It's approved and in the in-queue.  When are these famous 48
hours in this case, could it still be changed ?  And Paul's
taobis I-D is simply nice.
                          Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt
Date: Mon, 9 May 2005 21:05:27 -0400
Sender: [email-masked]

On Mon May 9 2005 19:33, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
>  
> > Review of draft-kucherawy-sender-auth-header-02 by B. Lilly
> 
> Is your review tool also available as Web form ?

No. It's a set of troff/nroff macros and template that can  be used
to generate a review document (or one could edit the text version).

> Something 
> like proto-I-D in, death sentence (or whatever) out ?

No, it requires human review.
 
> The "idnits webservice" (and related tools like rfcdiff) does
> not work from my POV, I get no output, only the "usage" page:
> 
> <http://ietf.levkowetz.com/tools/idnits/idnits.pyht>

I just run idnits locally.
 
> >    [X] ABNF [R4.RFC2234]
> 
> Somewhat beside the point, but this draft doesn't contain the
> string "2234" or "ABNF".

It should, since it uses ABNF.  Since one needs to understand
ABNF and its core rules to understand the draft ABNF (well, maybe
if the draft ABNF weren't so badly broken), it should be a
normative reference.

> And if you check it anyway Scott H. 
> wants us to use the new 2234bis in the References.

A normative reference would hold up publication, as the 2234
successor isn't yet a published RFC.
 
> >               20:0: error: Empty rule
> >               22:0: error: Empty rule
>  
> >    Clearly, the "ABNF" is badly broken.
> 
> That's not helpful, so how should we reference terms defined
> elsewhere ?

a) use a term defined elsewhere, including the source as a normative
   reference.
or
b) write the necessary ABNF. It's not rocket science.

Note that according to the IETF "I-D Checklist"
http://www.ietf.org/ID-Checklist.html
"All ABNF must be checked".  Foisting unchecked broken "ABNF" on
reviewers is a waste of time.

> >    [X] None of the above.
> 
> Is that your personal opinion or idnits output ?

My opinion, based on what I see (my guess is that the concept is so
incompatible with the Internet Architecture and the reality of SMTP
and the message format that it should be withdrawn; but I stopped
short of saying so in case there's some merit lurking somewhere
behind the broken ABNF and formatting).

> > [X] missing or inadequate IANA considerations
> 
> = missing 3864 header registration form

at least. Probably also keyword registries.  Possibly some discussion
of private-use/experimental keywords and non-registration of same.
 
> > [X] incompatible with the Internet Architecture
> 
> If that's American humour please add an I18N version.

Not humor, see the specific references to RFC 1958, end-to-end issues,
and lack of transitive trust.
 
> > Trust needs to be end-to-end.
> 
> No.  If you can partition the net into "ours" and "not-ours",
> and find an imaginary border between these partitions along the
> lines of "our MX", then you can reduce this admittedly simple
> check to the hop from the last "not ours" to the first "ours"
> MTA,  The concept is known as MX.

Provides no useful information; "it came from somewhere".  If all
received mail is local '"ours"' (and header content is trusted), then
any spam is a purely local problem.  Conversely w/o an end-to-end
mechanism, all one can say about non-local content is that it's
not local '"not-ours"'. 

> > there exist domain names which have no corresponding IP
> > addresses.
> 
> So what ?

So the domain name in an SMTP HELO or ESMTP EHLO might not
correspond to the IP address of the SMTP client.  Nothing
suitable for authentication there.  Ditto for the domain
part of reverse paths.

> The last MTA used on the "not ours" side has an IP. 

So what? "it came from somewhere". No unsigned content from there
(in particular, any plaintext assertions of prior authentication)
is trustworthy. 
 
> > SMTP transfer does not alter content except for addition of
> > time-stamp fields (a.k.a. Received fields), and (at "final"
> > delivery) a Return-Path field.
> 
> Obviously this draft proposes a new trace header field.

No, it's more serious than that. The draft proposes *deletion* of
message header content, which does not now happen (other than at
gateways).  Worse, it leaves such deletion optional (MAY), making
it unpredictable whether or not such content might make it through
transport [requiring deletion would break backwards compatibility
with the entire installed SMTP base, so I suspect that there's no
way to salvage this proposal].

> > modification of message header content in transit.
> 
> In other words it adds a header field, but does not modify any
> existing header field.

No, see above.
 
> > [X] [R57.Errata]
> 
> That's a dubious source, I've tested it two times, and so far
> nothing happened (after an inquiry I got the confirmation that
> they got it for the first).

There exist errata for many of the documents suggested for consultation
(e.g. 2234).

> Try to make these reviews shorter, e.g. remove anything that's
> clearly not applicable.

Noted.

> You managed to reference your own I-D, 
> therefore you could do the same with 2234bis or taobis.

Most of the references are approved BCP, FYI, STD or RFCs.  Mere drafts
(e.g. "2234bis") are less desirable where there is a suitable stable
reference.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt
Date:  Tue, 10 May 2005 01:33:57 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 101
Sender: [email-masked]

Bruce Lilly wrote:
 
> Review of draft-kucherawy-sender-auth-header-02 by B. Lilly

Is your review tool also available as Web form ?  Something
like proto-I-D in, death sentence (or whatever) out ?

The "idnits webservice" (and related tools like rfcdiff) does
not work from my POV, I get no output, only the "usage" page:

<http://ietf.levkowetz.com/tools/idnits/idnits.pyht>

>    [X] ABNF [R4.RFC2234]

Somewhat beside the point, but this draft doesn't contain the
string "2234" or "ABNF".  And if you check it anyway Scott H.
wants us to use the new 2234bis in the References.

>               20:0: error: Empty rule
>               22:0: error: Empty rule
 
>    Clearly, the "ABNF" is badly broken.

That's not helpful, so how should we reference terms defined
elsewhere ?  Especially terms defined NOWHERE in ABNF, as all
2045 or 2231 terms.  Sorry, but I'm getting _very_ angry if I
see this, it's a royal PITA, see also many USEFOR articles.

> However, the status as defined in BCP 9 should be:

etc., the dysfunctional Web interface claims that there should
be less verbose output formats better suited for posting.

>    [X] None of the above.

Is that your personal opinion or idnits output ?  I'd guess
that Murray wants FYI / proposed standard / experimental.

> [X] missing or inadequate IANA considerations

= missing 3864 header registration form

> [X] incompatible with the Internet Architecture

If that's American humour please add an I18N version.

> [X] uses non-standard terminology

Where ?  It certainly explains "border-MTA", although I'd
prefer MX.  Okay, I saw it later, your "header" hobby horse.

> Trust needs to be end-to-end.

No.  If you can partition the net into "ours" and "not-ours",
and find an imaginary border between these partitions along the
lines of "our MX", then you can reduce this admittedly simple
check to the hop from the last "not ours" to the first "ours"
MTA,  The concept is known as MX.

> Unencrypted, unsigned content is trivially forged.

Try it, forge a MAIL FROM me and send it to any receiver using
SPF checks.  Hint: it's not impossible.  In practice you can't.

> there exist domain names which have no corresponding IP
> addresses.

So what ?  The last MTA used on the "not ours" side has an IP.

> SMTP transfer does not alter content except for addition of
> time-stamp fields (a.k.a. Received fields), and (at "final"
> delivery) a Return-Path field.

Obviously this draft proposes a new trace header field.  In
practice MDAs already create numerous additional fields like a
very important X-Envelope-To or a X-Spam-Prev-Subject (that's
the original subject before adding ***SPAM*** to it).  Just
two arbitrary examples found in my inbox.

> modification of message header content in transit.

In other words it adds a header field, but does not modify any
existing header field.

> [X] [R10.FYI18]; pay particular attention to the standard
>                  definition of "header".

That won't stop him to find "bang path" and "mail path".
 
> [X] [R57.Errata]

That's a dubious source, I've tested it two times, and so far
nothing happened (after an inquiry I got the confirmation that
they got it for the first).  The second was about RfC 3978.

Try to make these reviews shorter, e.g. remove anything that's
clearly not applicable.  You managed to reference your own I-D,
therefore you could do the same with 2234bis or taobis.

                           Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: "ietf-822" <[email-masked]>
Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt
Date: Mon, 9 May 2005 14:11:11 -0400
Cc: [email-masked]
Sender: [email-masked]

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Message Header for Indicating Sender Authentication Status
> 	Author(s)	: M. Kucherawy
> 	Filename	: draft-kucherawy-sender-auth-header-02.txt
> 	Pages		: 15
> 	Date		: 2005-5-5
> 	
> This memo defines a new message header for use with [MAIL] messages
>    to indicate the results of sender authentication efforts to mail user
>    agents (MUAs) in order to equip them to relay that information in a
>    convenient way to users.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-02.txt

Review of         draft-kucherawy-sender-auth-header-02      by B. Lilly

Internet-Drafts and RFCs are required to meet certain criteria: [R1.ID],
[R2.Instruct].  These can be checked by using the "idnits" tool:
[R3.idnits].  That tool noted the following regarding the document:

idnits 1.71 (02 May 2005)

draft-kucherawy-sender-auth-header-02.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack separate sections for Informative/Normative
    References.
    Checking conformance with RFC 3978/3979 boilerplate...
  * The document claims conformance with section 10 of RFC 2026, but uses
    some RFC 3978/3979 boilerplate.  As RFC 3978/3979 replaces section 10 of RFC
    2026, you should not claim conformance with it if you have changed to using
    RFC 3978/3979 boilerplate.
  * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
    Acknowledgement  -- however, there's a paragraph with a matching beginning.
    Boilerplate error?
  * The document seems to lack an RFC 3978 Section 5.4 Copyright Line --
    however, there's a paragraph with a matching beginning. Boilerplate error?
  * The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78.
  * The document seems to lack an RFC 3978 Section 5.5 Disclaimer --
    however, there's a paragraph with a matching beginning. Boilerplate error?
  * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure
    Acknowledgement.
  * The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure
    Acknowledgement.
  * The document seems to lack an RFC 3979 Section 5, para 3 IPR Disclosure
    Invitation.
    (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
    instead of verbatim RFC 3978 boilerplate.  After 6 May 2005, submission of
    drafts without verbatim RFC 3978 boilerplate is not accepted.)

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

  * The document seems to lack a 1id_guidelines paragraph about 6 months
    document validity -- however, there's a paragraph with a matching beginning.
    Boilerplate error?
  - It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 15 pages

  Miscellaneous warnings:

  - The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation
    clause.

    Run idnits with the --verbose option for more detailed information.

The document contains:

   [ ] MIB

   [X] ABNF [R4.RFC2234]

   [ ] Internet message (or fragment)

   Verification tools are available at [R5.verify] and/or [R6.mparse].

   Verification tools yielded the following results:

              Bill's ABNF Parser
              Errors during parsing:

              Errors are noted by line number and column,
              e.g. line:column: Something bad.

              20:0: error: Empty rule

              22:0: error: Empty rule

   Clearly, the "ABNF" is badly broken.

The formatting of the document is atrocious. See [R7.formatting] and
[R8.formatting]

The (intended) status of the document is:

   [X] Not indicated

   [ ] Experimental

   [ ] Informational

   [ ] Proposed Standard

   [ ] Draft Standard

   [ ] Internet Standard

   [ ] Best Current Practice

   However, the status as defined in BCP 9 should be:

   [ ] Experimental (typically denotes a specification that is part of
       some research or development effort, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [ ] Informational (published for the general information of the
       Internet community, does not represent an Internet community
       consensus or recommendation, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [ ] Proposed Standard (generally stable, has resolved known design
       choices, is believed to be well-understood, has received
       significant community review, appears to enjoy enough community
       interest to be considered valuable, has no known technical
       omissions)

   [ ] Draft Standard (at least two independent and fully interoperable
       implementations from different code bases have been developed,
       sufficient successful operational experience has been obtained,
       unused options and features have been removed, well-understood,
       known to be quite stable both in its semantics and as a basis for
       developing an implementation, must have been Proposed Standard
       for at least six months)

   [ ] Internet Standard (significant implementation and successful
       operational experience has been obtained, characterized by a high
       degree of technical maturity and by a generally held belief that
       the specified protocol or service provides significant benefit to
       the Internet community, must have been Draft Standard for at
       least four months)

   [ ] Historic (A specification that has been superseded by a more
       recent specification or is for any other reason considered to be
       obsolete, must have been Standards Track)

   [ ] Best Current Practice (a way to standardize practices and the
       results of community deliberations, subject to the same basic set
       of procedures as standards track documents, the community's best
       current thinking on a statement of principle or on what is
       believed to be the best way to perform some operations or IETF
       process function, common guidelines for policies and operations
       which are generally different in scope and style from protocol
       standards, not well suited to the phased roll-in nature of the
       three stage standards track and instead generally only make sense
       for full and immediate instantiation)

   [X] None of the above.

The document suffers from the following serious defects:

   [X] missing or inadequate IANA considerations

   [X] missing or inadequate security considerations

   [ ] missing or inadequate internationalization considerations

   [X] incompatible with the Internet Architecture

   [X] incompatible with one or more Internet Standards

   [X] uses non-standard terminology which may lead to confusion,
       misinterpretation, and loss of interoperability

   [ ] not backwards compatible with widely deployed,
       standards-conforming infrastructure

   [ ] BCP 14 is referenced, but keywords are not used, or are used
       inappropriately

In addition, the proposal is based on a lack of understanding or
misunderstanding of the following issues:

   o While message delivery may be sequential, trust is not transitive.
     Ignoring forgery for the moment, if A indicates authenticity to B,
     and B trusts A, then it does not follow that C, who trusts B,
     should also trust A.  Trust needs to be end-to-end.

   o Unencrypted, unsigned content is trivially forged.

   o SMTP involves message transfer without prior arrangement, and may
     traverse many transfer agents, as directed by MX DNS RRs.
     Consequently, there might very well be no basis for authentication
     for some part of a transfer (which is why trust must be
     end-to-end):

      o Due to DHCP and NAT, there might be no correspondence between a
        domain name (SMTP HELO or ESMTP EHLO) and an IP address.
        Indeed, there exist domain names which have no corresponding IP
        addresses.

      o The semantics of the [E]SMTP MAIL FROM command argument are of a
        path for notification messages, which may legitimately be
        unrelated, in whole or in part (e.g. domain), to the message
        sender or message author.

      o The message header address fields (From, To, Reply-To, Sender,
        etc.)  are unrelated to message transport, and are end-to-end,
        user-to-user communication.

      About the only portions of transfer that have some basis for
      authentication are between parties which do have a prior
      relationship, as between an originator's MUA and his ISP's MSA (if
      the ISP operates a separate MSA on a port which is not blocked
      between the MUA and MSA).  Beyond such a hypothetical ISP's
      borders (e.g. when a message is subsequently transferred to the MX
      host corresponding to a recipient mailbox), such "authentication"
      is of precisely zero value; there is (in general) no prior
      arrangement between the hypothetical ISP's sending MTA and the MX
      host receiving MTA, and any random sending MTA could connect to
      the receiving MTA and present unsigned, unencrypted content
      purporting to assert MUA-MSA auhentication.

   o SMTP transfer does not alter content except for addition of
     time-stamp fields (a.k.a. Received fields), and (at "final"
     delivery) a Return-Path field.  The proposal advocates slicing,
     dicing, and modification of message header content in transit.

Please carefully review the references and resources indicated:

   [X] [R1.ID]; Note in particular "The Internet-Draft should neither
       state nor imply that it has any standards status", whereas the
       draft uses "this standard" many times.

   [X] [R2.Instruct]

   [X] [R3.idnits]

   [ ] [R4.RFC2234]

   [ ] [R5.verify]

   [ ] [R6.mparse]

   [ ] [R7.formatting]

   [ ] [R8.formatting]

   [ ] [R9.FYI17]

   [X] [R10.FYI18]; pay particular attention to the standard definition
       of "header".

   [ ] [R11.FYI36]

   [X] [R12.STD10], [R13.STD10], [R14.STD10]

   [X] [R15.STD11]; pay particular attention to the standard terms
       "header" and "header field".  Also note that comments cannot
       appear between a field name and the colon which separates it from
       the field body, as printable characters including parentheses may
       be part of a field name.  See also section 4.1 regarding (lack
       of) significance of message header field order.

   [ ] [R16.STD13], [R17.STD13]

   [ ] [R18.STD17]

   [ ] [R19.BCP9]

   [ ] [R20.BCP14]

   [ ] [R21.BCP18]

   [X] [R22.BCP22]

   [X] [R23.BCP26]

   [ ] [R24.BCP32]

   [ ] [R25.BCP41]

   [ ] [R26.BCP44]

   [ ] [R27.BCP56]

   [X] [R28.BCP61]

   [ ] [R29.BCP72]

   [X] [R30.BCP82]

   [X] [R31.BCP90]

   [X] [R32.BCP95]

   [ ] [R33.BCP97]

   [ ] [R34.RFC1796]

   [X] [R35.RFC1847]

   [X] [R36.RFC1925] (5), (6), (8), (11)

   [X] [R37.RFC1958]; particularly section 2.3.

   [ ] [R38.RFC1982]

   [X] [R39.RFC2015]

   [X] [R40.RFC2223] paying particular attention to section 3a "Do not
       do hyphenation of words at the right margin"

   [X] [R41.RFC2231]

   [X] [R42.RFC2821]

   [X] [R43.RFC2822]; pay particular attention to the standard terms
       "header" and "header field".  Also note that comments cannot
       appear between a field name and the colon which separates it from
       the field body, as printable characters including parentheses may
       be part of a field name.  See also section 3.6 and Appendix B
       regarding (lack of) significance of message header field order.

   [ ] [R44.RFC3092]

   [ ] [R45.RFC3117]

   [X] [R46.RFC3156]

   [ ] [R47.RFC3254]

   [ ] [R48.RFC3426]

   [ ] [R49.RFC3439]

   [ ] [R50.RFC3444]

   [X] [R51.RFC3467]

   [ ] [R52.RFC3523]

   [ ] [R53.RFC3536]

   [ ] [R54.RFC3724]

   [ ] [R55.RFC3929]

   [ ] [R56.RFC3930]

   [X] [R57.Errata]

   [X] [R58.Fields]

The following applies to the document being reviewed:

   [ ] The document seems promising, but needs work.

   [X] The document needs substantial rework before serious review can
       take place.

   [ ] The document is a disaster.  It should be withdrawn.

References:

   [R1.ID]         "Guidelines to Authors of Internet-Drafts", March
                   2005, ftp://ftp.ietf.org/ietf/1id-guidelines.txt

   [R2.Instruct]   Reynolds, J., and R. Braden, "Instructions to Request
                   for Comments (RFC) Authors", Work in progress (August
                   2004).

   [R3.idnits]     http://ietf.levkowetz.com/tools/idnits/

   [R4.RFC2234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
                   Specifications: ABNF", RFC 2234, November 1997.

   [R5.verify]     TOOLS, "Available Verification Tools",
                   http://tools.ietf.org/verif-tools

   [R6.mparse]     Internet Message Format validating parser,
                   http://users.erols.com/blilly/mparse/index.html

   [R7.formatting] RFC Editor, "Formatting RFCs and Internet Drafts",
                   http://www.rfc-editor.org/formatting.html

   [R8.formatting] Lilly, B., "Writing Internet-Drafts and Requests For
                   Comments using troff and nroff",
                   http://users.erols.com/blilly/formatting/draft-lilly-using-troff-04.html

   [R9.FYI17]      Harris, S., "The Tao of IETF - A Novice's Guide to
                   the Internet Engineering Task Force", RFC 3160,
                   August 2001.

   [R10.FYI18]     Malkin, G., "Internet Users' Glossary", RFC 1983,
                   August 1996.

   [R11.FYI36]     Shirey, R., "Internet Security Glossary", RFC 2828,
                   May 2000.

   [R12.STD10]     Postel, J., "Simple Mail Transfer Protocol", STD 10,
                   RFC 821, August 1982.

   [R13.STD10]     Klensin, J., Freed, N., Rose, M., Stefferud, E., and
                   D. Crocker, "SMTP Service Extensions", STD 10,
                   RFC 1869, November 1995.

   [R14.STD10]     Partridge, C., "Mail routing and the domain system",
                   STD 10, RFC 974, January 1986.

   [R15.STD11]     Crocker, D., "Standard for the format of ARPA
                   Internet text messages", STD 11, RFC 822, August
                   1982.

   [R16.STD13]     Mockapetris, P., "Domain names - concepts and
                   facilities", STD 13, RFC 1034, November 1987.

   [R17.STD13]     Mockapetris, P., "Domain names - implementation and
                   specification", STD 13, RFC 1035, November 1987.

   [R18.STD17]     McCloghrie, K. and M. Rose, "Management Information
                   Base for Network Management of TCP/IP-based
                   internets:MIB-II", STD 17, RFC 1213, March 1991.

   [R19.BCP9]      Bradner, S., "The Internet Standards Process --
                   Revision 3", BCP 9, RFC 2026, October 1996.

   [R20.BCP14]     Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [R21.BCP18]     Alvestrand, H., "IETF Policy on Character Sets and
                   Languages", BCP 18, RFC 2277, January 1998.

   [R22.BCP22]     Scott, G., "Guide for Internet Standards Writers",
                   BCP 22, RFC 2360, June 1998.

   [R23.BCP26]     Narten, T. and H. Alvestrand, "Guidelines for Writing
                   an IANA Considerations Section in RFCs", BCP 26,
                   RFC 2434, October 1998.

   [R24.BCP32]     Eastlake 3rd, D. and A. Panitz, "Reserved Top Level
                   DNS Names", BCP 32, RFC 2606, June 1999.

   [R25.BCP41]     Floyd, S., "Congestion Control Principles", BCP 41,
                   RFC 2914, September 2000.

   [R26.BCP44]     Moore, K. and N. Freed, "Use of HTTP State
                   Management", BCP 44, RFC 2964, October 2000.

   [R27.BCP56]     Moore, K., "On the use of HTTP as a Substrate",
                   BCP 56, RFC 3205, February 2002.

   [R28.BCP61]     Schiller, J., "Strong Security Requirements for
                   Internet Engineering Task Force Standard Protocols",
                   BCP 61, RFC 3365, August 2002.

   [R29.BCP72]     Rescorla, E. and B. Korver, "Guidelines for Writing
                   RFC Text on Security Considerations", BCP 72,
                   RFC 3552, July 2003.

   [R30.BCP82]     Narten, T., "Assigning Experimental and Testing
                   Numbers Considered Useful", BCP 82, RFC 3692, January
                   2004.

   [R31.BCP90]     Klyne, G., Nottingham, M., and J. Mogul,
                   "Registration Procedures for Message Header Fields",
                   BCP 90, RFC 3864, September 2004.

   [R32.BCP95]     Alvestrand, H., "A Mission Statement for the IETF",
                   BCP 95, RFC 3935, October 2004.

   [R33.BCP97]     Bush, R. and T. Narten, "Clarifying when Standards
                   Track Documents may Refer Normatively to Documents at
                   a Lower Level", BCP 97, RFC 3967, December 2004.

   [R34.RFC1796]   Huitema, C., Postel, J., and S. Crocker, "Not All
                   RFCs are Standards", RFC 1796, April 1995.

   [R35.RFC1847]   Galvin, J., Murphy, S., Crocker, S., and N. Freed,
                   "Security Multiparts for MIME: Multipart/Signed and
                   Multipart/Encrypted", RFC 1847, October 1995.

   [R36.RFC1925]   Callon, R., "The Twelve Networking Truths", RFC 1925,
                   April 1996.

   [R37.RFC1958]   Carpenter, B., "Architectural Principles of the
                   Internet", RFC 1958, June 1996.

   [R38.RFC1982]   Elz, R. and R. Bush, "Serial Number Arithmetic",
                   RFC 1982, August 1996.

   [R39.RFC2015]   Elkins, M., "MIME Security with Pretty Good Privacy
                   (PGP)", RFC 2015, October 1996.

   [R40.RFC2223]   Postel, J. and J. Reynolds, "Instructions to RFC
                   Authors", RFC 2223, October 1997.

   [R41.RFC2231]   Freed, N. and K. Moore, "MIME Parameter Value and
                   Encoded Word Extensions: Character Sets, Languages,
                   and Continuations", RFC 2231, November 1997.

   [R42.RFC2821]   Klensin, J., "Simple Mail Transfer Protocol",
                   RFC 2821, April 2001.

   [R43.RFC2822]   Resnick, P., "Internet Message Format", RFC 2822,
                   April 2001.

   [R44.RFC3092]   Eastlake 3rd, D., Manros, C., and E. Raymond,
                   "Etymology of "Foo"", RFC 3092, April 2001.

   [R45.RFC3117]   Rose, M., "On the Design of Application Protocols",
                   RFC 3117, November 2001.

   [R46.RFC3156]   Elkins, M., Del Torto, D., Levien, R., and T.
                   Roessler, "MIME Security with OpenPGP", RFC 3156,
                   August 2001.

   [R47.RFC3254]   Alvestrand, H., "Definitions for talking about
                   directories", RFC 3254, April 2002.

   [R48.RFC3426]   Floyd, S., "General Architectural and Policy
                   Considerations", RFC 3426, November 2002.

   [R49.RFC3439]   Bush, R. and D. Meyer, "Some Internet Architectural
                   Guidelines and Philosophy", RFC 3439, December 2002.

   [R50.RFC3444]   Pras, A. and J. Schoenwaelder, "On the Difference
                   between Information Models and Data Models",
                   RFC 3444, January 2003.

   [R51.RFC3467]   Klensin, J., "Role of the Domain Name System (DNS)",
                   RFC 3467, February 2003.

   [R52.RFC3523]   Polk, J., "Internet Emergency Preparedness (IEPREP)
                   Telephony Topology Terminology", RFC 3523, April
                   2003.

   [R53.RFC3536]   Hoffman, P., "Terminology Used in
                   Internationalization in the IETF", RFC 3536, May
                   2003.

   [R54.RFC3724]   Kempf, J., Austein, R., and IAB, "The Rise of the
                   Middle and the Future of End-to-End: Reflections on
                   the Evolution of the Internet Architecture",
                   RFC 3724, March 2004.

   [R55.RFC3929]   Hardie, T., "Alternative Decision Making Processes
                   for Consensus-Blocked Decisions in the IETF",
                   RFC 3929, October 2004.

   [R56.RFC3930]   Eastlake 3rd, D., "The Protocol versus Document
                   Points of View in Computer Protocols", RFC 3930,
                   October 2004.

   [R57.Errata]    RFC-Editor errata page,
                   http://www.rfc-editor.org/errata.html

   [R58.Fields]    Lilly, B., "Implementer-friendly Specification of
                   Message and MIME-Part Header Fields and Field
                   Components", work in progress, May 2005.