Very embarrassed :-$

"mail.smtp.sendpartial" does NOT leak memory. So please put it in.

-- Jason

> -----Original Message-----
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: 06 February 2003 17:14
> To: James Developers List
> Subject: JavaMail settings for RemoteDelivery (was about memory leaks)
> 
> 
> Jason,
> 
> Remember that RemoteDelivery uses JavaMail for SENDING.  Your 
> DoS attack doesn't apply.  We have our own code for receiving 
> SMTP, and we handle timeouts.
> 
> Seems to me that it makes sense to have defaults (NULL to not 
> set the value) for each property, and configuration entries 
> to override.
> 
> With respect to "mail.smtp.sendpartial", I think that it is 
> important to use it.  See the API docs: "If set to true, and 
> a message has some valid and some invalid addresses, send the 
> message anyway, reporting the partial failure with a 
> SendFailedException. If set to false (the default), the 
> message is not sent to any of the recipients if there is an 
> invalid recipient address."  RemoteDelivery already has the 
> code for handling the SendFamiledException, and processing 
> the getValidSentAddresses list.  But, again, this can be a 
> configuration setting.  I just think that it should probably 
> be true in most cases.
That's fine if the code handles it correctly as it would give us a lot
more resilance. So go for it.
> 
>       --- Noel
> 
> -----Original Message-----
> From: Jason Webb [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 06, 2003 11:47
> To: 'James Developers List'
> Subject: RE: An interesting note about memory leaks (was 
> Memory leaks in RemoteDelivery mailet?)
> 
> 
> I've tried the following settings:
> > props.put("mail.smpt.connectiontimeout", "6000");
> Taken from Qmail - 60 second timeout is fine
> 
> > props.put("mail.smtp.timeout", "1200000");
> Taken from Qmail - 20 minute timeout on I/O. This may be less 
> than desirable. Someone may be sending you 1 byte every 19 
> minutes. This keeps the channel open and acts like a DOS attack.
> 
> > props.put("mail.smtp.localhost", "stockholm.inovem.com");
> Not sure this is useful. Doesn't cause any problems, but I 
> think it doesn't add much either.
> 
> > props.put("mail.smtp.sendpartial", "true");
> This appears on the surface to be nice, but I don't think it 
> is. I send a mail to 2 people, 1 address gives me a 5xx error 
> (mail box full for example). Which one succeed? Do I try 
> again later? Do I end up sending the same message many times 
> (once per attempt) to the user who I can send to? I'm not 
> sure, but I think this may be a bad idea. It also leaks 
> memory slowly and persitantly. My current opinon with 
> JavaMail's SMTP transport is to keep it simple. So I'd 
> recommend NOT using it.
> 
> In summary add the following: 
> props.put("mail.smpt.connectiontimeout", "6000"); 
> props.put("mail.smtp.timeout", "1200000");
> 
> 
> I don't have the time today to do a proper job and add the 
> extra items to the config file. I can do it tomorrow though.
> 
> -- Jason
> 
> 
> > -----Original Message-----
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > Sent: 06 February 2003 16:04
> > To: James Developers List
> > Subject: RE: An interesting note about memory leaks (was 
> Memory leaks 
> > in RemoteDelivery mailet?)
> >
> >
> > Jason,
> >
> > > OK, I'll try [Serge's suggestions for JavaMail properties]
> > and report
> > back.
> >
> > > I will post the patch that removes the "mail.smtp.user"
> > setting first
> > > though as that may cause users real problems.
> >
> > If you can try Serge's suggestions, and resubmit the patch, 
> that'd be 
> > good. Sounds like you are in a position to turn that around pretty 
> > quickly.
> >
> >     --- Noel
> 
> 
> ---------------------------------------------------------------------
> 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