Re: odd behavior in enforcing of message size limits

[Matti Aarnio <mea@nic.funet.fi>]

> Tom Samplonius <tom@uniserve.com> writes:
> >   Allowing the DATA command makes sense.  The remote host wouldn't see a 
> > DATA command failing, and the message would be input as SMTP commands.   
> > Better to let DATA command succeed, and drain rest of the buffer, and 
> > then throw it away.
> 
> The PIPELINING specification only permits the DATA command as the last
> command in a group.  The client isn't permitted to pipeline the
> message, it must wait for the 3xx reply from the server.  In my
> opinion, the best behavior would be for the SMTP server to cause the
> DATA command to immediately fail.

	It should, if there are no valid recipients it does complain,
	but apparently I never thought of having failing "MAIL FROM:"..

> If you're interested in pipelining the message, I'd suggest looking at
> the CHUNKING extension of RFC 1830.

	Pardon me, but how does the PIPELINING step in with CHUNKING ?

	The thing that PIPELINING gives is ability to "throw to the pipe"
	all of the initial address headers:
		MAIL FROM:<...>
		RCPT TO:<...>
		RCPT TO:<...>
		...
		RCPT TO:<...>
		DATA
	Now instead of waiting the half-duplex handshake at each line,
	the SMTP-client waits for all of the reports after it has sent
	the "DATA" command, and has flushed possible stdio buffers to
	the connection  (thats how I do it at ZMailer SMTP-client).

	Now if we add this BDAT mode ( = chunking ? )
	.... mumble mumble (reading the RFC) ... Oh, I see:
	"When streaming, the receiver SMTP must accept, and discard
	 additional BDAT chunks after the failed BDAT".. (until the
	 "BDAT nn LAST", I suppose..)

	I don't see actual use for this, EXCEPT with BINARYMIME, but
	implementing a receiver for it should be rather trivial anyway..
	(Optimizing it is another matter..)   Will you test it, John ?

	And by the way:  utu.fi mailhost has not talked with any
	system implementing CHUNKING keyword at EHLO responce during
	the last 10 (or so) days.  (nic.funet.fi does not anymore
	log outgoing sessions -- 1.2 GB in a week was a bit too much;
	admittedly it was due to some misbehaving machine, and over-
	eager retry ... -- That linux kernel sendmail locking error
	fury a month ago..)
 
> -- 
> _.John G. Myers		Internet: jgm+@CMU.EDU
> 			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

	/Matti Aarnio <mea@nic.funet.fi>