Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: [email protected] [mailto:ietf-dkim-
>> [email protected]] On Behalf Of Mark Delany
>> Sent: Thursday, October 29, 2009 9:42 AM
>> To: [email protected]
>> Cc: IETF DKIM WG
>> Subject: Re: [ietf-dkim] DKIM on envelope level
>>
>> If the proposal is an attempt to reduce SMTP bandwidth, which is
>> becoming a vanishingly small part of Internet traffic for most sites
>> anyway, then stopping after DATA doesn't help as your OS will have
>> likely received a socket buffer full of data, even if the application
>> doesn't read it. So it might make you feel good, but it doesn't reduce
>> the bytes coming down the line consequentially.
>
> Do you mean the server's side of the connection will have buffer data in it?
> That would mean the client sent DATA<CR><LF> followed by header/body
> information, possibly even in the same packet, without waiting for the reply
> from DATA. The server could drop the connection outright in that case for
> violating SMTP rules, even with support for PIPELINING which as I recall
> requires a synchronization point at DATA. This wouldn't reduce pipe
> bandwidth consumption (if that's the goal) but it could reduce resource
> consumption at MTAs.
Not always.
If a HALF CLOSE is done
shutdown(socket,SD_SENT)
there will be some remaining buffer. Half Close is the recommended way
to shutdown a TCP session.[1]
It could be just QUIT<cr><lf> remaining in the buffer.
You can test this now but creating a DATA shim that receives the
payload but delays for 3-5 minutes before a response. The Server can
wait for a client connection drop and read the remaining buffer.
We use this to resolve the SMTP Specification NO-QUIT-CANCEL found in
sites that have lengthy DATA filtering scripts. The client did its
part of sending the data and is waiting for the server response. It
doesn't come, so it issues a QUIT and drops the socket. This is
detectable. The server should see if a QUIT was issued before
cancelling the transaction
The point is, that the client is not designed to wait in sending
partial data via SMTP state machine. The SMTP server can not drop
because there is an implicit 451 reply code interpretation by the
client [2].
--
HLS
[1] TCP/IP Illustrated Volume 1, The Protocols. Pages 233, 238.
[2] RFC 5321 Section 3.8. Terminating Sessions and Connections
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
