Sorry for all the email problems you've been having. I've come over from our system administration team to the customer community department, and have a lof of experience troubleshooting email bounce back issues
, so hopefully I can shed some light on this problem for you.
The current issue that you're experiencing, appears to be from what we can tell, directly related to the mail server you are sending into our mail server from (www1.webmail.pair.com
). I don't see any indication of this being a standard 550 email error
indicating an unknown user.
It seems that this mail server that is attempting to send mail for (email@example.com
) is connecting to our mail server, and then attempting to do a sender verify for that same address. This fails because it is trying to force our mail server to verify an address that doesn't exist on our server, when it should be doing the sender verify check on their server, prior to reaching out to our server via SMTP
(Simple Mail Transport Protocol).
After our server responds letting the remote server know the user doesn't exist, there is then a (RSET
) command issued from the remote server closing the SMTP connection. This is what it looks like from the logs, I've replaced the remote mail server's IP with [x]
and our IP with [IMH]
12:02:25 SMTP connection from [x] I=[IMH]:25 (TCP/IP connection count = 57)
12:02:25 H=www1.webmail.pair.com [x] I=[IMH]:25 Warning: Sender rate 1.9 / 1h
12:02:25 H=www1.webmail.pair.com [x] I=[IMH]:25 sender verify fail for <firstname.lastname@example.org>: No Such User Here
12:02:25 H=www1.webmail.pair.com [x] I=[IMH]:25 F=<email@example.com> rejected RCPT <firstname.lastname@example.org>: Sender verify failed
12:02:25 H=www1.webmail.pair.com [x] I=[IMH]:25 incomplete transaction (RSET) from <email@example.com>
12:02:25 SMTP connection from www1.webmail.pair.com [x] I=[IMH]:25 closed by QUIT
Here you can see what a normal SMTP connection looks like when sent from a standard mail server that is not encountering this issue, and you can see that it also forwards to the Gmail account successfully:
16:42:42 SMTP connection from [IMH-Office] I=[IMH]:25 (TCP/IP connection count = 31)
16:42:50 IMH 1UpPDN-0007Mn-13 <= firstname.lastname@example.org [IMH-Office]:50098 I=[IMH]:25 T="Test email, please disregard" for email@example.com
16:42:50 SMTP connection from imh-srv.inmotionhosting.com [IMH-Office]:50098 I=[IMH]:25 closed by QUIT
16:42:51 1UpPDN-0007Mn-13 => firstname.lastname@example.org (email@example.com) <firstname.lastname@example.org> F=<email@example.com>
16:42:51 1UpPDN-0007Mn-13 Completed QT=2s
It's almost as if the remote mail server is attempting to use our server as an open mail relay, which it is not. Rather than queuing up the mail for delivery locally via a local MTA (Mail Transfer Agent) on their end, and then starting a SMTP session with our mail server to hand off the message.
Also I'd like to point out two important tidbits of info. When attempting to send mail to (firstname.lastname@example.org
) this domain has the MX (Mail Exchange) records set to mailwash48.pair.com
for delivery. When I attempt a manual SMTP connection via telnet to this mail server, it temporarily rejects any delivery attempts for that address:
250 2.1.0 Ok
450 4.7.1 <email@example.com>: Recipient address rejected: Service temporarily unavailable
A 450 email error
indicates a temporarily delivery issue, typically relating to Greylisting. This is a practice of outright rejecting a message on its first delivery attempt, so that it will remain queued on the sending server and attempt delivery again at a later time. This is to deter spammers who aren't using a properly configured mail server that will attempt re-delivery attempts. This could possibly also be causing the strange communication problem between the two mail servers, but wouldn't be within our control to investigate or resolve from our end.
Also, you typically do not want to impose an extra unnecessary duplication of SMTP communication in your mail stream. I would HIGHLY
recommend that you delete the email forwarder pointing to your Gmail
account, and instead configure Gmail to check your POP3 account
The difference is that if your LynnGray.com
email address gets 100 spam messages sent to it, you are then forwarding those onto Gmail
and their server sees our server as the last relaying IP address. That can eventually lead to a blacklisting or delay in deliveries, and other issues. If you instead are using Gmail
as your online mail client, you can simply retrieve the messages from your LynnGray.com
account via POP3 into Gmail
. This is definitely the preferred method from both our own, and Google's perspective, and I POP in about 10 email accounts to my own Gmail
without any issues at all.
I would recommend attempting to send to your email account from various other services other than Pair.com
. If the general consensus is that they all work except for that one service, then I would assume it'd have to be something on their end causing the issues.
Please let us know what you find out, and hope that helps!