ietf-smtp
[Top] [All Lists]

Re: Sender's Declaration of Identity

2005-05-17 09:44:34

At 11:44 AM 5/17/2005 -0400, Bruce Lilly wrote:
On Tue May 17 2005 11:07, David MacQuigg wrote:
> > At 07:19 AM 5/17/2005 -0400, Bruce Lilly wrote:
>
> >On Sun May 15 2005 21:23, David MacQuigg wrote:
> > > My main concern is backward compatibility.  Here are the
> > > relevant paragraphs:
> > >
> > >     EHLO  mailserver7.my-company.com
> > >     ID  mycompany.com
> > >     MAIL FROM: bob(_at_)sales(_dot_)my-company(_dot_)com
> > >
> > >     ...
> > >
> > >     The proposed syntax will require extension of SMTP standard [RFC-
> > > 2821] and changes in current MTA software and practices. See section
> > >     7. IANA Considerations.
> > >
> > >     MTA software will need to be enhanced and deployed at sites that
> > >     provide email authentication.  To minimize upgrade efforts these
> > > changes should be bundled with the upgrade to enable authentication.
> > >
> > >     Receivers that don't recognize the ID command should return a Reply
> > >     Code 500 COMMAND UNRECOGNIZED.
> >[...]
> >
> >This is NOT backward compatible.  See separate message on ietf-smtp for
> >an overview and pointers to detailed references.
>
> Bruce, I appreciate your general advice, and I do read it carefully.  I'll
> need something more specific in this case, however.
>
> I assume from the position of your comment above, that you are objecting to
> the expectation that Reply Code 500 could be a normal and harmless
> response.

No, the objection is to sending an extended command that does not have a
corresponding ESMTP keyword extension in the EHLO response.  You need to
establish such a keyword and stipulate that clients MUST NOT send an ID
command unless that keyword is offered in the server's EHLO response. In
that case "Receivers that don;t recognize the ID command" never arises.
That is the established ESMTP negotiation mechanism, and if you don't
play by those rules, your proposal will go nowhere.

Sorry to be breaking the rules. I wanted to find out first if there is some fundamental problem before spending a lot of time on documentation.

I've re-written the IANA section.

IANA Considerations

The proposed syntax will require an SMTP service extension for a new ID command.

           C: EHLO example.com
           S: 250-host.com, welcome
           S: 250-SIZE ETRN ID
           S: 250-AUTH LOGIN
           S: 250 HELP

I understand there is a lot more documentation still needed. I can do that if and when it gets to the RFC stage.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *