looking for the proper geronimo sources right now … On Oct 27, 2014, at 10:31 AM, Jerry Malcolm <techst...@malcolms.com> wrote:
> Robert, > > Where does the abstract configurator enter the flow? Unless it overrides the > InetAddress.getLocalHost().getHostname() call, I don't think it will help > since that is the ONLY thing the transport is looking at for HELO. Details > in my previous post..... I believe the actual error is in: > > org.apache.geronimo.javamail.transport.smtp.SMTPConnection.java > > I can make the fix to that class if you have the ability to rebuild the > geronimo.javamail.jar file. > > Thanks. > > Jerry > > > > > On 10/27/2014 12:16 PM, Robert Munn wrote: >> Bernd, >> >> See my previous note, I think the java.mail.localhost parameter is being >> ignored in the source code. I tried your suggestion and it did not seem to >> make a difference. I added the parameter as an argument in wrapper.conf as: >> >> wrapper.java.additional.15=-Dhostname >> >> But that change was not picked up. >> >> I am testing a temporary patch of AbstractConfigurableAsyncServer.java, >> trying to do a build, but repository.apache.org is throwing a 503 error >> Service Temporarily Unavailable. It took 14 minutes to do a build, and I’m >> not sure the build is good, although it reported success. I am going to test >> my patch and report back. >> >> Robert >> >> >> >> >> On Oct 27, 2014, at 9:09 AM, Bernd Waibel <bwai...@intarsys.de> wrote: >> >>> Hi Jerry >>> >>> I am not using v3 but: >>> >>> Could you try setting the parameter >>> "-Djava.mail.localhost=mail.jwmhosting.com" in the java startup command >>> line? >>> >>> Most java.mail parameters are only parsed on startup by the vm. >>> >>> >>> Ciao. >>> Bernd >>> >>> >>> >>> -------- Ursprüngliche Nachricht -------- >>> Von: Jerry Malcolm <techst...@malcolms.com> >>> Datum: >>> An: James Users List <server-user@james.apache.org> >>> Betreff: Re: James 3 b4 HELO Override Not Working? >>> >>> >>> More progress... But now I'm really stumped. I dug into the >>> remoteDelivery mailet source. I did confirm that James is NOT using the >>> smtpserver.xml 'hello' value at all for outbound HELO. It is definitely >>> using the config parms for the remoteDelivery mailet. >>> >>> In the mailet, the outbound HELO value is set by javax.mail.Transport >>> based on the 'mail.smtp.localhost' property passed in via the Properties >>> object. According to the Transport javadoc, it says it'll use the >>> property value for HELO if it's set, and if it's not set, it'll use >>> InetAddress.getLocalHost().getHostName(). Fine. So I cloned the mailet >>> so I could add log statements and do some debug. I add two log >>> statements right above the 'transport.sendMessage()' call in the >>> RemoteDelivery mailet: >>> >>> log( "JWMRemoteDelivery.deliver() mail.smtp.localhost - " + >>> props.getProperty( "mail.smtp.localhost" )); >>> >>> log( "JWMRemoteDelivery.deliver() >>> InetAddress.getLocalHost().getHostName() - " + >>> InetAddress.getLocalHost().getHostName() ); >>> >>> transport.sendMessage(message, addr); >>> >>> In the log, I get.... >>> >>> INFO 09:52:19,480 | james.mailetcontext | JWMRemoteDelivery.deliver() >>> mail.smtp.localhost - mail.jwmhosting.com >>> >>> INFO 09:52:19,480 | james.mailetcontext | JWMRemoteDelivery.deliver() >>> InetAddress.getLocalHost().getHostName() - p2825577 >>> >>> This is precisely what I expected to get. BUT.... when the mail is >>> sent, the p282.... is sent in the HELO. >>> >>> It appears that javax.mail.Transport is ignoring the property (or not >>> recognizing that it is set). But I'm pretty certain that a bug that is >>> that blatant would not be hanging around unreported in a base java class >>> like Transport. But, then again, that's what I appear to be seeing. >>> >>> Where am I going wrong? >>> >>> Secondarily, anybody know how I can change what java reports back on the >>> InetAddress call other than changing the machine name? Is there a JVM >>> parameter I can pass in? If I can force that, problem solved for me >>> (although it's still not working correctly). >>> >>> Thanks again. >>> >>> Jerry >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >>> For additional commands, e-mail: server-user-h...@james.apache.org >>> >> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2015.0.5315 / Virus Database: 4189/8462 - Release Date: 10/27/14 >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org > For additional commands, e-mail: server-user-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
