[Top] [All Lists]

Re: refuse-reject SMTP multi-lines replies

2008-04-08 04:31:29

Дилян Палаузов wrote:

Hi all,

Hi Дилян,

Section 2.1.2 of draft-ietf-sieve-refuse-reject-06 speaks about how to not-accpept a message (Action ereject, Rejecting a message at the SMTP/LMTP protocol level).

It might happen, that the ereject's parameter is longer than 512 characters, or it can be multilined (e.g
  ereject "First line
  second line";
). The line terminators within the script are not necessary CR and LF, it can be only CR or only LF. (at least cyrus' timsieved allows only LF).

RFC 5228 only allows for CRLF as end-of-line markers, so this document shouldn't care about bare CRs or bare LFs used in scripts.

Do you think it is appropriate to specify in the draft, when it comes to SMTP, one of:

- If the ejerect's parameter consists of several lines, that lines are merged into one single line. This line is split in portions of about 500 characters (the number comes from RFC 2821, Section, "reply line"; subtracting from 512 the length of "250"/"550" code and the lengtt of enhanced status codes), when possible no word is hyphenated. Each portion of the so created string-list is returned on a separate smtp line in a multi-line SMPT reply;

- (If the ereject's parameter consists of several lines, the line separators are replaced with CRLF.?)

As per RFC 5228, this statement is not needed.

The SMTP makes multi-line reply, giving every line of the reason-parameter on as a separate line in the SMTP dialog. (this leaves unhandled the case, when a single line is longer than 512);

- If the ereject's parameter is longer than 500 characters, it is truncated to 500 characters.

Personally, I don't like the 3rd choice. I would prefer to do a hybrid of your proposal 1 and proposal 2: try to preserve existing CRLFs in the text, but insert additional ones, if any single line is longer than 500 characters.

Of course with the usual sense of "Shall/Must/Might/" etc. My question is more if the draft shall deal with very-long-multi-lined ereject-parameters, than what to do exactly.

<Prev in Thread] Current Thread [Next in Thread>