• The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Email never arrives, smtp times out, relaylock messages in mail.info log

  • Thread starter Gustave Stresen-Reuter
  • Start date
G

Gustave Stresen-Reuter

Guest
(note: email addresses and domains have been obfuscated but the IP addresses are all real)

A client is trying to send me email but their messages never arrive. Likewise, they see smtp timeout messages in their logs in response to their attempts to send email:

to=<[email protected]>, relay=mail.mydomain.com[204.11.244.248]:25, delay=21394, delays=21364/0/30/0, dsn=4.4.2, status=deferred (conversation with mail.mydomain.com[204.11.244.248] timed out while receiving the initial server greeting)

I'm seeing the following in my mail.info logs:

Jan 20 11:03:32 myservername relaylock: /var/qmail/bin/relaylock: mail from 82.98.131.91:39135 (server.theirserver.com)

From what I've read on the Internet, relaylock does some kind of checking of sender IP against a database and if the IP passes the test, the request is forwarded on to qmail-smtpd. However, there is absolutely NO documentation on what relaylock is nor how to configure it and based on the name, I'm not convinced that what I've read is actually true.

Many people suggest adding -Rt0 to the tcp_env command in /etc/inetd.conf to disable reverse DNS lookups and (I assume) remove the timeout limit, but I've been unable to get this switch to change qmail's behavior.

I'm desperate for a solution to this problem and would greatly appreciate any help anyone on this forum can provide.

Thanks in advance!

Ted Stresen-Reuter
 
Relaylock itself is not the problem here, at least not in itself, and there's nothing to configure for it.

The remote server is having some form of difficulty talking to yours. Most likely the remote is misconfigured (or it's DNS is), given that you presumably have no problems with other incoming email.

With regards to those reverese lookups normally you'd add -Rt0 in /etc/xinetd.d/smtp_psa (and smtps_psa) if you are using a Centos/Redhat type OS (don't know about Debian et al)

i.e. server_args = -Rt0 (rest of the line)

Then restart xinetd (service xinetd restart)

This should really not make a difference though. It is most useful for when your customers have non-reverse-resolving IPs and use your server as an smtp server.

But try it anyway. If it works, great. If not ... use www.dnsreport.com on your domain and see if it reports any significant errors. Do the same one his domain too. You never know, you might spot something.

Faris.
 
I have had similar problems ... the problems arise out of multiple problems and I believe they are due to auth and spam checks on the server; my problems were found and solved:

1. IP address black listed for SMTP relaying at spamhaus.org - go to spamhaus.org and request removal - takes 30 mins or less to get that removed

2. SPF rules misconfigured or too strict ... server SPF rules have to be specified correctly ... keep it simple use

3. Multiple SMTP or IMAPD connections from same IP ... various fixes

4. Misconfigurations of Qmail ... permissions etc etc

some other problems.

Qmail to me is the most horribly designed software and postfix is no better. Unfortunately do not have an alternative.
 
Back
Top