Norman, I admit I am not an SMTP guru, so I'm open to accepting that my idea doesn't make sense. Before I do that though, could you explain to me why you think that Apache James should resolve addresses differently when configured as a gateway than how it resolves addresses when connecting directly to the e-mail destination server? Both email servers are SMTP servers...
My company has many mail servers and they expect people communicating with their servers to follow the SMTP RFC best practices. This means that they have multiple MX records for a domain that indicates multiple servers that are capable of handling mail. If I don't rely on the MX records when resolving the address, but rather pick a one or more corporate mail servers to connect to from my SMTP server (configured as a gateway), then I have to manually ensure that I keep my mail server addresses synchronized with the MX configuration. Am I making sense here? Am I crazy? I'm starting to feel crazy... Tim -----Original Message----- From: Norman Maurer [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 3:02 PM To: James Users List Subject: Re: RemoteDelivery mailet doesn't do an MX lookup on the gateway smtp hostname(s) Hi Tim, maybe I missunderstand you, but for me that makes no sense at all. bye Norman [EMAIL PROTECTED] schrieb: > I appreciate the feedback. I agree now that this isn't a bug. > > I did some digging into the SMTP RFC 2821 > http://www.ietf.org/rfc/rfc2821.txt (sections 3.8 & 5) to see what > they had to say about gateways and they didn't really specify a proper > way of connecting to the gateway or that address resolution of the > gateway needed to be the same when delivering mail directly to the > destination SMTP server (section 5). > > Although, from a purist perspective, wouldn't it make sense to handle > communicating with the SMTP gateway in the same way as if delivering > mail to the destination STMP server? Perhaps it makes sense to first > do an MX lookup of the gateway address, and if no MX record is found, > to then use the A record? > > I'm willing to code this change and submit it to the Apache James > project if it makes sense. > > Please advise. > > Tim Michalski > > > > -----Original Message----- > From: Stefano Bagnara [mailto:[EMAIL PROTECTED] > Sent: Friday, April 20, 2007 9:09 AM > To: James Users List > Subject: Re: RemoteDelivery mailet doesn't do an MX lookup on the > gateway smtp hostname(s) > > Hi Tim, > > If I understood your problem then it is not a bug. > > In the gateway you have to provide a valid hostname, with a valid "IN A" > > (direct) resolution. > > As you noticed mailout01 has not direct resolutions, but only an mx, > so it is pretty useless as we couldn't know where to connect to. > > You probably have simply to use example.weelsfargo.com as your gateway. > > Stefano > > [EMAIL PROTECTED] ha scritto: > >> I need to setup a James mail server to basically receive e-mail and >> forward all mail to a "master" mail server. I've modified the >> RemoteDelivery mailet properites within the transport processor of >> the >> > > >> config.xml and specified the gateway server hostname and port. When I >> test the James mail server by sending mail to it, I am getting the >> following output in the logs: >> >> 17/04/07 14:10:51 INFO James.Mailet: RemoteDelivery: Unknown gateway >> host: unknown host >> 17/04/07 14:10:51 INFO James.Mailet: RemoteDelivery: This could be a >> DNS server error or configuration error. >> >> I did an nslookup on my gateway server hostname and noticed that only >> an MX record has been setup... no A record exists for this hostname. >> For >> example: >> >> mailout01 MX example.wellsfargo.com >> >> The quick fix for this is to just use the hostname >> "example.wellsfargo.com" rather than "mailout01.wellsfargo.com". >> >> I dug into the RemoteDelivery mailet source to see what is going on... >> >> RemoteDelivery.getGatewaySMTPHostAddresses(Collection) is grabbing >> each gateway hostname and calling >> org.apache.james.dnsserver.DNSServer.getAllByName(nextGateway); >> >> DNSServer.getAllByName(nextGateway) is a wrapper method that makess a >> call out to org.xbill.DNS.Address.getAllByName(allowIPLiteral(host)); >> >> org.xbill.DNS.Address.getAllByName(String addr) { >> byte [] bytes; >> bytes = toByteArray(addr, IPv4); >> if (bytes != null) >> return InetAddress.getByAddress(bytes); >> bytes = toByteArray(addr, IPv6); >> if (bytes != null) >> return InetAddress.getByAddress(bytes); >> throw new UnknownHostException("Invalid address: " + addr); } >> >> The UnknownHostException is thrown when executing >> InetAddress.getByAddress(bytes) for my hostname >> "mailout01.wellsfargo.com" because DNS cannot resolve it's A record. >> >> For hostnames that have an A record, this exception is not thrown, >> which then RemoteDelivery.getGatewaySMTPHostAddresses(Collection) >> formats the returned InetAddress into a URL string like >> "smtp://something.goes.here". I am guessing that specifying the >> "SMTP://" indicates that port 25 will be accessed. >> >> So it seems that the bug is in having InetAddress.getByAddress() >> attempting to resolve the A record of the gateway server hostname. A >> solution could be to lookup the MX record of the gateway server, >> retrieve the A record that the MX record is pointing to and then call >> org.xbill.DNS.Address.getAllByName(String addr). >> >> >> Please advise. >> >> Thanks, >> >> Tim Michalski >> > > > > --------------------------------------------------------------------- > 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] > > > !DSPAM:1,46290a5a324323082015302! > > > --------------------------------------------------------------------- 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]
