[jira] Reopened: (JAMES-580) NPE is issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain is set to true
[ 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 issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain is set to true -- Key: JAMES-580 URL: http://issues.apache.org/jira/browse/JAMES-580 Project: James Issue Type: Bug Components: SMTPServer Affects Versions: 2.3.0rc1 Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Priority: Blocker Fix For: 2.3.0rc2 A NPE is issued when receiving a read receipt from MS Outlook (not Outlook express nor Thunderbird), and checkValidSenderDomain is set to true and the sender IP address is not in authorizedAddresses: 27/07/06 17:17:00 ERROR smtpserver: Exception opening socket: null java.lang.NullPointerException at org.apache.james.smtpserver.MailCmdHandler.doMAIL(MailCmdHandler.java:210) at org.apache.james.smtpserver.MailCmdHandler.onCommand(MailCmdHandler.java:83) at org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:391) at org.apache.james.util.connection.ServerConnection$ClientConnectionRunner.run(ServerConnection.java:422) at org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:55) at org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:116) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r426542 - /james/server/branches/v2.3/src/java/org/apache/james/smtpserver/MailCmdHandler.java
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:
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/MailCmdHandler.java
Modified:
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/MailCmdHandler.java
URL:
http://svn.apache.org/viewvc/james/server/branches/v2.3/src/java/org/apache/james/smtpserver/MailCmdHandler.java?rev=426542r1=426541r2=426542view=diff
==
---
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/MailCmdHandler.java
(original)
+++
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/MailCmdHandler.java
Fri Jul 28 07:09:31 2006
@@ -197,8 +197,8 @@
}
}
-// check only if its no null sender
-if (checkValidSenderDomain == true sender != null) {
+// check only if senderAddress is not null
+if (checkValidSenderDomain == true senderAddress != null) {
/**
* don't check if the ip address is allowed to relay. Only
check if it is set in the config.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Reopened: (JAMES-580) NPE is issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain is set to true
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 Pini (was: Norman Maurer) The fix was ok for 3.0 in trunk, but not for 2.3.0. NPE is issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain is set to true -- Key: JAMES-580 URL: http://issues.apache.org/jira/browse/JAMES-580 Project: James Issue Type: Bug Components: SMTPServer Affects Versions: 2.3.0rc1 Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Priority: Blocker Fix For: 2.3.0rc2 A NPE is issued when receiving a read receipt from MS Outlook (not Outlook express nor Thunderbird), and checkValidSenderDomain is set to true and the sender IP address is not in authorizedAddresses: 27/07/06 17:17:00 ERROR smtpserver: Exception opening socket: null java.lang.NullPointerException at org.apache.james.smtpserver.MailCmdHandler.doMAIL(MailCmdHandler.java:210) at org.apache.james.smtpserver.MailCmdHandler.onCommand(MailCmdHandler.java:83) at org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:391) at org.apache.james.util.connection.ServerConnection$ClientConnectionRunner.run(ServerConnection.java:422) at org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:55) at org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:116) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[jira] Resolved: (JAMES-580) NPE is issued when receiving a read receipt from MS Outlook, and checkValidSenderDomain is set to true
[ 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 receipt from MS Outlook, and checkValidSenderDomain is set to true -- Key: JAMES-580 URL: http://issues.apache.org/jira/browse/JAMES-580 Project: James Issue Type: Bug Components: SMTPServer Affects Versions: 2.3.0rc1 Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Priority: Blocker Fix For: 2.3.0rc2 A NPE is issued when receiving a read receipt from MS Outlook (not Outlook express nor Thunderbird), and checkValidSenderDomain is set to true and the sender IP address is not in authorizedAddresses: 27/07/06 17:17:00 ERROR smtpserver: Exception opening socket: null java.lang.NullPointerException at org.apache.james.smtpserver.MailCmdHandler.doMAIL(MailCmdHandler.java:210) at org.apache.james.smtpserver.MailCmdHandler.onCommand(MailCmdHandler.java:83) at org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:391) at org.apache.james.util.connection.ServerConnection$ClientConnectionRunner.run(ServerConnection.java:422) at org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:55) at org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:116) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fix or enhancement to checkResolvableHelo/Ehlo?
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 SMTP AUTHenticated client users, that may typically have non resolvable names specially if roaming. I think that this check should be conditioned by the user being or not SMTP AUTHenticated, as the blacklist check is in RcptCmdHandler, so IMHO the current behaviour is a bug that should be fixed for 2.3.0. But as this whole helo/ehlo check functionality was introduced some time ago by Stefano, he may have given it a different meaning then mine, so I'm not sure of it. What do you think about this? Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix or enhancement to checkResolvableHelo/Ehlo?
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 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 roaming. I think that this check should be conditioned by the user being or not SMTP AUTHenticated, as the blacklist check is in RcptCmdHandler, so IMHO the current behaviour is a bug that should be fixed for 2.3.0. But as this whole helo/ehlo check functionality was introduced some time ago by Stefano, he may have given it a different meaning then mine, so I'm not sure of it. What do you think about this? Vincenzo Well Vincenzo you are right. i will correct it. BTW the code was contributed from me and stefano just commit it.. So its my faul :-( bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Fix or enhancement to checkResolvableHelo/Ehlo?
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 roaming. They are effective but even dungerous. MANY users have misconfigured systems and uses bad salutations. Furthermore 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. I think that this check should be conditioned by the user being or not SMTP AUTHenticated, as the blacklist check is in RcptCmdHandler, so IMHO the current behaviour is a bug that should be fixed for 2.3.0. But as this whole helo/ehlo check functionality was introduced some time ago by Stefano, he may have given it a different meaning then mine, so I'm not sure of it. I don't remember if I committed it or not, btw this is Norman work (IIRC). I never worked on this ehlo validity/resolvability checks because I think they are more harmful than useful. I've not checked the sources and I don't know how it works now. I suppose you already checked the checkAuthClients/checkAuthNetworks option for the handlers. What do you think about this? Vincenzo I am against any change to the fastfail code because we are in RC and the fastfail is experimental code that we already changed it in trunk and should not delay furthermore 2.3.0 for this stuff. (In fact I would have released 2.3.0 with fastfail disabled at all and only document how to enable it somewhere in our wiki for people that wanted to experiment). I think I will not veto this changes, but I think that if we start fixing this behaviours we'll never make this release. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fix or enhancement to checkResolvableHelo/Ehlo?
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 can set a session attribute itself (or another aware handler) to deal with later. For example, the block list code is intentionally handled in RCPT because I wanted to defer the error until we knew to whom they were sending the e-mail, thus allowing RFC compliance with postmaster@ and [EMAIL PROTECTED] The concept, for which we now have support in the v2.4 changes, was that an EHLO handler could actually be a suite of related handlers registered to be an EHLO handler, an AUTH handler, and some other type of handler(s), so that it could set a detected concern in EHLO, possibly clear it in AUTH, and check it downstream. I've not formed an opinion on whether or not to fix this for v2.3 or wait for v2.4. I won't form an opinion until I see the proposed patch. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Postage problems and questions
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 is easy. But insuch case it should be said in the docs. 2) The generated postage_jvmStatistics.*.csv (and postage_errors.*.csv) files are empty after a run. Now a question: the time interval between any two mails generated (based on count-per-min=n) is constant or is there any probability distribution function (exponential or other)? And what about the text and binary sizes? Thanks, Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Conditional build / check for jdbc 3.x presence
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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 + * from this file, embedded it with a test driver, and the comments + * enabled./p But you removed all of the debug code! One or other other should be corrected: either the comment should be removed, or the debug code put back. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
