(cross posted as code change proposal at bottom)

Having had a quick look at the RFCs it looks like the 552 error should not
be sent until the final <crlf>.<crlf> has been received.

Looking at james code (SMTPHandler.java):

James recieves data command. Responds accordingly.
James starts receiving data. Once hit's maximum limit, an exception causes
james to send a 552 error (immediately).
Now, this is where i might be missing somthing, but James then seems to
return to reading commands, but as the state MESG_FAILED is set,
parseCommand skips logging, and doesnt return 500 error messages!

In terms of DOS, this seems ok, as once the mail hits the size limit, data
is no longer built into a mail. (so cant do OutOfMemory DOS)

Sure, you can use bandwidth, but you can do that anyway with lots of smaller
messages that will get accepted and use more CPU!

Assuming my understanding of the code and rfcs is correct, it means that
james enters a blackhole phase, where james basically does nothing until it
receives a proper smtp command, and then it doesnt get it's state reset,
which all seems wrong in light of the rfcs.

If i am right, it should:
Notice to size limit has been reached, and stop buffering the message.
Continue reading the message until <crlf>.<crlf> is reached
Send 552 error!
Reset state, and continue to accept other messages.

I think it should do this by:
Upon catching the size exception,
gobble away at the CharTerminatedInputStream (need to keep a reference to
this) until eof.
then continue as before, but:
Also, Get rid of MESG_FAILED state, and call resetState so we can allow the
parsing/logging/responses-to further commands/messages to work properly!

Does this make sense?

Daniel.




> -----Original Message-----
> From: Chris Hane [mailto:[EMAIL PROTECTED]
> Sent: 10 May 2005 18:53
> To: James Users List
> Subject: Re: Serious bandwidth begin consumed by James
>
>
>
>
> [EMAIL PROTECTED] wrote:
>
> >>I tested by:
> >>
> >>- I had two test servers both setup with james (Sender, Receiver)
> >>- I set the Receiver to a max message size of 7MB
> >>- I set the Sender to a max message size of 0MB (unlimited)
> >>- When I sent a 20MB file from Sender to Receiver I saw the
> >>following (very rough times from memory but I can repeat and
> >>get more accuruate timings if anyone cares.  (I don't really
> >>at this point since I really wanted to solve the bounce issue
> >>I was having originally).
> >>
> >>1. Receiver.smtp.log time 0 - connection accept and message
> >>started to be transmited 2. Receiver.smtp.log time 1 minute -
> >>message to large (552) 3. Sender.mailet.log time 3 minute -
> >>error message 552 message too large
> >>
> >>I made an assumption that message #2 on the Receiver
> >>generated the error message back to the Receiver; but based
> >>on what you said I assume this is informational that an error
> >>message will be sent once the message has been completely sent.
> >>
> >>However, wouldn't this behavior allow for a denial of service
> >>attack?
> >>Someone could repeatedly send large files and clog up my
> >>bandwidth......
> >>
> >>
> >
> >This behaviour simply double the bandwith used: once to receive
> the message,
> >once to send the bounce.
> >You can configure james to avoid creating the bounce or to
> create the bounce
> >with no message attached.
> >
> >
> hmm...
>
> Maybe I'm not fully understanding; but that is not what I am seeing.
>
> First, the Receiver email server should not "bounce" the email.  Is that
> correct?  Instead it sends back a 552 error code (I'm only dealing with
> the use case where the email exceeds the max message size ).
>
> Second, I have configured the Sender RemoteDelivery with a
> bounceProcessor and set the <attachment>none</attachment> option.
>
> What I am seeing is a log message on the Receiving Email server
> indicating that a message has exceeded max size and will send a 552
> error message.  I'm assuming it will only send the error code back via
> the connection and *not* the entire message.
>
> Once this error message (552) is written to the Receiving.smtp.log file,
> the Sending email server continues to send the email.  The send portion
> is not aborted.  When I look at ntop which shows me network traffic
> broken by IP address / direction (in/out) / and protocol, I confirm that
> the entire 20MB message is sent (Sender -> Receiver) and very little
> traffic (measured in KBs) is received (Receiver -> Sender).
>
> Also, the Receiver contains the mbox of the actual user sending the
> email so I would not expect double the bandwidth until the user actual
> downloads the email (but it still wouldn't be double since the
> bounceProcessor strips the attachment - which I have confirm it is doing).
>
> I still believe that if james is not stopping an incoming message
> (receiver side) when a message has exceeded it's max message size, that
> a denial of service attack it possible.  This type of attack would more
> consume bandwidth than cpu, but bandwidth is the expensive resource in
> this equation.
>
> Maybe I'll take a look at the smtp receiving code (pointer on which
> class to look in).  It might help if I took a look to understand what it
> is doing for this particular case.
>
> Chris....
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to