Regarding SMTP Message specification syntax ...

Re: Regarding SMTP Message specification syntax ...

dhananjay wrote:
> Hi,
>     If user enters "." or "CR" as a first character for a response to 
> DATA command. Then, should that be treated as illegal message format ?
>     I went through RFC822 in search of this, but could not gain much 
> from "Message specification section 4.1" with regards to this issue.
>     It would be really great, if I can get some pointers to resolve this 
> issue.

If you mean a completely empty message, i.e. no body and no header, then that
is not legal. RFC 822 section 4.1 gives the message syntax; date, originator
(From), and at least one recipient (To, Cc, Bcc) header fields are mandatory:

      message     =  fields *( CRLF *text )       ; Everything after
                                                  ;  first null line
                                                  ;  is message body

      fields      =    dates                      ; Creation time,
                       source                     ;  author id & one
                     1*destination                ;  address required
                      *optional-field             ;  others optional

RFC 2822 is somewhat more liberal; it does not require a recipient field.
See the table in RFC 2822 section 3.6.

Re: Regarding SMTP Message specification syntax ...

dhananjay <at> zlemail.com writes:
> Hi,
>     If user enters "." or "CR" as a first character for a response to DATA
> command. Then, should that be treated as illegal message format ?

You're talking about the SMTP stream now, aren't you? You should treat 
as if no DATA command has been sent at all. See RFC 1854 section 2.1, 
fourth paragraph.

>     I went through RFC822 in search of this, but could not gain much from
> "Message specification section 4.1" with regards to this issue.

Please don't read 822 any more. 2821/2822 are the main current RFCs

--Arnt

Re: Regarding SMTP Message specification syntax ...

Arnt Gulbrandsen <arnt <at> gulbrandsen.priv.no> wrote:

> Please don't read 822 any more. 2821/2822 are the main current RFCs

Unless you're writing a mail user agent and wondering whether you need
to preserve the upper/lower case information in any of the fields in a
message header.  RFC 2822 says nothing about preserving case, but 822
tells exactly which fields do and do not need case preservation (in
section 3.4.7).

I don't know if that's the only omission; I haven't done a thorough
search.

Of course 2822 contains new information that you don't want to miss
(like deprecations of some syntax), so I recommend reading both.

AMC

Re: Regarding SMTP Message specification syntax ...

Adam M. Costello writes:
> Arnt Gulbrandsen <arnt <at> gulbrandsen.priv.no> wrote:
>
>>  Please don't read 822 any more. 2821/2822 are the main current RFCs
>
> Unless you're writing a mail user agent and wondering whether you need 
> to preserve the upper/lower case information in any of the fields in 
> a message header. RFC 2822 says nothing about preserving case, but 
> 822 tells exactly which fields do and do not need case preservation 
> (in section 3.4.7).

I beg to differ. The rules in RFC822 3.4.7 may be complete, but they're 
not necessarily descriptive of what a MUA needs to do. Try sending FroM 
and see how many receivers choke on it, expecting From. And if I read 
it correctly, 3.4.7 says localparts are case sensitive sometimes but 
generally not (the grammar notes "case-preserved"). The 3.4.7 rules 
don't seem practical for a MUA's addressbook lookup.

I agree that there might be more troublesome omissions in 2822. Is there 
a document editor for 3822 yet?

> I don't know if that's the only omission; I haven't done a thorough search.

Please post about each and every one as you run across them.

--Arnt

Re: Regarding SMTP Message specification syntax ...

Arnt Gulbrandsen <arnt <at> gulbrandsen.priv.no> writes:

>>     I went through RFC822 in search of this, but could not gain much from
>> "Message specification section 4.1" with regards to this issue.
>
> Please don't read 822 any more. 2821/2822 are the main current RFCs

RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
2822 is merely a Proposed Standard.

As for things lacking in RFC 2822; I wish the X-* headers could be
discussed, at least to explicitly acknowledge that they are no longer
the recommended solution to introduce new headers.

Re: Regarding SMTP Message specification syntax ...

> RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
> 2822 is merely a Proposed Standard.
> 
> As for things lacking in RFC 2822; I wish the X-* headers could be
> discussed, at least to explicitly acknowledge that they are no longer
> the recommended solution to introduce new headers.

they never were the recommended solution to introduce new header fields.

Re: Regarding SMTP Message specification syntax ...

Keith Moore <moore <at> cs.utk.edu> writes:

>> RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
>> 2822 is merely a Proposed Standard.
>> 
>> As for things lacking in RFC 2822; I wish the X-* headers could be
>> discussed, at least to explicitly acknowledge that they are no longer
>> the recommended solution to introduce new headers.
>
> they never were the recommended solution to introduce new header fields.

OK, replace "new header fields" with "user defined header fields"
then.  To me, they both result in the same thing, as any new header
field at some point in time would have been a user defined header
field during experiments, but perhaps you see a difference.

To turn this discussion into something potentially useful; do you
think a 2822bis (822tres?) should discuss X-* or not?  If so, what do
you think it should say?

Thanks,
Simon

Re: Regarding SMTP Message specification syntax ...

On Wed, 01 Oct 2003 15:59:27 +0200
Simon Josefsson <simon+ietf-822 <at> josefsson.org> wrote:

> Keith Moore <moore <at> cs.utk.edu> writes:
> 
> >> RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
> >> 2822 is merely a Proposed Standard.
> >> 
> >> As for things lacking in RFC 2822; I wish the X-* headers could be
> >> discussed, at least to explicitly acknowledge that they are no longer
> >> the recommended solution to introduce new headers.
> >
> > they never were the recommended solution to introduce new header fields.
> 
> OK, replace "new header fields" with "user defined header fields"
> then.  To me, they both result in the same thing, as any new header
> field at some point in time would have been a user defined header
> field during experiments, but perhaps you see a difference.

New fields don't have to be used in experiments before being defined. 

> To turn this discussion into something potentially useful; do you
> think a 2822bis (822tres?) should discuss X-* or not?  If so, what do
> you think it should say?

If 2822 is revised I think it should only contain minor clarifications
of the existing material.   The effort to revise 2822 should avoid 
opening up new cans of worms.

Re: Regarding SMTP Message specification syntax ...

Keith Moore writes:
> If 2822 is revised I think it should only contain minor clarifications 
> of the existing material.

2822 should be revised, bcause that's the only way to formally obsolete 822.

I agree that 2822 is good and that only very minor changes should be done.

--Arnt