In message <6E881F81-991D-4E98-932C-65CB49B02783@xxxxxxxxx>, =?iso-8859-1?Q?Pat rik_F=E4ltstr=F6m?= writes: > On 31 maj 2010, at 08.03, Mark Andrews wrote: > > > MTAs should never search. MX records are absolute (explict or > > implicit). > > Agree. > > > MSAs should only search to qualify unqualified domains in user > > submitted data. > > I agree with this as well. > > These are just two details that have not been clear in some drafty-draft = > documents I have seen on "SMTP and IPv6". > > > Just curious. What percentage addresses in your address book are > > not fully qualified. I know I gave up on unqualified address back > > in the early '90s. Also are all the search element served locally > > or do you need to do a remote lookup for them? > > I really think we should "get rid of" the search path in resolvers. > > > And it shouldn't be exponential growth. Double maybe. > > If you have search path, and then choice of IPv4 and IPv6 transport for = > DNS, and then A and AAAA to look up for the MTA you connect to, that at = > least multiplies the number of choices. > > The best is double. Then in some cases it is worse. You have qualification searchs. MX (1 + search), A (1 + search), AAAA (1 + search) Delivery (A + AAAA) * MX targets (implict or explict). If it's more than that then the MTA is broken and is a security incident waiting to happen. > It all works pretty well if the client have IPv4 and IPv6 _AND_ both > works. But to some degree the functionality and user experience goes > down if either of IPv4 or IPv6 have problems. SMTP is store and forward. Your MSA should just accept and queue. The actual delivery should be done in the background or do you have debugging turned on where you are trying to see the delivery step? > Anyway, the biggest problem is still, as you say, that we do not really = > know... > > >> For me it worked better than dual stack, when accessing things that = > was > >> reachable over IPv6. But that was with my OS (MacOSX) that have > >> relatively good IPv6 support. > > > > And problems with its resolver trying to be too smart. :-) > > You bet! > > Patrik -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf