Think about this usecase:

Internally, we have many servers responsible for relaying mail. (multiple
data centers). Also, they have the concept of servers that are lower
priority, in case all the primary ones have a failure.

Also, we can not directly send mail outside the firewall, so all mail must
go through this infrastructure to be sent. (So we must have
smarthost/gateway turned on)

They can setup/change the list of MX records for the network name we are
supposed to transport mail through whenever they want.

Thoughts?

Thanks,

Cole

On Fri, May 11, 2012 at 1:24 AM, Eric Charles <[email protected]> wrote:

> If you specify explicitly a mail gateway, MX record usage does not make
> any sense.
>
> You must see the mail gateway you define as 'hard-coding' the MTA you want
> to use, that skips any usage of dynamically defined MX record.
>
> Thx, Eric
>
>
> On 05/10/2012 06:28 PM, Cole Ferrier wrote:
>
>> Ahh, i think i've figured out the problem..
>>
>> We have a requirement to smarthost (transfer all mail through an internal
>> mail relay). so we have set the Mail Gateway up in our remotedelivery
>> mailet.
>>
>> org.apache.james.transport.**mailets.RemoteDeliverydeliver.**deliver(Mail
>> mail,
>> Session session)
>>
>> then in the mailet:
>>
>>             if (gatewayServer == null) {
>>                 MailAddress rcpt = (MailAddress)
>> recipients.iterator().next();
>>                 String host = rcpt.getHost();
>>
>>                 //Lookup the possible targets
>>                 targetServers =
>> getMailetContext().**getSMTPHostAddresses(host);
>>                 if (!targetServers.hasNext()) {
>>                     log("No mail server found for: " + host);
>>                     StringBuffer exceptionBuffer =
>>                         new StringBuffer(128)
>>                         .append("There are no DNS entries for the hostname
>> ")
>>                         .append(host)
>>                         .append(".  I cannot determine where to send this
>> message.");
>>                     return failMessage(mail, new
>> MessagingException(**exceptionBuffer.toString()), false);
>>                 }
>>             } else {
>>                 targetServers = getGatewaySMTPHostAddresses(**
>> gatewayServer);
>>             }
>>
>> we have a gateway server so it goes into the else clause of this block,
>> because it doesn't have to find the mail servers responsible for the
>> domains of the recipients, and it just calls
>> getGatewaySMTPHostAddresses(**gatewayServer);
>>
>> which returns an iterator that just loops through
>>
>> final InetAddress[] ips =
>> org.apache.james.dnsserver.**DNSServer.getAllByName(**nextGateway);
>>
>> which are just all the DNS entries (not MX records) for the gateway
>> server.
>>
>> This is why when i turned up logging to DEBUG on the DNSServer component,
>> i
>> didn't get any meaningful data.
>>
>> So it looks like i have a requirement that i still want MX records to be
>> evaluated while using a mail gateway. Does that make sense?
>>
>> Could i just change this block of code to always call the
>>
>> //Lookup the possible targets
>>                 targetServers =
>> getMailetContext().**getSMTPHostAddresses(host);
>>
>> method?
>>
>> Or?
>>
>> Thoughts?
>>
>> Cole
>>
>>
>>
>> On Thu, May 10, 2012 at 3:40 AM, Eric Charles<[email protected]>  wrote:
>>
>>  Quick addon if finally the issue is in james code, and further to Ioan's
>>> point on JIRA, the patch to backport on 2.3 could be
>>>
>>> http://svn.apache.org/viewvc/****james/server/trunk/**dnsservice-**<http://svn.apache.org/viewvc/**james/server/trunk/dnsservice-**>
>>> dnsjava/src/main/java/org/****apache/james/dnsservice/**
>>> dnsjava/DNSJavaService.java?****r1=1035437&r2=1035436&pathrev=**
>>> **1035437<http://svn.apache.**org/viewvc/james/server/trunk/**
>>> dnsservice-dnsjava/src/main/**java/org/apache/james/**
>>> dnsservice/dnsjava/**DNSJavaService.java?r1=**
>>> 1035437&r2=1035436&pathrev=**1035437<http://svn.apache.org/viewvc/james/server/trunk/dnsservice-dnsjava/src/main/java/org/apache/james/dnsservice/dnsjava/DNSJavaService.java?r1=1035437&r2=1035436&pathrev=1035437>
>>> >
>>>
>>>
>>> Thx, Eric
>>>
>>>
>>> On 05/10/2012 11:30 AM, Stefano Bagnara wrote:
>>>
>>>  2012/5/9 Cole Ferrier<[email protected]>:
>>>>
>>>>  Recycle of James did not work, it is still equally using all 6 of the
>>>>> mail
>>>>> servers, even though they are at a different preference levels.
>>>>>
>>>>> Any Ideas?
>>>>>
>>>>>
>>>> I think you have issues at DNS level.
>>>>
>>>> AFAIK james 2.3 had some bug in MX ordering but I remember only two of
>>>> them, and they do not break priority the way you see.
>>>> 1) If james is a relay server for a domain it doesn't take care to
>>>> only relay to "lower priority" servers resulting into loops if the
>>>> high priority servers are not available (this is not your case).
>>>> 2) James does sort MX hosts, but uses a comparator that is not
>>>> "consistent with equals"
>>>> (http://docs.oracle.com/****javase/1.4.2/docs/api/java/**<http://docs.oracle.com/**javase/1.4.2/docs/api/java/**>
>>>> util/Comparator.html<http://**docs.oracle.com/javase/1.4.2/**
>>>> docs/api/java/util/Comparator.**html<http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Comparator.html>
>>>> >
>>>>
>>>> ).
>>>> This is not necessarily a bad thing as it will correctly sort results
>>>> using the priority but often will return servers with the same
>>>> priority "not shuffled": more often than not, MX are already shuffled
>>>> on the DNS side so this doesn't have a big impact (and is not your
>>>> case).
>>>>
>>>> So check what DNS servers your james is using and make sure that very
>>>> specific DNS servers have updated informations.
>>>>
>>>> Stefano
>>>>
>>>>  Cole
>>>>
>>>>>
>>>>> On Tue, May 8, 2012 at 3:03 PM, Cole Ferrier<[email protected]>
>>>>>  wrote:
>>>>>
>>>>>  talking with our internal mail system people, all 6 servers had a
>>>>>
>>>>>> priority
>>>>>> of 10 the last time apache James was restarted.
>>>>>>
>>>>>> Does James cache this data for the life of it running? or is there a
>>>>>> time
>>>>>> to live? or?
>>>>>>
>>>>>> I will schedule a recycle of james to see if it stops using the
>>>>>> servers
>>>>>> that now have a lower preference.
>>>>>>
>>>>>> Let me know if you have any ideas in the mean time.
>>>>>>
>>>>>> Cole
>>>>>>
>>>>>>
>>>>>> On Tue, May 8, 2012 at 9:42 AM, Cole Ferrier<[email protected]>
>>>>>>  wrote:
>>>>>>
>>>>>>  We have an internal mail system that has 6 MX records 3 at priority
>>>>>> 10
>>>>>>
>>>>>>> (new servers recently added) and 3 at priority 20 (old servers that
>>>>>>> where
>>>>>>> previously at 10).
>>>>>>>
>>>>>>> and it appears that apache james 2.3 is sending mail to all of them
>>>>>>> about
>>>>>>> equally?
>>>>>>>
>>>>>>> i was instructed that it should only connect to the 20's when all of
>>>>>>> the
>>>>>>> 10s are unavailable?
>>>>>>>
>>>>>>> any help would be appreciated?
>>>>>>>
>>>>>>> (or is there any need to restart James? aka, how long does it cache
>>>>>>> its
>>>>>>> data about the MX preferences?)
>>>>>>>
>>>>>>> Cole
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>  ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: server-user-unsubscribe@james.****apache.org<
>>>> server-user-**[email protected]<[email protected]>
>>>> >
>>>> For additional commands, e-mail: [email protected].****org<
>>>> server-user-help@james.**apache.org <[email protected]>
>>>> >
>>>>
>>>>
>>>>  --
>>> eric | http://about.echarles.net | @echarles
>>>
>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: server-user-unsubscribe@james.****apache.org<
>>> server-user-**[email protected]<[email protected]>
>>> >
>>> For additional commands, e-mail: [email protected].****org<
>>> server-user-help@james.**apache.org <[email protected]>>
>>>
>>>
>>>
>>
> --
> eric | http://about.echarles.net | @echarles
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: 
> server-user-unsubscribe@james.**apache.org<[email protected]>
> For additional commands, e-mail: 
> [email protected].**org<[email protected]>
>
>

Reply via email to