headers
Dave Crocker | 5 Aug 2002 17:47

Fwd: I-D ACTION:draft-ietf-fax-esmtp-conneg-03.txt


Folks,

The SMTP Conneg draft has been revised, with the primary change being 
addition of two Appendices.  One discusses use of the option when there are 
multiple recipients.  The other discusses use of the option when there is 
relaying.

d/

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Internet Fax Working Group of the IETF.
>
>         Title           : SMTP Service Extension for Content Negotiation
>         Author(s)       : K. Toyoda, D. Crocker
>         Filename        : draft-ietf-fax-esmtp-conneg-03.txt
>         Pages           :
>         Date            : 02-Aug-02
>
>This document defines a content negotiation service
>extension for SMTP [ESMTP1, ESMTP2] whereby an SMTP
>client may request information about content
>capabilities of the target device or system that is
>serviced by an SMTP server.  The SMTP server may report
>the target's content capabilities back to the client.
>This process emulates a classic facsimile start-of-
>session capabilities negotiation, although it can be used
>for a broad range of email-based scenarios.  This service
>extension is primarily intended for 'direct', one-hop,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Moore | 5 Aug 2002 21:19
Picon

Re: Fwd: I-D ACTION:draft-ietf-fax-esmtp-conneg-03.txt


[bcc'ed to iesg - on the assumption that they might not want to see the 
resulting replies]

> The SMTP Conneg draft has been revised, with the primary change being 
> addition of two Appendices.  One discusses use of the option when there are 
> multiple recipients.  The other discusses use of the option when there is 
> relaying.

I think the two appendices help slightly.  However they also introduce 
new problems not present in the previous draft.  Also, the new version of 
the document fails to correct a number of problems (some of them serious) 
in the previous version.

In particular,

- it is still overbroad, claiming applicability for general email
  when it really works only for a limited subset of content 
  which has an obvious ordering relation for "quality".   
  perhaps illustrating this, all of the examples are for fax.

- it still permits unauthorized parties to make arbitrary and
  unspecified alterations to mail.  

- worse, the new version permits unauthorized parties to make
  arbitrary assertions of recipient capabilities in the absence
  of explicit information.

- the new version also permits multiple conversions to take place,
  potentially degrading the message considerably more than a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Crocker | 6 Aug 2002 10:21

Re: Fwd: I-D ACTION:draft-ietf-fax-esmtp-conneg-03.txt


Keith,

Responding to those items that I can:

At 03:19 PM 8/5/2002 -0400, Keith Moore wrote:
>- it is still overbroad, claiming applicability for general email
>   when it really works only for a limited subset of content
>   which has an obvious ordering relation for "quality".

Please feel free to provide real-world examples of usage that is likely to 
be attempted and that will not work properly.

>      perhaps illustrating this, all of the examples are for fax.

You believe that making examples be for something other than fax will 
materially affect the adequacy of the normative specification?

>- it still permits unauthorized parties to make arbitrary and
>   unspecified alterations to mail.

Sorry, no.  It makes no alterations to the power of intermediaries.  It 
gives them better information, not different capabilities.

In any event, the "permissions" assigned to intermediaries are a matter of 
administration policy, not technical specification.  If an administrative 
authority does not want to permit use of this option, it will not use it.

>- worse, the new version permits unauthorized parties to make
>   arbitrary assertions of recipient capabilities in the absence
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Moore | 6 Aug 2002 20:13
Picon

Re: Fwd: I-D ACTION:draft-ietf-fax-esmtp-conneg-03.txt


> Keith,
> 
> Responding to those items that I can:
> 
> At 03:19 PM 8/5/2002 -0400, Keith Moore wrote:
> >- it is still overbroad, claiming applicability for general email
> >   when it really works only for a limited subset of content
> >   which has an obvious ordering relation for "quality".
> 
> Please feel free to provide real-world examples of usage that is likely to 
> be attempted and that will not work properly.

I have already done so, on multiple occasions.  Perhaps we have different 
ideas of what is 'likely' or what is 'real-world'.  To me it seems likely 
and consistent with the real world that senders will send around a wide
variety of content, that recipients will want to specify what kinds of 
content they are willing to accept to keep from having their mailboxes
cluttered with useless content, and that senders will at least occasionally 
want to specify that the message should not be delivered unless the recipient 
is willing to accept the content.  All of which is fine.  But the assumption 
that some intermediate MTA can then be expected to "transform" the sender's 
content into something that the recipient is willing to accept - that does
not seem either fine, likely, or consistent with the real world.

At any rate, I don't think it's acceptable for an extension to cause
delivery failure or unrequested munging of messages even in 'unlikely' 
cases - when whether the extension is employed isn't under control of 
the sender.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Moore | 6 Aug 2002 21:15
Picon

an attempt to make CONNEG-over-SMTP work reasonably over mail relays


this is an attempt to outline what it will take to make CONNEG-over-SMTP
work reasonably over mail relays

goals:

- make it possible for a client to request recipient capabilities, 
  for whatever use, provided it can communicate directly with 
  recipient's SMTP servers.

- make it possible for senders to request "assuredly deliver in a 
  form the recipient can use, else fail" semantics.

- work with relaying

- no change to current SMTP functioning unless explicitly requested
  by sender

1. providing recipient capability information

for general-purpose mail reception, recipient capability information 
MUST be under the control of the recipient.

