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]

Reply via email to