Sender Verify & Gmail
We have a weird issue on a box where an external party is sending emails to an account and using a gmail address in the from field. Sender verify then tries to verify BUT it results in:
SMTP error from remote mail server after end of data: 421-4.7.32 Your email has been rate limited because the From: header (RFC5322)\n421-4.7.32 in this message isn't aligned with either the authenticated SPF or\n421-4.7.32 DKIM organizational domain. To learn more about DMARC alignment,\n421-4.7.32 visit\n421-4.7.32 https://support.google.com/a?p=dmarc-alignment\n421-4.7.32 To learn more about Gmail requirements for bulk senders, visit\n421 4.7.32 https://support.google.com/a?p=sender-guidelines. 2adb3069b0e04-5930281e4bfsi3562663e87.416 - gsmtp
This is resulting in our accounts domain being labeled in googles postmaster tools as:
| Reject | Suspected spam |
Assuming that its due to the sender verifiy trying to verifiy the non existient gamil address being used by an obvious spammer. We have blocked that senders IP but they just start using a different IP.
We suspect that its a pretty sneaky way to tarnish a domains rep. a bit like negative seo.
It is hurting the domains email sedning rep and the only option that comes to mind is to turn off sender verify (which we would not prefer to do) and you cannot whitelist a domain plus googles email service has so many different IPs it doess not seem the best way to add those? or is it?
anyone else have this experience? what steps can be taken to block the current spammer and prevent such an issue for the future?
-
That would be an email originating from your server or being forwarded by an account on your server, causing an the error you show (which originates from the Gmail platform end when Gmail received it).
1. If one of your users authenticates as xyz@domain_on_server but sets the FROM address to be an email address not within the @domain_on_server domain, that could do it. If that is what is happening, it should never be done. You're users should always be sending with a valid FROM address whose email account exists on the server, or at least from a valid and properly configured domain on the server.
2. If somebody from Gmail, Yahoo, AOL, Comcast or any company who is strictly enforcing DMARC sends an email to one of your users and your user has their email forwarded to Gmail, that could cause the issue. you would want to make sure that you have SRS enabled.
Even with SRS enabled, there are emails that may be received by your users and automatically forwarded to external addresses that still do not pass SPF / DKIM / DMARC for some reason or another. But having SRS enabled certainly helps.
For instance, if I had SRS disabled on my server and I sent a message from my @yahoo.com account to joeblow@serverexample.com (an email account on my server) and joeblow@serverexample.com is set to forward emails to joeblow1985@gmail.com, Gmail is definitely going to come back with message indicating that DMARC failed if SRS is disabled, and may in some circumstances come back with that message If SRS IS enabled.
In today's email world, forwarding is bad. We all do it, all the time. But remote mail systems do not like to deal with forwarded email and often scrutinize those emails even more closely.
0 -
That would be an email originating from your server or being forwarded by an account on your server, causing an the error you show (which originates from the Gmail platform end when Gmail received it).
So let me understand this correctly and clarify just in case.
So an external sender sends an email (which is seen as sent from a gmail account - via a spoofed header) to a cpanel account, sender verify is enabled on the sever. The server tries to verify the gmail account quite a few times and fails. This same sender resends the email a number of times for a period of a 3-4 hours. This results in that message as can be seen in the server mail delivery reports section... where is shows the delivery details attempted BUT not the actual contet of the email.
My mind tells me its not an issue with the account hosted on the server?
To further clarify, the account on the server does have a forwarder that goes to a gmail account BUT I assume that fowarder step would only kick in ONCE the sender verify has been successful?
Does that makse sense? is your answer thus still applicable???
0 -
I don't know about sender-verify, and I don't know that sender-verify is going to do any checking on whether the incoming email (if it is external coming in to your user) is valid and passes SPF/DKIM/DMARC.
Based upon what you've shown, I don't know for a fact that it was a Gmail email coming in and then getting forwarded back out to your customers Gmail account. It could have been an email from any company who has DMARC set up with proper SPF/DKIM in place, so that emails from their company can't normally pass through forwarding (thus preventing phishing).
Without seeing logs for myself I couldn't tell you. I'm just saying that what is looks like to me is that:
1. A user on your account is authenticating properly as themselves to send a mail but has put an @gmail address (or AOL, or Comcast, or Microsoft, or any other company with strict DMARC compliance in place) in the FROM field as the sender. That's not going to pass when it hits Gmail's platform.
2. More likely scenario is an email sent externally (again from an @gmail.com address or AOL or Comcast or Microsoft, or any other company with strict DMARC complaince in place) was sent to one of your customers on your server -- and that customer has a forward on their account to a Gmail address.
Usually, if you have SRS enabled, that will allow most forwarded emails to pass SPF/DKIM/DMARC checks when the hit Gmail, but not all.
Same for any emails being forwarded to AOL, COMCAST, MICROSOFT or other companies enforcing strict DMARC policies.
Making sure you have SRS enabled, and making sure that all the accounts on your servers that send email have proper SPF / DKIM / DMARC set is the best that you can do. There will always be some forwarded message (legit or not) that is not going to end up making it through.
Forwarding shouldn't be done. My customers do it, your customers do it. I do it myself, and you probably do too. But in this day and age it is harder for forwarded emails to make it to the destination mailbox, and when they do they are sometimes found in a spam/junk folder.
You can't post log specifics on this forum. But if you trust me and you want to send me all of the relevant /var/log/exim_mainlog information for that particular email transaction (there will be two separate IDs -- one transaction when the email comes in from the external source, and one when the received email is forwarded off to Gmail) then feel free to shoot me an email at mtindor at Gmail
Otherwise, that's all the advice I can personally offer you.
0
Please sign in to leave a comment.
Comments
3 comments