Stephen Gran wrote:
> On Tue, Nov 07, 2006 at 03:41:02AM +0800, W B Hacker said:
>> Have been unable to find any examples of code that would allow one to cause Exim
>> to issue the smtp 'RSET' command, specifically during the acl_smtp_data policy
>> acl's.
>>
>> Perhaps it is trivial, and simply has not often been done.
>>
>> Does anyone know if this is possible with existing acl's?
>
> I don't think that's a valid use case, according to my understanding of
> the RFCs. The server does not issue commands, the client does. Unless
> I'm not understanding you?
The intent is to determine experimentally, the 'real', not theoretical, response
of a submitting client [1], if/as/when the server with which it has estabished a
connection were to issue a 'RSET'. More accurately, an unexpected RSET.
Specification sez:
==================================================================================
4.1.1.5 RESET (RSET)
This command specifies that the current mail transaction will be
aborted. Any stored sender, recipients, and mail data MUST be
discarded, and all buffers and state tables cleared. The receiver
MUST send a "250 OK" reply to a RSET command with no arguments. A
reset command may be issued by the client at any time. It is
effectively equivalent to a NOOP (i.e., if has no effect) if issued
immediately after EHLO, before EHLO is issued in the session, after
an end-of-data indicator has been sent and acknowledged, or
immediately before a QUIT. An SMTP server MUST NOT close the
connection as the result of receiving a RSET; that action is reserved
for QUIT (see section 4.1.1.10).
Since EHLO implies some additional processing and response by the
server, RSET will normally be more efficient than reissuing that
command, even though the formal semantics are the same.
There are circumstances, contrary to the intent of this
specification, in which an SMTP server may receive an indication that
the underlying TCP connection has been closed or reset. To preserve
the robustness of the mail system, SMTP servers SHOULD be prepared
for this condition and SHOULD treat it as if a QUIT had been received
before the connection disappeared.
Syntax:
"RSET" CRLF
====================================================================================
Nothing may come of this, but paragraph 3 has one wondering just what is
actually coded into the real-world implementations.
Thanks
Bill
[1] Guesswork at this point, but one might surmise that 'proper' MTA submitting
traffic to another MTA in submission-client mode are likely to ignore an
unexpected RSET, ELSE tally an smtp sync error, and/or tally a nonmail command,
and (at some point) potentially drop the connection on the basis of sync errors
or excess non-mail commands.
Some spambots *may* handle this differently, which is "To Be Determined'.
