1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

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

Discussion in 'Plesk for Linux - 8.x and Older' started by Gustave Stresen-Reuter, Jan 20, 2010.

  1. (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=<me@mydomain.com>, 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
     
  2. Faris Raouf

    Faris Raouf Silver Pleskian Plesk Guru

    31
    30%
    Joined:
    Mar 15, 2009
    Messages:
    667
    Likes Received:
    17
    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.
     
  3. adiwan

    adiwan New Pleskian

    22
     
    Joined:
    Oct 5, 2008
    Messages:
    4
    Likes Received:
    0
    Location:
    PVD
    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.
     
  4. adiwan

    adiwan New Pleskian

    22
     
    Joined:
    Oct 5, 2008
    Messages:
    4
    Likes Received:
    0
    Location:
    PVD
    Check other DNSBLS lists besides Spamhaus ... dnsbl.info checks a bunch of them
     
Loading...