Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!TRANSARC.COM!Craig_Everhart From: Craig_Everhart@TRANSARC.COM Newsgroups: comp.mail.sendmail Subject: Re: 'm' mailer flag doesn't help with MX's Message-ID: Date: 19 Jun 91 15:33:12 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Lines: 47 I did a similar thing to sendmail 5.61 some years back; I called it MX-piggybacking. I can give you the implementation, but it's more limited than you wanted. It does work well, though, and helps a lot on big address lists. The version that I built assumes a preprocessor on address lists that sorts recipients by MX. Instead of doing multiple deliveries when the target domain names are identical, it does multiple deliveries when the sorted arrays of MX receiver names are identical. It keeps only a one-element cache, so it does only one-name lookahead. That is, it keeps two vectors of MX hosts: the current one (corresponding to the ``current'' host/target domain), and the single lookahead one (corresponding to the lookahead target). If the MX vectors are identical, it will piggyback the lookahead recipient onto the current list, and look ahead one more time. It treats the absence of any MX records as identical to having a single MX record to the destination domain. This was a case I missed in the initial implementation. It also randomizes MX elements with identical preferences. The only trick here is that to keep from defeating your MX-piggybacking, you want to randomize the same set of domain names in the same order on any given sendmail run, but you do want to randomize the same set of domain names in different orders on different runs. I do this by taking a snapshot of time if a static variable is still zero, and using that snapshot and the domain name in the MX (in case-folded form) to come up with a signature value, then sorting by signature value. It's tricky to get the temp-failure and persistent-failure cases right as you look ahead for MX results. Clearly, this is important, and it's what I concentrated on in my first version. In my use, the single look-ahead buffer works just great, because AMDS looks up hosts also before sending to them (so it can maybe issue rejections for host-not-found without de-formatting any ATK-format mail), and it sorts the recipients. I recently found a weakness of its method, though: it sorts only on the first named MX receiver, not all the MX receivers, so MX-piggybacking is sort of defeated for mail that goes through *.uu.net, since there is currently a lot of variation in the MX records there. (Most mail currently goes to relay1.uu.net and relay2.uu.net, but some goes to news.uu.net and/or other hosts.) Let me know if you want to see my implementation. Craig