Bruce Lilly | 1 Feb 15:54 2005
Picon

Re: I-D ACTION:draft-malamud-subject-line-00.txt (fwd)


On Mon January 31 2005 16:38, Carl Malamud wrote:

> Comments are most welcome on this first draft.

In order of presentation in the draft:

Section 2 discussion of encoded-words (top of page 5) is missing
RFC 2231 language identifiers (RFC 2047 is amended by errata (and
one erratum itself has an error, corrected by another erratum) and
by RFC 2231 (which also has errata)). RFC Errata may be found at
the RFC Editor web site: http://www.rfc-editor.org/cgi-bin/errata.pl

Same section: mention should probably be made that encoding indication
characters are case-insensitive.

Same section: re. "resort to a variety of strategies", note that
conforming implementations are limited to the actions specified in
RFC 2047 section 7.

Section 5 is where things go really bad.  Section 4 correctly points
out the fact that the Subject header field is intended for human
consumption, and is therefore unsuitable for label cruft. However
wrong such cruft is, the section 5 recommendation to put similar
cruft in RFC [2]822 comments ("human readable informational text";
RFC 2822 section 3.2.3, also "ignored by the formal semantics";
STD 11, a.k.a. RFC 822, section 3.4.3) in Received fields ("intended
for humans"; STD 3, a.k.a. RFC 1123 section 5.2.8) is triply wrong.

(Continue reading)

Bruce Lilly | 1 Feb 04:52 2005
Picon

Re: revised Email Architecture draft


On Sun January 30 2005 01:47, Frank Ellermann wrote:
> > that happens not to match the intended original use (prior
> > to DSNs) for delivery trouble notifications.
> 
> IBTD.  The original use of a "Return-Path" was a reverse path,
> the same path backwards.

Even if one goes back to the original SMTP specification,
RFC 788, the purpose is "to return non-delivery notices".

For a direct message from an individual to a set of
recipients, sending such notices to the originating
individual makes sense. But for cases such as a message
sent via a mailing list expander (introduced in RFC 822),
the non-delivery notices would simply be annoying if sent
to the message author, and can only be usefully acted upon
if sent to the mailing list maintainer.

So for early SMTP documents, which didn't consider mailing
lists as we now know them (those documents discuss expansion
of lists by assuming that the originator would issue EXPN
commands, collect the responses, then issue corresponding
multiple RCPT TO commands in a subsequent session), the
originator would appear in the return path.  But that has
turned out to be impractical (due to list maintenance
issues as well as the fact that many sites have chosen to
violate RFC 821 by disabling the EXPN command (subsequently
doing so was sanctioned by RFC 1123)).  

(Continue reading)

Carl Malamud | 2 Feb 00:51 2005

Re: I-D ACTION:draft-malamud-subject-line-00.txt (fwd)


Hi -

> Section 2 discussion of encoded-words (top of page 5) is missing
> RFC 2231 language identifiers (RFC 2047 is amended by errata (and
> one erratum itself has an error, corrected by another erratum) and
> by RFC 2231 (which also has errata)). RFC Errata may be found at
> the RFC Editor web site: http://www.rfc-editor.org/cgi-bin/errata.pl
> 

I'll add the language identifiers pointer ... thanks.  I'm not sure
about pointers into the various errata ... I may just make those
part of the footnote.  

> Same section: mention should probably be made that encoding indication
> characters are case-insensitive.
> 

Not central to the point, but I'll point that out.   Thanks.

> Same section: re. "resort to a variety of strategies", note that
> conforming implementations are limited to the actions specified in
> RFC 2047 section 7.

Thanks ... I'll make that clearer.

> 
> Section 5 is where things go really bad.  Section 4 correctly points
> out the fact that the Subject header field is intended for human
> consumption, and is therefore unsuitable for label cruft. However
(Continue reading)

Dave Crocker | 2 Feb 07:55 2005
Picon

Re: revised Email Architecture draft


>  Even if one goes back to the original SMTP specification,
>  RFC 788, the purpose is "to return non-delivery notices".

right.

>  But for cases such as a message
>  sent via a mailing list expander (introduced in RFC 822),
>  the non-delivery notices would simply be annoying if sent
>  to the message author, 

it was as irritating then, as it is now.

>  So for early SMTP documents, which didn't consider mailing
>  lists as we now know them (those documents discuss expansion

nevertheless, mailing list mechanisms, of the same flavor as we have today, were in operation at the time
smtp was written.

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net

Richard Dawe | 2 Feb 11:18 2005

Pipelining vs. multiple failure codes


Hello.

The RFC on pipelining (RFC2920
<ftp://ftp.rfc-editor.org/in-notes/rfc2920.txt>) doesn't discuss what to
do on a temporary failure on, say, MAIL FROM. Consider the following
sequence:

  MAIL FROM
  4xx
  RCPT TO
  5xx (no MAIL FROM => RCPT TO not valid)
  DATA
  5xx (no recipients)

What should the SMTP client conclude in this case? Should it bounce the
message or try again later?

Is the intent that the DATA command returns the error that the client
should take notice of?

Thanks, regards,

--

-- 
Richard Dawe
Software Engineer - Mail Engine
MessageLabs Ltd., UK

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
(Continue reading)

Tony Finch | 2 Feb 12:13 2005
Picon

Re: Pipelining vs. multiple failure codes


On Wed, 2 Feb 2005, Richard Dawe wrote:
>
> The RFC on pipelining (RFC2920
> <ftp://ftp.rfc-editor.org/in-notes/rfc2920.txt>) doesn't discuss what to
> do on a temporary failure on, say, MAIL FROM.

The pipelining spec is hopelessly wooly.

> Consider the following sequence:
>
>   MAIL FROM
>   4xx
>   RCPT TO
>   5xx (no MAIL FROM => RCPT TO not valid)
>   DATA
>   5xx (no recipients)
>
> What should the SMTP client conclude in this case? Should it bounce the
> message or try again later?

It should try again later. The client should interpret the responses as if
it hadn't pipelined the commands. The first error is the important one.

(Outlook gets this grievously wrong and will uselessly report to users
"Valid RCPT command must precede DATA". Not advertising PIPELINING doesn't
help because it pipelines anyway.)

Tony.
--

-- 
(Continue reading)

Richard Dawe | 2 Feb 14:44 2005

Re: Pipelining vs. multiple failure codes


Hello.

On Wed, 2005-02-02 at 11:13, Tony Finch wrote:
> On Wed, 2 Feb 2005, Richard Dawe wrote:
> >
> > The RFC on pipelining (RFC2920
> > <ftp://ftp.rfc-editor.org/in-notes/rfc2920.txt>) doesn't discuss what to
> > do on a temporary failure on, say, MAIL FROM.
> 
> The pipelining spec is hopelessly wooly.

Maybe it's worth doing an update to the spec, to make it clearer?

> > Consider the following sequence:
> >
> >   MAIL FROM
> >   4xx
> >   RCPT TO
> >   5xx (no MAIL FROM => RCPT TO not valid)
> >   DATA
> >   5xx (no recipients)
> >
> > What should the SMTP client conclude in this case? Should it bounce the
> > message or try again later?
> 
> It should try again later. The client should interpret the responses as if
> it hadn't pipelined the commands. The first error is the important one.

Good, that's what I was hoping.
(Continue reading)

Tony Finch | 2 Feb 15:14 2005
Picon

Re: Pipelining vs. multiple failure codes


On Wed, 2 Feb 2005, Richard Dawe wrote:
>
> > The pipelining spec is hopelessly wooly.
>
> Maybe it's worth doing an update to the spec, to make it clearer?

Probably. There has been a fair amount of discussion about this on the
Exim list, because Exim is unusually strict about when pipelining is
permitted (which turns out to be a useful defence against ratware).
Matthew Byng-Maddick did a good analysis of the problems and ambiguities:

http://www.exim.org/mailman/htdig/exim-users/Week-of-Mon-20040419/msg00287.html
http://www.exim.org/mailman/htdig/exim-users/Week-of-Mon-20040426/msg00007.html
(the thread got split across the week boundary)

I also found this when Googling, about pipelined close:

http://mail.adeptech.com/pipermail/sidewinder/2003-July/001145.html

Tony.
--

-- 
f.a.n.finch  <dot <at> dotat.at>  http://dotat.at/
FAEROES: WEST OR SOUTHWEST 6 TO GALE 8, DECREASING 5 FOR A TIME. RAIN OR
SHOWERS. MODERATE OR GOOD.

Matti Aarnio | 2 Feb 15:58 2005
Picon
Picon

Re: Pipelining vs. multiple failure codes


On Wed, Feb 02, 2005 at 01:44:09PM +0000, Richard Dawe wrote:
> Hello.
> 
> On Wed, 2005-02-02 at 11:13, Tony Finch wrote:
> > On Wed, 2 Feb 2005, Richard Dawe wrote:
> > >
> > > The RFC on pipelining (RFC2920
> > > <ftp://ftp.rfc-editor.org/in-notes/rfc2920.txt>) doesn't discuss what to
> > > do on a temporary failure on, say, MAIL FROM.
> > 
> > The pipelining spec is hopelessly wooly.
> 
> Maybe it's worth doing an update to the spec, to make it clearer?

I found it very clear in overall, but at the same time
very challenging to implement efficiently and correctly
at the client side.

More so as I wanted to present some resemblance of context
in error reports, but not present _all_ of the context e.g.
50 RCPTs of which one is failing does not need to know about
49 successfull ones.

Server side is trivialish to implement even without buffering
optimizations ( = flush reply buffers to network only at sync-
points )  and fairly simple with them.  Flush replies always
when the input command stream is empty at the start of input
verb line collection.  Let them accumulate otherwise.  Plus
explicitely flush at PIPELINING-defined explicite sync points.
(Continue reading)

Jeff Stephenson | 2 Feb 19:28 2005
Picon

RE: Pipelining vs. multiple failure codes


> -----Original Message-----
> From: owner-ietf-smtp <at> mail.imc.org
[mailto:owner-ietf-smtp <at> mail.imc.org]
> On Behalf Of Tony Finch
> Sent: Wednesday, February 02, 2005 3:14 AM
> 
> (Outlook gets this grievously wrong and will uselessly report to users
> "Valid RCPT command must precede DATA". Not advertising PIPELINING
doesn't
> help because it pipelines anyway.)

Actually, Outlook *never* pipelines - if this happens, it's just a plain
bug.  What version of Outlook does this happen in?  I suspect you won't
find it happening in Outlook 2003.

-- jeff

Jeff Stephenson
Outlook Development 


Gmane