🚀 go-pugleaf

In article <821135729snz@pdlmail.demon.co.uk>,
           Peter Disdale <pete@pdlmail.demon.co.uk> wrote

>what effect (if any)
>does the size and/or number of files in ~/spool/mqueue have on
>SMTP performance?  My observations are that one ot two small
>messages are accepted quite quickly, but that 5 or more largish
>files (eg. 5 x 50k) do not move *at all*.

On a mail kick, KA9Q scans the mqueue directory and attempts a DNS lookup 
for each of the outbound messages, using the first line of each .wrk file 
to resolve the mail domain to a destination IP address to attempt to 
connect to.  Once it knows to which machine each piece of mail is 
destined, it can make up to 10 simultaneous connections to different 
machines, sending multiple messages for the same machine in the same 
connection.

Since all the addresses are resolved first, the more messages you have,
the longer the lookups will take, especially if the DNS server takes a 
while to get back to you.

To get an idea of whether it is the DNS lookup that is causing the 
problems, you could add 'domain trace on' (or 'do t 1' will do) to 
autoexec.net and watch for the lookups and responses.  

'domain listservers' ('do l') will show you the stats for each DNS server 
you have configured - responses, timeouts, etc. with the most recently 
used at the top of the list.

The other problem that you might see, depending on where your mail is 
destined, is that the mail domain resolver in KA9Q is, I believe, 
somewhat broken and does not comply with RFC974 (STD 14 - "Mail routing 
and the domain system") - if an MX (mail) record doesn't exist for the 
given mail address, KA9Q should attempt to contact the host in the 
address directly, but it doesn't - it starts making up wildcard 
truncations of the address and looks these up - which takes ages and 
doesn't get any response from the servers, eventually it will give up not 
having found anything and only then try and send it to the real host. I 
did have a look at fixing it, but decided it wasn't quick nor easy since 
there are no success/failure checks anywhere to differentiate from the 
server returning no MX records :(  (There's a similar problem elsewhere 
in the SMTP client where under certain circumstances, bounced mail can be 
deleted without trace rather than returned)

If you regularly send mail to an address which doesn't have an MX record,
a quick bodge is to forge an MX record in your local cache by adding a 
line like this to ~/domain.txt (note the trailing dots, and the tabs 
might be important):

some.host.com.	IN	MX	0	some.host.com.

(a check would be to use 'dom qtype 15' to look up MX records, followed 
by 'dom query some.host.com' - if the result looks like 
'some.host.com IN MX [blank]' then it's likely it doesn't have one)

>And if someone has worked out how the 'smtp wait 20' command
>works (or doesn't...) I'd love to know too.

smtp wait controls a timer which times out connect attempts, it is also 
used in timing the opening of connections to news and the time server. 
The 'smtp wait' parameter is in seconds and stored in the global variable 
connect_wait_val in ms.  connect() calls are run under a watchdog timer 
started by alarm(value) and reset with alarm(0L), if the timer expires 
then connect() will return failure.

The default in KA9Q, if none is set in autoexec.net, is 60s - I think, as 
you say, the present installed default is 20s which IMHO is too low given 
the present network performance at peak times (I'm using 60) - before the 
last overhaul of the punts, I found a wait value of just over 30s was 
usually needed to successfully send inter-demon mail to them.  (exactly 
30s on a few occassions produced an odd result of the punt banner 
appearing just as the connection was dropped - never did suss out that 
one).

Cheers,

      Graham.
-- 
----[ Graham E. Kinns ]----==========----< Graham@grempc.demon.co.uk >----