Depending on my DMARC settings out of office replies are not arriving (if DMARC is setup to reject), or being sent into junk (DMARC is setup to quarantine) to gmail or yahoo emails, it works fine when its communication between exchange mails.
The reason for this, as it was explained to me by our support, is that when exchange generates an out of office reply it generates it with an empty RFC5321.MailFrom field, which according to RFC standards makes it invalid because there is a difference in the From and MailFrom fields. According to RFC 3798 - Message Disposition Notification it states that the MailFrom field must always be null to force the out of office message to be sent only once.
The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be
null (<>), specifying that no Delivery Status Notification messages
or other messages indicating successful or unsuccessful delivery are
to be sent in response to an MDN.
The question being how do I work around this, when I setup out of office on a gmail address and send a message to it I get a returned out of office message. So this only doesn't work when the message is sent from a gmail or yahoo account to an exchange.
I'm gonna post the answer I got from reddit that seems to be correct by /u/omers:
The solution is DKIM. The null return-path only affects SPF alignment
in DMARC which can be compensated for with DKIM alignment. As long as
you're DKIM signing all of your domains and the signatures are applied
to MDNs you'll have no issues.
If you're on-prem and only have one domain you can also make SPF
alignment work with relaxed alignment. When the MailFrom/return-path
is null, SPF alignment is performed between the EHLO/HELO hostname and
the header from address. Ie, if your mail server identifies as
mail-exch-01.example.com and the message has a header from of
bob#example.com it will align even without a return-path. Obviously
doesn't work in the cloud with onmicrosoft.com being the EHLO domain
unless you force MDNs to use the user's onmicrosoft.com address. DKIM
is still easier.
Related
We've used Mailgun for 8+ years for inbound email routing, and always noticed lots of emails ended up in our spam folder(s).
After speaking to the Google team, it turns out that Mailgun is simply not compatible with Gmail when using inbound routes as it doesn't "relay" emails, but rather re-sends them modifying the headers.
This causes all emails to fail SPF! This means a certain (often large %) of your emails will end up in the spam folder for no good reason.
From Google:
"We've identified that Mailgun is re-sending those emails, while Google is expecting for those emails to be relayed. Re-sending emails causes the SMTP sender to change to [redacted]. What happens then is SPF is checked for [redacted]. Inbound gateway is telling to ignore Mailgun's IP address, so the previous one is being used instead. This would cause all emails to fail SPF.
In this scenario, it's recommended to contact Mailgun and ask them if there's a way to relay those emails, so that SMTP sender would not change."
Mailgun Response:
"Unfortunately, there isn't much that can be done to prevent this as this is how our Routes work"
Any solutions?
Has anyone managed to work around this issue?
Or does anyone have a fully-featured recommended alternative to Mailgun Routes?
I have an email address forwarding to a gmail account. I then use SMTP to send a response from gmail via the domains SMTP server. This is all set up fine. However some recipients are not receiving the emails? Is there further configuration I need to do on the domain side?
I am told I need to configure the SPF, DKIM and DMARC records but I have no idea what the configuration/values should be?
Having SPF, DKIM and DMARC set up is seldom a prerequisite for having your email delivered. If your email domain and servers have a decent reputation, you won't, generally, run into to much trouble.
However, it is best practice to set up all three, to start authenticating your emails and making it harder for others to impersonate your email domain without authorization. I'll outline the basics for you:
Why Authenticate
Phishing: Email Authentication will make it harder to impersonate your email
domain, without authorization. It (somewhat) protects your colleagues, partners and customers against phishing.
Brand Reputation Protection: Phishing from your domain can harm the reputation of your brand.
Deliverability: Authentication improves deliverability because it's weighed heavily in determining whether or not the email is legit.
DMARC
DMARC will try to find successful authentication for servers sending on your behalf. Specifically, it will look for a Pass on SPF or DKIM, in alignment with the email address (domain) that is being showed to the recipient in his email client. This is known as the Header.From field. (Not to be mistaken with the Sender field, the Reply-To field or Return-Path).
SPF
SPF is basically a list of IP addresses, published as a TXT DNS resource record, listing all servers that are authorized to send email for the domain the record lives in. This does not include subdomains, those require additional SPF records. One of the (many) problems with SPF: Receiving servers need to check the Return-Path email address to lookup the SPF record, instead of the Header.From domain. There is no need for the Header.From email address and the Return-Path address to share any of the domain part, according to the SMTP RFC. Thus where DMARC comes in.
DKIM
Signing an email message with a DKIM private key, requires you to publish a matching public key in the subdomain _domainkey for the domain your signing for. The receiving server will look for d= value and the s= value in the DKIM signature to construct the correct DNS TXT resource record to query, holding the public key. Example d=stackexchange.email s=s1 will result in a DNS query for the TXT record s1._domainkey.stackexchange.email. The same applies here as with SPF: The d= value does not have to match with the domain portion of the Header.From email address.
Unfortunately the configuration and values are very specific, depending on which parties are allowed to send on behalf of your domains, the subdomains you use and how you use them, etc. Especially SPF has a few limits that will make the setup harder.
I am creating own mail server. I am using Haraka (http://haraka.github.io/). But I am little confused about the relay thing. How to make relay my mail server so that I can send mail using other domain(DKIM and SPF verified).
I want mail in receiver inbox not in Spam. Right now mail is received in spam. What is relay in particular ? Can anyone help ?
What I've got is that you're having a problem with sending mail on behalf of "other domain".
Given that "other domain" mail reaches its destination (even in SPAM folder) I assume that you've configured your relay right.
Key thing to notice is that DKIM and SPF records not only need to be validated but also need to be aligned with your "other domain". It's a common scenario when SPF/DKIM validations 'pass' but overall DMARC policy 'fails'.
Providing both your message headers (to check how it was processed) and your other domain name (to check how SPF/DKIM/DMARC records configured) would help a lot.
I know there are lots of questions on here already about being able to send emails to hotmail. I have read through them all, as well as lots of online posts over the last few weeks and have still been unable to fix this issue.
The issue that I am having is that I am unable to send emails to customers who have a hotmail email address. I can send emails to yahoo fine, I can also send emails to gmail as well (although these seem to go to the junk folder), however when I sent emails to hotmail email addresses, they just seem to never arrive.
I am using swiftMailer in a PHP Symfony2 Application to send the emails.
The server that my application sits on is a Linux CentOs box and I have open relay turned off
I have sent emails to 'auth-results#verifier.port25.com' to check that SPF, DKIM and Sender-Id is setup correctly. Partial output of that report is below:
==========================================================
Summary of Results
SPF check: pass
DomainKeys check: neutral
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham
==========================================================
The DomainKeys check is neutral, i'm not sure if that is required as as DKIM is an extension on the DomainKeys.
I have setup a v=spf1 record and a spf2.0/pra record in the DNS as TXT entries.
My help on this would be greatly appreciated. I think the issue may be to do with Sender-ID, but I dont know too much about this subject area.
Check your mail server logs. Are you seeing something like this for delivery to your Hotmail recipients:
550 SC-001 (COL004-MC4F43) Unfortunately, messages from xxx.xxx.xxx.xx weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
If so, then it means that your mail server IP is on Microsoft's blacklist. You probably won't have much luck sending to users at live.com, outlook.com, or msn.com either. Fortunately, there is a solution. See the link below for a decent guide on how to resolve the problem:
https://www.rackaid.com/blog/hotmail-blacklist-removal/.
The key is to submit a request to Microsoft to remove your IP address from their blacklist (at https://support.live.com/eform.aspx?productKey=edfsmsbl3&ct=eformts&wa=wsignin1.0&scrx=1), but don't do that until you are sure that whatever caused you to become blacklisted has been resolved, as Microsoft doesn't like repeat offenders.
On our mailing application we are sending emails with the following header:
FROM: marketing#customer.com
TO: subscriber1#domain1.example
Return-PATH: bouncemgmt#ourcompany.example
The problem that we are facing is that some email servers will bounce back a message immediately and use the from or reverse path (marketing#customer.example) instead to our bounce mgmt server. We want to know if we modify in the header the reply-to to be the same as the return-path if we will be able to catch all bounces.
Any other ideas are welcome?
We are using the following documents as references:
VERP
RFC
Bounce Messages
SMTP Log Parsing to get Bounces
EDIT 1: A few more bits of information to see if we can get this resolve.
We want to know at what point the email server relaying the message will choose to use the reply-to versus the return-path. We have notice that when the first SMTP server relaying the message gets rejected it sends it to the reply-to, but when it happens after one hop it sends it to the return-path.
Let's start with a simple example. Let's say you have an email list, that is going to send out the following RFC2822 content.
From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
Now, let's say you are going to send it from a mailing list, that implements VERP (or some other bounce tracking mechanism that uses a different return-path). Lets say it will have a return-path of coolstuff-you=yourcompany.com#mymailinglist.example. The SMTP session might look like:
{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<coolstuff-you=yourcompany.com#mymailinglist.example>
{S}250 2.1.0 me#mycompany.com....Sender OK
{C}RCPT TO:<you#example.com>
{S}250 2.1.5 you#example.com
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
.
{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel
Where {C} and {S} represent Client and Server commands, respectively.
The recipient's mail would look like:
Return-Path: coolstuff-you=yourcompany.com#mymailinglist.example
From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
Now, let's describe the different "FROM"s.
The return path (sometimes called the reverse path, envelope sender, or envelope from — all of these terms can be used interchangeably) is the value used in the SMTP session in the MAIL FROM command. As you can see, this does not need to be the same value that is found in the message headers. Only the recipient's mail server is supposed to add a Return-Path header to the top of the email. This records the actual Return-Path sender during the SMTP session. If a Return-Path header already exists in the message, then that header is removed and replaced by the recipient's mail server.
All bounces that occur during the SMTP session should go back to the Return-Path address. Some servers may accept all email, and then queue it locally, until it has a free thread to deliver it to the recipient's mailbox. If the recipient doesn't exist, it should bounce it back to the recorded Return-Path value.
Note, not all mail servers obey this rule; Some mail servers will bounce it back to the FROM address.
The FROM address is the value found in the FROM header. This is supposed to be who the message is FROM. This is what you see as the "FROM" in most mail clients. If an email does not have a Reply-To header, then all human (mail client) replies should go back to the FROM address.
The Reply-To header is added by the sender (or the sender's software). It is where all human replies should be addressed too. Basically, when the user clicks "reply", the Reply-To value should be the value used as the recipient of the newly composed email. The Reply-To value should not be used by any server. It is meant for client-side (MUA) use only.
However, as you can tell, not all mail servers obey the RFC standards or recommendations.
Hopefully this should help clear things up. However, if I missed anything, let me know, and I'll try to answer.
Another way to think about Return-Path vs Reply-To is to compare it to snail mail.
When you send an envelope in the mail, you specify a return address. If the recipient does not exist or refuses your mail, the postmaster returns the envelope back to the return address. For email, the return address is the Return-Path.
Inside of the envelope might be a letter and inside of the letter it may direct the recipient to "Send correspondence to example address". For email, the example address is the Reply-To.
In essence, a Postage Return Address is comparable to SMTP's Return-Path header and SMTP's Reply-To header is similar to the replying instructions contained in a letter.
for those who got here because the title of the question:
I use Reply-To: address with webforms. when someone fills out the form, the webpage sends an automatic email to the page's owner. the From: is the automatic mail sender's address, so the owner knows it is from the webform. but the Reply-To: address is the one filled in in the form by the user, so the owner can just hit reply to contact them.
I had to add a Return-Path header in emails send by a Redmine instance.
I agree with greatwolf only the sender can determine a correct (non default) Return-Path.
The case is the following:
E-mails are send with the default email address: admin#example.com
But we want that the real user initiating the action receives the bounce emails, because he will be the one knowing how to fix wrong recipients emails (and not the application adminstrators that have other cats to whip :-) ).
We use this and it works perfectly well with exim on the application server and zimbra as the final company mail server.