Now this problem has hit our server.... And in the last ten days or so
consumed an enormous amount of bandwidth!
An 18mb email was sent to an address that is forwarded elsewhere (via
jdbcvirtualusertable). The server it is forwarded to has a 10mb limit, so
it responded with "552 Message size exceeds maximum permitted".
Now I've looked through the code, and it all looks good - permanent error,
so send bounce, and delete original message. But this wasn't happening.
Now here's the catch - delivering the bounce caused a
java.lang.OutOfMemoryError. So, the bouncing never completed, and this is
not caught by the "catch Exception" block around getMailetContext().bounce,
but is caught in RemoteDelivery.run()!
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!
Daniel.
> -----Original Message-----
> From: Stefano Bagnara [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED]
> Sent: 14 April 2005 21:04
> To: 'James Users List'; [EMAIL PROTECTED]
> Subject: Re: Serious bandwidth begin consumed by James
>
>
> > I did a little digging in the logs and I was able to find
> > these repeated log entries in the mailet-* logs (I removed
> > the actual email address/dns info to protect the innocent):
>
> It seems the same message that once failed bounces and resend
> again. This is
> really strange.
> RemoteDelivery, after it says "Sending failure...":
>
> log("Sending failure message " + mail.getName());
> try {
> getMailetContext().bounce(mail, sout.toString());
>
> Will call MailetContext.bounce. James.java, bounce():
>
> if (mail.getSender() == null) {
> if (getLogger().isInfoEnabled())
> getLogger().info("Mail to be bounced contains a null (<>)
> reverse path. No bounce will be sent.");
> return;
> } else {
> // Bounce message goes to the reverse path, not to
> the Reply-To
> address
> if (getLogger().isInfoEnabled())
> getLogger().info("Processing a bounce request for
> a message
> with a reverse path of " + mail.getSender().toString());
> reply.setRecipient(MimeMessage.RecipientType.TO,
> mail.getSender().toInternetAddress());
> }
>
> You should find a log containing one of these 2 logs "Mail to be bounce
> contains" or "Processing a bounce request"... Please find that
> log and tell
> us what you find.
>
> But I think I found the problem: the bounce created has the full
> message as
> attachment and so it is bigger than the original. The
> domain.here.com refuse
> big messages as like the graphicsbyheather.com server so the message keeps
> bouncing.
> This is a problem in the current 2.2.0. I rememeber something fixed about
> return-path handling in the current 2_1_fcs branch. You should
> try upgrading
> to "2.2.1dev" (branch 2_1_fcs in current subversion). This should
> be fixed.
>
> Alternatively you probably can fix this by adding a <bounceProcessor> tag
> like described in this JIRA issue:
> http://issues.apache.org/jira/browse/JAMES-357
>
> The bug will be still there but the bounce will be created by DSNBounce
> instead of the MailetContext and I think that DSNBounce will correctly set
> the return-path of the bounce to "<>". You can even configure the
> DSNBounce
> with the option <attachment>none</attachment> so that the bounce will not
> contain the original message!
>
>
> > mailet-2005-04-13-00-01.log:13/04/05 14:10:28 INFO James.Mailet:
> > RemoteDelivery: Attempting delivery of Mail1113353072629-556
> > 45-to-graphicsbyheather.com to host mx.domain.here.com. at
> > 217.160.230.10 to addresses [EMAIL PROTECTED]
> > mailet-2005-04-13-00-01.log:13/04/05 14:13:38 INFO James.Mailet:
> > RemoteDelivery: Exception delivering message (Mail1113353072
> > 629-55645-to-domain.here.com) - 552 message too large
> > mailet-2005-04-13-00-01.log:13/04/05 14:13:38 INFO James.Mailet:
> > RemoteDelivery: Permanent exception delivering mail (Mail111
> > 3353072629-55645-to-domain.here.com:
> > javax.mail.MessagingException: 552 message too large
> > mailet-2005-04-13-00-01.log:13/04/05 14:13:44 INFO James.Mailet:
> > RemoteDelivery: Sending failure message Mail1113353072629-55
> > 645-to-domain.here.com
> >
> > mailet-2005-04-13-00-01.log:13/04/05 14:13:45 INFO James.Mailet:
> > RemoteDelivery: Attempting delivery of Mail1113353072629-556
> > 45-to-graphicsbyheather.com to host mx.domain.here.com. at
> > 217.160.230.12 to addresses [EMAIL PROTECTED]
> > mailet-2005-04-13-00-01.log:13/04/05 14:18:27 INFO James.Mailet:
> > RemoteDelivery: Exception delivering message (Mail1113353072
> > 629-55645-to-domain.here.com) - 552 message too large
> > mailet-2005-04-13-00-01.log:13/04/05 14:18:27 INFO James.Mailet:
> > RemoteDelivery: Permanent exception delivering mail (Mail111
> > 3353072629-55645-to-domain.here.com:
> > javax.mail.MessagingException: 552 message too large
> > mailet-2005-04-13-00-01.log:13/04/05 14:18:42 INFO James.Mailet:
> > RemoteDelivery: Sending failure message Mail1113353072629-55
> > 645-to-domain.here.com
> >
> > This group of messages repeated from 8pm 4/12 when the
> > message was sent by one of my users until 2:30 4/13 when I
> > killed the server and removed all of the outgoing mail
> > messages. It looks like they repeat in 3 minute increments.
> >
> >
> > Chris....
> >
> >
> > Serge Knystautas wrote:
> >
> > > Chris Hane wrote:
> > >
> > >> What I think is happening though is the other server that james is
> > >> trying to send to is not allowing for such a large message and is
> > >> just terminating the connection.
> > >>
> > >> It appears that james takes the termination as a network error and
> > >> retries immediately (and gets itself into a loop). Has
> > anyone else
> > >> seen this type of issue? Any solutions? I'm even willing to work
> > >> through some of the james code if I could get a pointer or
> > two with
> > >> which classes to start with in my debugging attempts.
> > >
> > >
> > > What version are you running? I can't think of how our
> > error handling
> > > would try to immediately resend without incrementing the attempt
> > > counter. Maybe it's an old version with a bug that's since
> > been fixed.
> > >
> >
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.308 / Virus Database: 266.9.7 - Release Date: 4/12/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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
