Re: MX choosing
On 22.07.11 16:50, Feng He wrote: Given the MX hosts for sympatico.ca domain: $ dig sympatico.ca mx +short 5 mxmta.sympatico.ca. $ dig mxmta.sympatico.ca +short 67.69.240.17 67.69.240.24 67.69.240.22 67.69.240.23 67.69.240.21 67.69.240.20 67.69.240.19 67.69.240.18 when the peer MTA fail to talk to one of these hosts,will it try the next one? or it just give up? this is out of DNS and BIND scope. see rfc 5321, section 5.1 for MTA requirements. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Saving Private Ryan... Private Ryan exists. Overwrite? (Y/N) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MX choosing
On 07/22/2011 09:50 AM, Feng He wrote: Given the MX hosts for sympatico.ca domain: $ dig sympatico.ca mx +short 5 mxmta.sympatico.ca. $ dig mxmta.sympatico.ca +short 67.69.240.17 67.69.240.24 67.69.240.22 67.69.240.23 67.69.240.21 67.69.240.20 67.69.240.19 67.69.240.18 when the peer MTA fail to talk to one of these hosts,will it try the next one? or it just give up? It should try the next one, but there is a lot of crappy MTA software out there. See section 5 of RFC 5321, or earlier RFC 2821, or section 5 of RFC 1123 and earlier RFCs 821 and 974, for details. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MX choosing
Am Fri, 22 Jul 2011 16:50:35 +0800 schrieb Feng He short...@gmail.com: Given the MX hosts for sympatico.ca domain: $ dig sympatico.ca mx +short 5 mxmta.sympatico.ca. $ dig mxmta.sympatico.ca +short 67.69.240.17 67.69.240.24 67.69.240.22 67.69.240.23 67.69.240.21 67.69.240.20 67.69.240.19 67.69.240.18 when the peer MTA fail to talk to one of these hosts,will it try the next one? or it just give up? Thanks. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Since there's no fallback MX the MTA will try once and then store the mail for a later retry (depends on how your MTA is configured). Since the TTL of mxmta.sympatico.ca is just 1800 seconds there might be a good chance that your MTA will try another server unless the next try is within 1800 seconds (where it will just reuse the already cached one) or your bad luck provides you with the not working IP address again. Ciao Torsten ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MX choosing
Thanks. this is the description: When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the SMTP client SHOULD try at least two addresses. On Fri, Jul 22, 2011 at 5:11 PM, Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 22.07.11 16:50, Feng He wrote: Given the MX hosts for sympatico.ca domain: $ dig sympatico.ca mx +short 5 mxmta.sympatico.ca. $ dig mxmta.sympatico.ca +short 67.69.240.17 67.69.240.24 67.69.240.22 67.69.240.23 67.69.240.21 67.69.240.20 67.69.240.19 67.69.240.18 when the peer MTA fail to talk to one of these hosts,will it try the next one? or it just give up? this is out of DNS and BIND scope. see rfc 5321, section 5.1 for MTA requirements. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Saving Private Ryan... Private Ryan exists. Overwrite? (Y/N) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MX choosing
Phil Mayers p.may...@imperial.ac.uk wrote: On 07/22/2011 09:50 AM, Feng He wrote: Given the MX hosts for sympatico.ca domain: $ dig sympatico.ca mx +short 5 mxmta.sympatico.ca. $ dig mxmta.sympatico.ca +short 67.69.240.17 [ and several others ] when the peer MTA fail to talk to one of these hosts,will it try the next one? or it just give up? It should try the next one, but there is a lot of crappy MTA software out there. See section 5 of RFC 5321 [...] I agree that it is better to immediately retry using the other IP addresses (and in fact our setup assumes they will - see mx.cam.ac.uk) but others (who believe that multihomed servers exist) disagree. RFC 5321 says: The question of whether a sender should attempt retries using the different addresses of a multihomed host has been controversial. The main argument for using the multiple addresses is that it maximizes the probability of timely delivery, and indeed sometimes the probability of any delivery; the counter-argument is that it may result in unnecessary resource use. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ East Dogger, Fisher, German Bight: Northwesterly 6 to gale 8. Moderate or rough, becoming rough or very rough. Rain. Good, becoming moderate or poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MX choosing
On Fri, Jul 22, 2011 at 5:58 PM, Tony Finch d...@dotat.at wrote: The question of whether a sender should attempt retries using the different addresses of a multihomed host has been controversial. The main argument for using the multiple addresses is that it maximizes the probability of timely delivery, and indeed sometimes the probability of any delivery; the counter-argument is that it may result in unnecessary resource use. In any case, the SMTP client SHOULD try at least two addresses. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MX choosing
On 22/07/11 14:01, Feng He wrote: On Fri, Jul 22, 2011 at 5:58 PM, Tony Finchd...@dotat.at wrote: The question of whether a sender should attempt retries using the different addresses of a multihomed host has been controversial. The main argument for using the multiple addresses is that it maximizes the probability of timely delivery, and indeed sometimes the probability of any delivery; the counter-argument is that it may result in unnecessary resource use. In any case, the SMTP client SHOULD try at least two addresses. Many do not. It is safer to have 1 MX, than 1 MX with 1 A record. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MX choosing
Hi there, On Fri, 22 Jul 2011 Tony Finch quoted the RFCs thus: The question of whether a sender should attempt retries using the different addresses of a multihomed host has been controversial. ... I know of at least one substantial organization which uses this kind of thing as part of its protection against unwanted mail. -- 73, Ged. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
