[Top] [All Lists]

Re: 3028bis open issue #2: unknown envelope-part names

2005-06-29 14:01:36

Alexandros Vellis <avel(_at_)noc(_dot_)uoa(_dot_)gr> writes:
Alexey Melnikov wrote:

I still think that an implementation should treat an unrecognized 
envelope part as an error. Scripts should not be using a feature without 
a proper require statement.

I don't feel strongly about my vote, and I'm not a guru of SMTP
protocols either, so as long as the 'auth' is added in the
clarification, that's fine with me too. 8-)

I think we have to choose among the following:

A) leave the behavior undefined if a script uses envelope-parts other
   than "from" and "to"
   CONS: such parts (ala "auth") effectively become undeclared, unnamed
         extensions; scripts can't depend on support; no way to test for
         support (e.g., in managesieve)
   PROS: breaks neither existing implementations nor existing scripts

B) require implementations to reject parts other than "from" and "to"
   unless declared via some new extension
   CONS: makes Cyrus implementation non-conforming; breaks scripts that
         haven't been updated to require the new extension
   PROS: <standard "declare before use" argument>, scripts using "auth"
         aren't portable anyway

C) require implementations to ignore all unknown parts, or maybe just
   CONS: breaks lots of implementations; script behavior could change if
         an implementation started recognizing new parts
   PROS: doesn't break existing scripts using "auth"

D) roll "auth" into the base-spec
   CONS: breaks lots of implementations; have to define what it means in
         implementations that don't have access to SMTP/LMTP AUTH info;
         why have an extension mechanism if we're not going to use it?
   PROS: doesn't break Cyrus implementation or scripts using "auth"

It sounds like you're suggesting (C), yes?  Do yo have any comments on
the pros and cons in the above list or the tradeoffs among them?

Philip Guenther