You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Andrzej Rusin (JIRA)" <se...@james.apache.org> on 2012/07/20 12:38:33 UTC

[jira] [Created] (JAMES-1427) DoS scenario(s) in SMTP server

Andrzej Rusin created JAMES-1427:
------------------------------------

             Summary: DoS scenario(s) in SMTP server
                 Key: JAMES-1427
                 URL: https://issues.apache.org/jira/browse/JAMES-1427
             Project: JAMES Server
          Issue Type: Bug
          Components: SMTPServer
    Affects Versions: 3.0-beta3
            Reporter: Andrzej Rusin


1. SMTP server allows unlimited number of invalid commands, which may waste network bandwidth.
2. The invalid commands go straight to the logs with level INFO, which can easily fill up the server disk.

Additionally:
3. After the max message size is reached, the SMTP server denies the message, but client keeps sending, which makes the remaining part of the message go straight to the log because of 2.

Ideas to fix:
A. Do not log more than N invalid commands per connection - solve 2,
B. Drop connection after Nth (consecutive?) invalid command - solve 1 and 2,
C. (This one is questionable) Drop the connection after max message size is reached - solve 3

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


[jira] [Commented] (JAMES-1427) DoS scenario(s) in SMTP server

Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
    [ https://issues.apache.org/jira/browse/JAMES-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420677#comment-13420677 ] 

Stefano Bagnara commented on JAMES-1427:
----------------------------------------

+1 for A and B
I don't like too much C because this way the client is not "aware" of the real error and is going to get it as a temporary network error and retry. Instead if you let it send the whole file and at the end you give it a permanent error it will stop trying. So it is better to receive and /dev/null 100MB once than receive 10 MB and disconnect for a dozen attempts in 5 days.

                
> DoS scenario(s) in SMTP server
> ------------------------------
>
>                 Key: JAMES-1427
>                 URL: https://issues.apache.org/jira/browse/JAMES-1427
>             Project: JAMES Server
>          Issue Type: Bug
>          Components: SMTPServer
>    Affects Versions: 3.0-beta3
>            Reporter: Andrzej Rusin
>
> 1. SMTP server allows unlimited number of invalid commands, which may waste network bandwidth.
> 2. The invalid commands go straight to the logs with level INFO, which can easily fill up the server disk.
> Additionally:
> 3. After the max message size is reached, the SMTP server denies the message, but client keeps sending, which makes the remaining part of the message go straight to the log because of 2.
> Ideas to fix:
> A. Do not log more than N invalid commands per connection - solve 2,
> B. Drop connection after Nth (consecutive?) invalid command - solve 1 and 2,
> C. (This one is questionable) Drop the connection after max message size is reached - solve 3

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org