[Top] [All Lists]

Re: RSET command - possible security loophole

2011-06-01 13:23:40

Peter Bowen wrote:
From: Ned Freed [mailto:ned(_dot_)freed(_at_)mrochek(_dot_)com]
I protested vehemently that the resulting security semantics would be a HUGE
mess. Just as one example, supppose the AUTH would have impacted the semantics
of the previous part of the transaction in some way, e.g., a recipient address
that looks successful but got silently blackholed because of the
lack of authorization.

But this would be allowed, correct? (Assuming no previous AUTH was sent)

C: MAIL FROM:<whoever@wherever>
S: 250 Go ahead, you unauthenticated thing you
C: RCPT TO:<highmucketymuck@wherever>
S: 559 Authorization failure, need to authenticate to send to this address
S: 250 State reset
C: AUTH blah blah blah
S: 250 OK, you're authorized now
C: RCPT TO:<highmucketymuck@wherever>
S: 250 OK, you're allowed to do that now

Once the RSET is issued, I would think the state it is not "during a
mail transaction".


Well, the RSET will clear the MAIL FROM. You need to basically restart the MAIL transaction. Your point is understood though.

Most of the time, this is more about authenticated relay that the sender or user is authorized to do. So if authorized relay is not established before MAIL is issued or at the connection level, there needs to be a reset or start at the top again.

RFC2554/RFC4954 both says its not permitted during the mail transaction.


    The AUTH command is not permitted during a mail transaction.

Fined tuned in 4954:

    The AUTH command is not permitted during a mail transaction.
    An AUTH command issued during a mail transaction MUST be
    rejected with a 503 reply.

I wish I was reviewing RFC4954 because I would of asked for clarification, i.e. after RCPT issues a 530.

   530 5.7.0  Authentication required

   This response SHOULD be returned by any command other than AUTH,
   EHLO, HELO, NOOP, RSET, or QUIT when server policy requires
   authentication in order to perform the requested action and
   authentication is not currently in force.

It doesn't not "prohibit" issuing AUTH at MAIL and RCPT. MAIL make sense because an AUTH can be issued after MAIL has a negative response (the transaction has not started). But after MAIL, a 530 negative response for RCPT should prohibit a AUTH if the sender/user has not be authorized.


Hector Santos