@alex: "Hi,
We are working with an smtp multiplexor that takes a high volume of
inbound mail connections and send them to a pool of qmail-smtpd
connections. This means that multiple emails from different sources will
be pipelined through a single smtp connection with qmail-smtpd.
While testing, it was discovered that sending a RSET does not reset the
smtp authentication state. i.e.:
220 vmwarex86 ESMTP
ehlo dev
250-vmwarex86
250-PIPELINING
250-8BITMIME
250-SIZE 0
250 AUTH LOGIN PLAIN CRAM-MD5
auth plain AGF3ZXhAYWxleC5rcm9obi5vcmcAMXEydzNlNHI=
235 ok, go ahead (#2.0.0)
rset
250 flushed
auth plain AGF3ZXhAYWxleC5rcm9obi5vcmcAMXEydzNlNHI=
503 you're already authenticated (#5.5.0)
This is using the smtp auth patch from:
<url>
What are your thoughts, should RSET reset the auth state as well? I can
put together a patch for this, just not sure if it is "the right thing
to do". =)
Cheers,
Alex
Alex Krohn <email_address>
Posted automagically by a mail2news hunterapril@example.com e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @qmail: "<quote>
[...]
Not true:
  4. The AUTH command
    [...]
    Restrictions:
      After an AUTH command has successfully completed, no more AUTH commands
      may be issued in the same session.  After a successful AUTH command
      completes, a server MUST reject any further AUTH commands with a 503
      reply.
"no more AUTH commands may be issued in the same session" is very clear; it
also implies that RSET doesn't clear AUTH state.
Charles
Charles Cazabon                               <email_address>
Read <url>
My services include qmail consulting.  See <url> for details.
Posted automagically by a mail2news hunterapril@example.com e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @alex: "Hi Charles,
<quote>
Thanks for the pointer, exactly what I was looking for. =) 
Cheers,
Alex
Alex Krohn <email_address>
Posted automagically by a mail2news hunterapril@example.com e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @feh: "Hi,
<quote>
I rather should say: "RFC 2554 makes no *explicit* statement about this".
You referring to an implicit declaration; which *unfortunately* may lead to
some ambiguity. As I said in my SMTP Auth tutorial
(<url> RFC 2554 and RFC 2821 are to
some extend incompatible or contradictory. To repeat RFC 2821:
"2.3.6 Buffer and State Table
   SMTP sessions are stateful, with both parties carefully maintaining a
   common view of the current state.  In this document we model this
   state by a virtual "buffer" and a "state table" on the server which
   may be used by the client to, for example, "clear the buffer" or
   "reset the state table," causing the information in the buffer to be
   discarded and the state to be returned to some previous state."
For STARTTLS this behavior is clarly enforced; but not for SMTP Auth.
In common sense (or in my understanding), a SMTP session begins with a
HELO/EHLO or MAIL FROM and ends with a QUIT or a RESET; rather, the TCP
connection on port 25 can last longer and can be reused for a new SMTP
session.
Just my 2cents.
regards.
eh.
Dr. Erwin Hoffmann | FEHCom | <url>
Wiener Weg 8, 50858 Cologne | T: 815-521-8520 | F: ...24
Posted automagically by a mail2news hunterapril@example.com e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @cweimann: "<quote>
I'm having exactly the opposite problem with the spamcontrol patch ( 2.4.15 )
from <url>  With that patch RSET does reset the authentication
and that breaks Eudora 7.  For some bizarre reason Eudora 7 issues an RSET
after it successfully authenticates but before sending the message.
Posted automagically by a mail2news hunterapril@example.com e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @fabiobusatto: "<quote>
4. The AUTH command
     Restrictions:
         After an AUTH command has successfully completed, no more AUTH
         commands may be issued in the same session.  After a successful
         AUTH command completes, a server MUST reject any further AUTH
         commands with a 503 reply.
         The AUTH command is not permitted during a mail transaction.
And from RFC 2821 ():
3.9 Terminating Sessions and Connections
   An SMTP connection is terminated when the client sends a QUIT
   command.  The server responds with a positive reply code, after which
   it closes the connection.
   An SMTP server MUST NOT intentionally close the connection except:
   -  After receiving a QUIT command and responding with a 221 reply.
   -  After detecting the need to shut down the SMTP service and
      returning a 421 response code.  This response code can be issued
      after the server receives any command or, if necessary,
      asynchronously from command receipt (on the assumption that the
      client will receive it after the next command is issued).
   In particular, a server that closes connections in response to
   commands that are not understood is in violation of this
   specification.  Servers are expected to be tolerant of unknown
   commands, issuing a 500 reply and awaiting further instructions from
   the client.
This, in my opinion, states that AUTH should not be reset (and so permitted
again) after a RSET command.
Bye
Fabio
Posted automagically by a mail2news hunterapril@example.com e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @fabiobusatto: "<quote>
The problem is that session is not mapped on transaction nor connection.
So, the dilemma: is the session the same as transaction, or the same as
connection, or nothing of the above?
This is also my point of view, even if reached with a different way.
I think you're not fully right.
The section is "Terminating Sessions and Connections", but in the content
it explain only how to terminate connections.
So, I think there are only three options:
1. the RFC is incomplete
2. the section title is wrong
3. sessions are the same as connections
I chose 3, and so I should intend that sessions and connections are the
same thing.
By the way I think it's not so important, the correct behavior is that
the RSET command should not invalidate successful AUTH commands.
Bye
Fabio
Posted automagically by a mail2news hunterapril@example.com e.V.
Please direct questions, flames, donations, etc. to <email_address>"
    @qmail: "<quote>
[...]
No.
Yes.
No.  RSET only resets the current message state (envelope sender, envelope
recipient(s)) prior to the DATA command.  It does not, for example, clear the
state set up by the HELO or EHLO commands.
Charles
Charles Cazabon                               <email_address>
Read <url>
My services include qmail consulting.  See <url> for details.
Posted automagically by a mail2news hunterapril@example.com e.V.
Please direct questions, flames, donations, etc. to <email_address>"
{'source': 'USENET', 'other_information': '{"reply_count": 7, "forum_name": "muc.lists.qmail.20140124.mbox"}', 'file': 'data/output/usenet-muc.lists.parquet'}