looks sensible to me Dan. Go for it.

d.



|---------+---------------------------->
|         |           "Daniel Perry"   |
|         |           <[EMAIL PROTECTED]|
|         |           co.uk>           |
|         |                            |
|         |           03/06/2005 11:07 |
|         |           Please respond to|
|         |           "James Developers|
|         |           List"            |
|         |                            |
|---------+---------------------------->
  
>-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                                  |
  |       To:       "James Developers List" <server-dev@james.apache.org>       
                                                  |
  |       cc:                                                                   
                                                  |
  |       Subject:  [bump]RE: Serious bandwidth begin consumed by James         
                                                  |
  
>-------------------------------------------------------------------------------------------------------------------------------|




Did anyone else ever look into the (serious) issues i highlighted with the
SMTP protocol handler and remote delivery mailet?

1. endless remote delivery retries on an exception when remote delivery
bounces a message (initial problem) - can be delt with using the patch i
supplied, to catch the error, and treat it in same way as exceptions.
2. Error (eg. OutOfMemoryError) at any point in remote delivery causes
endless retries, as only exceptions cause dropping of message, not errors.
3. Non RFC compliant rejection of messages over size limit, and this also
screws up the remainder of the SMTP session.

See the two blocks below of my origional message for code/comment on
solutions.

Are my solutions ok? (before i go away and code).  If i produce patches
against head and submit it to JIRA, is anyone interested?

Daniel.



>
> I changed the code to catch all "Error"s on bouncing, not just
> "Exception"s.
>
> -----------------------patch
>
> --- C:\RemoteDelivery.java.orig          Thu May 05 15:42:37 2005
> +++ C:\RemoteDelivery.java.fixed         Thu May 05 15:50:30 2005
> @@ -740,12 +740,12 @@
>          log("Sending failure message " + mail.getName());
>          try {
>              getMailetContext().bounce(mail, sout.toString());
>          } catch (MessagingException me) {
>              log("Encountered unexpected messaging exception
> while bouncing
> message: " + me.getMessage());
> -        } catch (Exception e) {
> -            log("Encountered unexpected exception while bouncing
> message: "
> + e.getMessage());
> +        } catch (Error e) {
> +            log("Encountered unexpected exception/error while bouncing
> message: " + e.getMessage());
>          }
>      }
>
>      public String getMailetInfo() {
>          return "RemoteDelivery Mailet";
> -----------------------end of patch
>
>
> However, looking at remotedelivery.run, it seems like it was designed to
> handle this kind of problem - but only removes messages that fails with
an
> exception, not an error or throwable:
>
>     } catch (Exception e) {
>         // Prevent unexpected exceptions from causing looping by removing
>         // message from outgoing.
>         outgoing.remove(key);
>         throw e;
>     }
> } catch (Throwable e) {
>     if (!destroyed) log("Exception caught in RemoteDelivery.run()", e);
> }
>
>
> Maybe this code should be catch all errors, and try to remove the mail!





> 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.


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





***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) 
only. If you are not the intended recipient (or responsible for delivery of the 
message to the intended recipient) please notify us immediately on 0141 306 
2050 and delete the message from your computer. You may not copy or forward it 
or use or disclose its contents to any other person. As Internet communications 
are capable of data corruption Student Loans Company Limited does not accept 
any  responsibility for changes made to this message after it was sent. For 
this reason it may be inappropriate to rely on advice or opinions contained in 
an e-mail without obtaining written confirmation of it. Neither Student Loans 
Company Limited or the sender accepts any liability or responsibility for 
viruses as it is your responsibility to scan attachments (if any). Opinions and 
views expressed in this e-mail are those of the sender and may not reflect the 
opinions and views of The Student Loans Company Limited.

This footnote also confirms that this email message has been swept for the 
presence of computer viruses.

**************************************************************************

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

Reply via email to