[jira] Reopened: (JAMES-580) NPE is issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain is set to true

2006-07-28 Thread Vincenzo Gianferrari Pini (JIRA)
[ http://issues.apache.org/jira/browse/JAMES-580?page=all ] Vincenzo Gianferrari Pini reopened JAMES-580: - Assignee: Vincenzo Gianferrari Pini (was: Norman Maurer) The fix was ok for 3.0 in trunk, but not for 2.3.0. NPE is

svn commit: r426542 - /james/server/branches/v2.3/src/java/org/apache/james/smtpserver/MailCmdHandler.java

2006-07-28 Thread vincenzo
Author: vincenzo Date: Fri Jul 28 07:09:31 2006 New Revision: 426542 URL: http://svn.apache.org/viewvc?rev=426542view=rev Log: The previous fix to JAMES-580 was ok for 3.0 in trunk, but not for 2.3.0rc1. Modified:

Re: [jira] Reopened: (JAMES-580) NPE is issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain is set to true

2006-07-28 Thread Norman Maurer
Ups.. :-( Thx Am Freitag, den 28.07.2006, 07:06 -0700 schrieb Vincenzo Gianferrari Pini (JIRA): [ http://issues.apache.org/jira/browse/JAMES-580?page=all ] Vincenzo Gianferrari Pini reopened JAMES-580: - Assignee: Vincenzo Gianferrari

[jira] Resolved: (JAMES-580) NPE is issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain is set to true

2006-07-28 Thread Vincenzo Gianferrari Pini (JIRA)
[ http://issues.apache.org/jira/browse/JAMES-580?page=all ] Vincenzo Gianferrari Pini resolved JAMES-580. - Resolution: Fixed The fix now is checking senderAddress != null, instead of sender != null. NPE is issued when receiving a read

Fix or enhancement to checkResolvableHelo/Ehlo?

2006-07-28 Thread Vincenzo Gianferrari Pini
I'm experimenting (using 2.3.0rc1 in my production system) some new settings, like checkResolvableHelo and checkResolvableEhlo. I found them very effective in blocking spam during the smtp session, in addition to blacklists. But I had to drop them because they check also the helo provided by

Re: Fix or enhancement to checkResolvableHelo/Ehlo?

2006-07-28 Thread Norman Maurer
Am Freitag, den 28.07.2006, 17:22 +0200 schrieb Vincenzo Gianferrari Pini: I'm experimenting (using 2.3.0rc1 in my production system) some new settings, like checkResolvableHelo and checkResolvableEhlo. I found them very effective in blocking spam during the smtp session, in addition to

Re: Fix or enhancement to checkResolvableHelo/Ehlo?

2006-07-28 Thread Stefano Bagnara
Vincenzo Gianferrari Pini wrote: I found them very effective in blocking spam during the smtp session, in addition to blacklists. But I had to drop them because they check also the helo provided by SMTP AUTHenticated client users, that may typically have non resolvable names specially if

RE: Fix or enhancement to checkResolvableHelo/Ehlo?

2006-07-28 Thread Noel J. Bergman
Stefano Bagnara wrote: the EHLO/EHLO is done before the AUTH can be issued so we only have a checkAuthNetworks option and not a checkAuthClients option like we did for other CmdHandlers. Sometimes, you have to defer the problem that you caught, so if the command handler finds the problem, it

Postage problems and questions

2006-07-28 Thread Vincenzo Gianferrari Pini
Bernd, I'm playing with Postage and 2.3.0rc1: Postage is great! Thanks. I found a couple of problems: 1) Postage doesn't support SMTP Authentication for int-ext users. Perhaps it is expected, as a real config.xml has in any case to be hacked to run postage, and setting authRequired to false

RE: Conditional build / check for jdbc 3.x presence

2006-07-28 Thread Noel J. Bergman
Yes, I believe that we can remove it. We can also removed some other things, such as the changes Norman made, as per comments in the code, to remove workarounds for earlier JDKs. --- Noel - To unsubscribe, e-mail:

RE: svn commit: r426107 - in /james/server/trunk/src/java/org/apache/james: transport/mailets/CommandListservProcessor.java transport/mailets/GenericListserv.java transport/mailets/WhiteListManager.ja

2006-07-28 Thread Noel J. Bergman
Norman, My major issue with this commit is that you preserved the comment: + * pI have done extensive testing of this routine with a standalone + * driver, and am leaving the commented out debug messages so that + * when someone decides to enhance this method, it can be yanked it +