I host email for a number of different domains - lets call one of them myuser#receiver.com. Lets also pretend my domain is called myserver.com. I receive and store email in a mailbox locally for these domain on mx1.myserver.com. I am having an odd sporadic email issue which I feel must stem from a misconfiguration or setup on my part. This problem only occurs when a 3rd party acts as a forwarder (intermediary), receiving the email for myuser#receiver.com but sending it on to myuser#www.myserver.com. The exerts below are directly from the email message source.
An email is sent by someone to one of my clients. Its received by an intermediary.
Received: from email.sender.com (the.sender.com [123.123.123.123])
by the.forwarder.com (8.14.5+Sun/8.14.5) with SMTP id x12XXXxX123456
for <myuser#receiver.com>; Thu, 5 Mar 2015 13:23:22 GMT
That intermediary then forwards the email to my server, but for some odd reason readdresses it.
Received: from the.forwarder.com (the.forwarder.com [234.234.234.234])
by mx1.myserver.com (smtpd) with ESMTPS id 1234X123X1
for <myuser#www.myserver.com>; Thu, 5 Mar 2015 08:27:11 -0500 (EST)
Why is the.forwarder.com (intermediary) rewriting the domain of the recipient on this message?
Some outgoing SMTP servers are known to re-write the headers on outgoing messages, and change the sender's address in From: line to the email address of the user that is authenticating. Gmail is notorious for doing this. See How to change reply-to and return-path header with gmail smtp in django for more info.
In the end this was caused by CNAME records in DNS. There were CNAME records that were present mainly for virtual hosting of web services. This would be something like CNAME record of receiver.com points to www.myserver.com (since they share the same IP address). This had the effect of making secondary mail delivery servers address mail to www.myserver.com instead of the intended receiver.com. To fix this I removed the CNAME record and created an A record to the actual IP address.
Related
So far my main.cf contained, primarily, two following lines:
local_recipient_maps =
luser_relay = mrjoe#mydomain.com
These settings are responsible for delivering all emails sent to any address in my domain like random_string#mydomain.com to my real account mrjoe#mydomain.com. This worked and I was receiving emails only from websites where I signed up with any of my unlimited aliases.
I realized that I don't want to receive all these emails, so I came up with an idea to discard emails sent to particular alias instead of blocking a particular sender. In this way, I can protect myself from any future unwanted email and somehow make this alias disabled.
To bring this idea to life I removed the previous two lines from main.cf and added the following one:
virtual_alias_maps = pcre:/etc/postfix/virtual_alias
The virtual_alias file has following content:
/^((?!^(blacklisted_address|another_blacklisted)#).)*$/ mrjoe#mydomain.com
This configuration redirects all emails sent to addresses other than blacklisted_address#mydomain.com and another_blclisted#mydomain.com to specified real address mrjoe#mydomain.com.
This works, emails sent to listed addresses are not delivered to my inbox. The problem is that now I started to receive hundreds of spam emails, none of which I received before.
Here is one example of such spam message:
From secretariat#solid-app-api.be Wed May 29 01:23:10 2019
Return-Path: <secretariat#solid-app-api.be>
X-Original-To: mrsnorah11#gmail.com
Delivered-To: mrjoe#mydomain.com
Content-Type: text/plain; charset="iso-8859-1"
Content-Description: Mail message body
Subject: 21.21.21.21 // my IP here
To: Recipients <secretariat#solid-app-api.be>
From: "Agent MacLeod" <secretariat#solid-app-api.be>
Date: Tue, 28 May 2019 16:23:10 -0700
X-UID: 1194
Content-Length: 3686
Status: RO
So the question is: why did I start to receive hundreds of spam messages after making changes described above? How is it possible that now messages with X-Original-To header different than #mydomain.com are delivered to my domain?
As for now, I brought back the previous configuration and I no longer receive spam messages. Clearly, this is not an acceptable solution.
In your old config, luser_relay delivered all "mail for unknown recipients in domains that match $mydestination, $inet_interfaces or $proxy_interfaces" (thus your domain) to your mailbox.
Your new configuration accepts mails for any recipient domain. The regex matches any email address except the blacklisted ones. All mails forwarded to your address mrjoe#mydomain.com, hence the X-Original-To header.
Spammers send mails with other repients (like gmail.com) to your server because your server accepts it. They think that you're running an open relay (which you probably don't).
I am creating a webservice with Mailgun to send out emails. It will BCC my own domain's email for every email sent out. Assuming my domain is "example.com". For every email sent out to a customer, say, customer1#gmail.com, I will BCC its content to sales#example.com.
Currently, the domain example.com and its email is hosted on a server with CPanel.
In Mailgun, I have added and verified the domain example.com. Using this domain, I've sent a mail to customer1#gmail.com and sales#example.com. The email is sent without issues to Gmail, however when sending to sales#example.com, I keep getting the error Server response: 550 550 Verification failed for <bounce+e0f051.e0179a-sales=example.com#example.com> No Such User Here.
What's baffling here is that if i send the email via Mailgun with another verified domain such as anotherexample.com, and then using this, I send my mail to sales#example.com. The email arrives perfectly fine without errors.
So far, the things I've tried:
Added Mailgun suggested SPF and DKIM
Modified SPF to include my CPanel server's IP (together with Mailgun SPF)
Deleted both the SPF and DKIM (one at a time and both at once)
Verified that the email sales#example.com exists. Using the CPanel webmail's interface, I can send and receive emails just fine.
Tried updating the CPanel MX entries Email routing from Local -> Automatic -> Remote. ("Local" works the best. If its set to "Remote", email sending and receiving doesnt work at all, even if mails are sent through Gmail/Hotmail).
My current MX settings are:
Priority 0: mail.example.com
My current Zone file records on CPanel:
example.com A <some ip>
mail.example.com A <same ip as above>
The code I am using to send mails via Mailgun (Ruby):
mg_client = Mailgun::Client.new 'xxxxxxxxxxx'
message_params = {:from => from_email,
:to => customer.email,
:bcc => bcc_email,
:subject => MessageTemplate.email_subject,
:text => message}
result = mg_client.send_message('example.com', message_params).to_h!
I currently do not have the SPF and DKIM records in the zone files. I've added and removed them and they had no effect on the error (still delivers fine to Gmail too).
I've spend the whole on this, scouring forums and whatnot but can't seem to find a solution.
If at all relevant, I have a 301 redirect of example.com to www.example.com(Which has a CNAME pointing to another server). But I've researched and found out that 301 redirect does not affect emails.
I don't think this is a send-side problem. You're sending to sales#example.com, but you're getting errors relating to bounce+e0f051.e0179a-sales=example.com#example.com, which is a typical VERP address. Now, VERP addresses are fine, so long as you're expecting them. Given that you are not apparently providing that explicit address to MailGun, I assume that they are generating that address automatically. I would check their documentation for how they generate return-path (envelope sender) addresses, and either override the sender address (with just sales#example.com), or configure handling of those VERP addresses on your own inbound mail server.
Here is a mailgun explanation
This error occurs due to what is termed Sender Address Verification (SAV). During SAV, an email server performs an MX lookup upon the domain (example.com) listed within the message envelope's Mail-From field. SAV typically rejects the message if,
the sender's (in this case, Mailgun's) MX records are not configured for that domain AND
the domain of the message envelope's Mail-From field does not match the domain of the message header's From field.
https://help.mailgun.com/hc/en-us/articles/360011804533-Sender-Verification-Error
Is it a problem if 127.0.0.1 appears in email headers?
Example: Received: from baobabsmail.baobab.fi ([127.0.0.1])
I ask because emails sent from my server to #outlook.com addresses end up in the spam folder and this is the last thing I can think of. I have properly configured HELO, DKIM, Reverse DNS, SenderID, SPF and DMARC. I don't send out mass emails. My IP is from AWS, but it isn't on any publicly available blacklists. I have verified that everything is set up correctly using DKIMvalidator, MxToolBox and mail-tester.
Edit: for what it's worth, I finally got rid of the 127.0.0.1's in my headers and it did not resolve the issue for me.
Unfortunately, it depends...
Mail systems vary in how they are configured, and it is perfectly legitimate for an MUA (e.g. Thunderbird) to send outgoing mail to an MTA / mail server (e.g. exim) running on the same machine using the localhost address. Unusual, these days, but not "bad by definition".
When you say 'end up in the spam folder', what is it that puts it there: are you using a local mail server? if so is it that server that junks the mail (on send) or outlook.com itself (on receipt). Either way, what error messages or other failure information have you found?
Some random thoughts:
DKIM is a pain to set up correctly. Try disabling it entirely and see if that changes things in interesting ways.
Ditto DMARC.
Have you got SPF set up separately? If so, disable SPF and retry.
Is IPv6 involved in the mix at all? Various things are subtly different if so.
If outlook.com were to do sender verify callbacks (i.e. on receipt, check that mail from address was an acceptable recipient to your server) would it pass?
Is your email system sending RFC-conformant mail: that is, does it have a From: address, To: or Sender: address, Message-ID:, Date: headers and, if using MIME, Content-* headers (and probably a couple I forget!).
If changing DKIM / DMARC / SPF changes things (and remembering DNS timeouts, leave it a while between attempts), re-add SPF first - it is the simplest to get right.
127.0.0.1 can be flagged by Spam filters because it fails to provide an identity trace of the sender. Most common e-mail systems will show the IP address or the host name. The next item will be the recipient e-mail server.
For example:
Received: from [127.0.0.1] (81.27.148.196) by TAE1.agent.com.pk
What is funny about this one is that the top-level domain says it is received initially by a domain in Pakistan, but the IP address is registered to an entity in St. Petersburg, Russia.
I use dnsimple to host my DNS and have valid SPF, DKIM, and DMARC records to validate my emails sent from Zoho. However, Whenever I send emails to an #ucdavis.edu account I get an Undelivered Mail response
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its recipients. This is a permanent error.
lsmiyashita#ucdavis.edu, ERROR_CODE :550, ERROR_CODE :5.7.1 <admin#study.space>... Access denied
Received:from mail.zoho.com by mx.zohomail.com
with SMTP id 1478675695600485.6815385213283; Tue, 8 Nov 2016 23:14:55 -0800 (PST)
Message-ID:<15847f087ed.112901d8e106580.9166398699723335101#study.space>
Date:Tue, 08 Nov 2016 23:14:55 -0800
From:Jacob Bevilacqua <admin#study.space>
User-Agent:Zoho Mail
To:"lsmiyashita" <lsmiyashita#ucdavis.edu>
Subject:Here's a little test for you.
Content-Type:multipart/alternative;
boundary="----=_Part_335760_1020694757.1478675695597"
I have tried several different hosts (GSuite, MailGun, & Zoho) and I get the same issue. I checked and I am not blacklisted on any sites. I ran a test at mail-tester.com and got a 10/10. Why won't my messages deliver.
I verified that the email address you are sending to is valid: Verified Email Address
So like #Synchro says, they just don't like you. It's always a challenge to figure out the exact reason, but contacting their admins is the right way to go. I have a feeling it's because of the .space domain ending, they probably haven't updated the list of domain endings they accept.
Anyway, if you wanted to do additional mail testing, use this Mail Tester.
You are under the unfortunate illusion that it's your fault. A 5.7.1 error means that they just don't like you, and they don't have to give a reason. Welcome to the world of deliverability, or lack thereof. Well-behaved mailers are often punished for no particular reason. If it's just this domain, your best bet might be to contact their admins.
I recently moved my transactional email sending to Mailgun
It works good so far however I am wondering about the return-path header.
Consider this email (I removed irrelevant header and replaced email/domain for privacy purposes)
Delivered-To: RECIEVER#gmail.com
Received: by 10.76.154.104 with SMTP id vn8csp478308oab;
Wed, 4 Sep 2013 05:04:44 -0700 (PDT)
X-Received: by 10.50.22.105 with SMTP id c9mr1537992igf.36.1378296283817;
Wed, 04 Sep 2013 05:04:43 -0700 (PDT)
Return-Path: <bounce+a801a1.c2b37-RECIEVER=gmail.com#my-website.com>
Received: from so254-63.mailgun.net (so254-63.mailgun.net. [198.61.254.63])
by mx.google.com with ESMTP id k5si1620852igx.55.1969.12.31.16.00.00;
Wed, 04 Sep 2013 05:04:43 -0700 (PDT)
Received-SPF: ...stripped...
Authentication-Results: ...stripped...
DKIM-Signature: ...stripped...
DomainKey-Signature: ...stripped...
Received: by luna.mailgun.net with HTTP; Wed, 04 Sep 2013 12:04:42 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: ...stripped...
From: my-website <support#my-website.com>
To: RECIEVER#gmail.com
Message-Id: <20130904120442.1488.88532#my-website.com>
X-Mailgun-Sid: WyI5YmI1OSIsICJqb2Vob3BmK2VlZ2VpN2lkMm9pbW9vYm9vZmFpQGdtYWlsLmNvbSIsICJjMmIzNyJd
Date: Wed, 04 Sep 2013 12:04:43 +0000
Sender: support#my-website.com
Content-Transfer-Encoding: base64
...email body...
This is the Raw email displayed from an actual mail in a gmail inbox.
As you can see the Return-Path header contains an email address that ends in #my-website.com
But I have only set up dns records for outgoing email (spf, domainkey, etc).
Not for incoming email. Meaning, my MX records still point to mailservers somewhere else (In my case google apps).
How is it possible then that the bounce email arrives at mailgun servers?
I would have expected to see an email address ending in #some-mailgun-server.com in the Return-Path header!
I have been using Amazon SES before, and there they had Return-Path header ending in amazonses.com
I asked the mailgun support and got this response:
Nick: your setup is correct, Mailgun will still automatically handle
the bounces even though your mx records are pointing elsewhere
They just assured me that everything was fine but gave me no explanation (which is okay since their job is not to teach me things I don't know but to deliver reliable email service...)
So I hope somebody can explain this to me.
I hope the point is clear, if not please ask and I will try to clarify my question.
EDIT:
One theory of me is that the bounce email is indeed sent to google mail servers where it is discarded. However that this is redundant since the error response is also sent to the sending mailserver during the process (when it opens its tcp connection to the target mail server).
To test this theory and since the Return-Path email is in the form of bounce+SOMETHING#my-website.com, and google delivers all email, regardless of what comes after the + character, to the user in front of it, I went ahead and created the account bounce#my-domain.com on google apps.
I also tried to send an email to bounce+a801a1.c2b37-RECIEVER=gmail.com#my-website.com.
It made it through to my inbox.
Now I expected to receive bounce traffic in my inbox. So I sent an email to an nonexistent hotmail address. I did not receive email on my google apps inbox, and mailgun successfully tracked the bounce.
So... It appears that it does indeed work. I just don't understand why.
One more theory I have is that the mailserver to which the bounce email is delivered is never resolved using its MX records. Rather always the delivering server, in this case luna.mailgun.net is chosen.
The domain ending in the Return-Path address is just the name of the mailbox on the server, but the domain has nothing to do with the server where the mail is actually delivered.
Then it would also make sense to make it like this since it might improve deliverability if the domains of From and Return-Path address match.
However this is only a theory. And it would also mean that a mailbox which is able to receive bounces, must be on the same server that is used for sending.
In other words it would be impossible to have a mailbox to receive bounce email addresses that is hosted somewhere else than the actual server sending the mail. But this sounds strange to me as well...
I hope somebody can enlighten me.
Turns out that there are different kinds of bounces.
When bounces occur they are generally returned to the server that is sending the email, and do not follow the MX records.
Thats why they are sent to the mailgun servers and also arrive there.
However there are also so called "Delayed Bounces" that are sent to the server declared as mailserver using MX records in the domain.
Those delayed bounces are generally difficult to handle and there are opinions out there that they violate RFC.
Those bounces are however very, very rare. Thats why mailgun does not handle them. The reason they use the clients domain in the return-path address is so that they can assign it to the right account. They just encode it that way...
In fact, as I was setting up my mailbox for bounces on my google apps mail, I recieved one such delayed bounce.
It was this email that made proper debugging possible which lead to the understanding of this issue.
So to sum up:
Yes, the address is incorrect. That is no problem for most bounces since the server does not use MX records to send them, but sends them directly to the server that has initated the conneciton.
However in case of delayed bounces, that also some times happen, the bounce will indeed go to the server behind the mx records of the domain specified in the return path address.
Those emails are not properly recognised as bounces at mailgun servers.