Re: ZMailer for slow connection

[Arnt Gulbrandsen <agulbra@troll.no>]

Wow.  That's some hole to be in.

If you can get the routers on both ends of that 64kbps line configured
well, you have some quite desirable options... giving packets from
your mail relay destined to port 25 somewhere extra priority, for
example.  Doing detailed usage logging for that line, creating high-,
medium- and low-priority queues on both ends, and dividing the traffic
according to value is obviously a good strategy.

If you can not influence the routing, you can minimize your dependency
on the line, maximize your share of it, or both.

Minimizing your dependency first.  Not very much you can do, but here
are some suggestions.

Have good, stable name servers on both sides, use TTLs of at least a
week on all the domain zones you can, never use a name server on the
other end except through a local caching name server.

If there is a lot of mail that's forwarded out of the country again,
massage aliases on the "real" mail destination into fqdnaliases on the
relay so you can skip two 64k hops.  It should also be possible to
bounce mail at the relay if you can give it complete knowledge of the
valid addresses, either using zmailer's expiredaccts feature or a
special zmsh script, but I don't know how.

Finally, hardest but almost certainly best: Set up a UUCP-over-TCP
mail feed and make it use gzip -9 for compression.  Accept mail on the
relay, UUCP-over-TCP it to a relay on the inside of the link, and send
it to the destination there via SMTP... or something like that.

Maxmimizing your share of the line:

A little setsockopt( SOL_IP, IP_TOS, IPTOS_RELIABILITY ) in the smtp
transport agent might cut down the packet loss a little.  Perhaps.

Use a hack like that Matti Aarnio used at vger in order to run more
deliveries in parallel.  His problem, as I understood it from a casual
look at the source, was that he needed to run more majordomos in
parallel.  Grep around in the source for something about majordomo and
vger.  Perhaps you can adapt it to run N smtp clients in parallel, and
thus increase your share of the bandwidth by a factor of almost N.

Switching to UUCP-over-TCP will very likely increase your share of the
bandwidth, too, perhaps by a great deal.

I'm sure some of the others on the list have suggestions I haven't
thought of.

--Arnt