for fixed-function devices which have exclusive use of one or more 
mailboxes, the recipient capabilities associated with those mailboxes 
MAY be set by such devices to reflect their capabilities.  the mechanism 
by which this is done, in the case where the SMTP server and the 
receiving device are separate, is currently unspecified.

posting of recipient capability information DOES NOT imply that the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric A. Hall | 16 Aug 2002 17:57

clarification re 2821, s4.1.4


 | 4.1.4 Order of Commands

 | An SMTP server MAY verify that the domain name parameter in the EHLO
 | command actually corresponds to the IP address of the client.
 | However, the server MUST NOT refuse to accept a message for this
 | reason if the verification fails: the information about verification
 | failure is for logging and tracing only.

There are two possible ways to read that.

The first way says that a legitimately-formed identifier cannot be
refused, even if it is verified as wrong. This prevents me from rejecting
sessions which provide my own domain name in the identifier.

The other way of reading it says that an identifier which has been
verified as wrong can be rejected.

Which is the intended interpretation? and can we get a clarification when
this is revisited.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
Permalink | Reply | 28 comments |
headers
Tony Hansen | 16 Aug 2002 21:09
Picon
Favicon

drums2


[I recently posted the following query in ietf-822. I should have posted 
it here as well. - Tony]

2821/2822 are "Proposed Standards" and have been out for 1.5 years now. 
What will it take to move them forward to Draft Standard? We've had 
considerably longer than 1.5 years to get operational experience with 
them, and I KNOW that there are lots of interoperational instances of each.

     Tony Hansen
     tony <at> att.com

P.S. If 2821 and 2822 need to be reissued, it might also be nice if they 
could be done in time to get the numbers 3821 and 3822. My estimate is 
that those numbers will be reached in about 23 months. That should give 
us enough time to work on them, if we started now. :-)
Permalink | Reply | 1 comment |
headers
Tony Hansen | 16 Aug 2002 21:28
Picon
Favicon

Re: drums2


In ietf-822, I think we're coming to the conclusion that it IS time to 
open 2821 and 2822 up again. It has been suggested that 2822 is ready to 
move to draft standard, but 2821 has too many needed changes to let it 
do so at this time.

And it is not clear whether a working group is required to do this work.

	Tony Hansen
	tony <at> att.com

Tony Hansen wrote:
> 
> [I recently posted the following query in ietf-822. I should have posted 
> it here as well. - Tony]
> 
> 2821/2822 are "Proposed Standards" and have been out for 1.5 years now. 
> What will it take to move them forward to Draft Standard? We've had 
> considerably longer than 1.5 years to get operational experience with 
> them, and I KNOW that there are lots of interoperational instances of each.
> 
>     Tony Hansen
>     tony <at> att.com
> 
> P.S. If 2821 and 2822 need to be reissued, it might also be nice if they 
> could be done in time to get the numbers 3821 and 3822. My estimate is 
> that those numbers will be reached in about 23 months. That should give 
> us enough time to work on them, if we started now. :-)
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Henningsen | 17 Aug 2002 12:19
Picon

Re: clarification re 2821, s4.1.4


ehall <at> ehsco.com (Eric A. Hall)  wrote on 16.08.02 in <3D5D2105.30001 <at> ehsco.com>:

>  | 4.1.4 Order of Commands
>
>  | An SMTP server MAY verify that the domain name parameter in the EHLO
>  | command actually corresponds to the IP address of the client.
>  | However, the server MUST NOT refuse to accept a message for this
>  | reason if the verification fails: the information about verification
>  | failure is for logging and tracing only.
>
> There are two possible ways to read that.
>
> The first way says that a legitimately-formed identifier cannot be
> refused, even if it is verified as wrong. This prevents me from rejecting
> sessions which provide my own domain name in the identifier.
>
> The other way of reading it says that an identifier which has been
> verified as wrong can be rejected.

I do not see how you can justify that reading, in light of the standard  
explicitely disclaiming it.

> Which is the intended interpretation? and can we get a clarification when
> this is revisited.

The clarification is right there in your quote of the standard. It seems  
completely unambiguous to me.

MfG Kai
(Continue reading)

Permalink | Reply | 27 comments |
headers
Kai Henningsen | 17 Aug 2002 12:34
Picon

Re: Keywords for "SMTP Service Extension for Content Negotiation"


ned+ietf-smtp <at> mrochek.com  wrote on 13.07.02 in <01KK1HVAM6PU000O32 <at> mauve.mrochek.com>:

> I think this is a fine piece of theoretical analysis which unfortunately has
> no applicability to the real world. In the real world directory/database
> systems that let sites provide Internet-wide access to information about
> their users do not deploy.
>
> I'm not sure why this is the case, and indeed I'm fairly sure that there is
> no good reason for it, but a vast tract of experience tells me it for-sure
> is the case. (Now is not the time to get into whys in more detail.)

I'm pretty sure that *one* important reason is that a "directory service"  
actually serves two rather distinct functions, and trying to do both with  
the same protocol works fine in an intranet but is insane in the Internet.

Those two functions are

(1) Find out attributes of a particular user (this seems to be what RESCAP  
does)

(2) Search for a particular user matching some conditions about his  
attributes ("Who is the CEO for Apple?" "Give me a list of all people at  
Microsoft named John Smith")

Note that the first does not necessarily (depending on protocol design)  
give you any method to, for example, locate valid user addresses to spam.  
The second, OTOH, does so by design.

Obviously, you may (in the Internet, as opposed to an intranet) want to be
(Continue reading)

Permalink | Reply | 0 comments |

Gmane