Ken Sarkies wrote:
Many thanks for the advice. I'm a tad confused at this point as I don't
really know enough about how Courier communicates with other
mailservers. There is no "me" file so above commands just gave the FQDN
for the server machine hta21.trinity.asn.au.
That's fairly normal. Most sites don't need a "me" file. However, your
FQDN *does* need to resolve at all of the sites to which you connect,
and the "me" file is available if that isn't the case (for whatever reason).
This is not accessible
directly from outside the LAN. All external email to domain
trinity.asn.au is directed to our external IP address, and we forward
port 25 from the router
Then put the FQDN of your router in "me". Don't forget to run
"makealiases" after changing the "me" file.
(which I gather would be a typical small system
setup). I have set the defaultdomain file to trinity.asn.au and that
appears to work fine. We have been running Courier-MTA for 2 and a half
years without any apparent connection problems, certainly nothing
visibly associated with DNS resolution.
Do you read all of your "postmaster" mail?
We also have the esmtphelo file set to mail.trinity.asn.au which is not
a machine inside the network - it is just a dummy identifier.
Obviously it resolves, though. It's your MX.
Is it that Courier is sending DSNs with the full machine hostname that
is causing this?
It's related. Courier uses the hostname of the machine on which it runs
for certain operations, and the dialback module of pythonfilter does, too.
I was wrong about the DSN bit, though. Courier actually uses no return
address when sending DSNs. You can do that in dialback, too, if your
python isn't super old. Just modify the dialback.py file and set:
postmasterAddr = ''
You might run in to a minor problem: some sites don't accept mail from
null senders. Those sites are in violation of RFC requirements, so you
can decide for yourself whether or not you want to accept mail from them.