I'm having a problem getting emails to bounce to a specific email address, different to the From address.
A particular client requires that we send emails from a specific email address (call it contact#clientcompany.com). Our Exchange admins have created an account on the Exchange box so that we can log in and send from that address. Our Exchange server is spoofing that address / domain. This works fine.
Unfortunately the emails sent from contact#clientcompany.com are not bouncing back to us. They are presumably bouncing back to the contact account at clientcompany.com (which may or may not exist).
I've inserted a header Return-Path=kirk.broadhurst#mycompany.com with the assumption that this field determines where bouncebacks are sent. Other documents indicate that this field should never be populated by the originating SMTP system. Other websites again talk about a field called Errors-To which is apparently non-standard.
So - which field is the correct one, and what does it depend on?
Any ideas why my Return-Path is not working?
I'd really like to get Exchange to correctly bounce a message addressed to an invalid server!
update:
Continuing to dig, and my Return-Path work was only adding an extended property at the end of the header block, but Exchange appears to be still adding its own Return-Path value at the top.
Delivered-To: test#test.com
Received: by 1.1.1.1 with SMTP ...
Return-Path: <contact#clientcomapny.com>
Received: from ... ...
...
Subject: Test
Message-ID: ...
Return-Path: kirk.broadhurst#mycompany.com
According to the Microsoft.com, I cannot set the Return-Path as it is determined by the MAIL FROM - which seems consistent with what I've previously read. But now I'm stuck - how do I change this MAIL FROM value programmatically within Exchange 2007?
You might want to check if the header is correctly set. Check the headers of your email and look for:
Return-Path: kirk.broadhurst#mycompany.com
Return-Path is the correct field according to RFC (IIRC) but not all Mail Servers implement that correctly.
Out of luck ;) The sender is where bounces end up. The client should create the mailbox and forward it to your internal bounce mailbox. Only clear solution.
If a human is replying to the e-mail, and not an automated response, you may want to try using the header "Reply-To:" instead of "Return-Path:". (For example: "Reply-To: kirk.broadhurst#mycompany.com")
Related
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.
I am building a ticketing system where users can raise a support ticket and agents can reply to the particular ticket and when the agent replied to a particular ticket I will send the reply to respective user email (email service using SendGrid).
My question is when the user replied to the agent email I will fetch that email with SendGrid inbound parser but I am stuck that how to uniquely identify for which ticket user has replied. I have two ideas attaching JWT in the header or unique email address resemble ticket id (ticket-id-2654654#example.com) but I don't what will work
You could send a custom Message-ID Header (RFC 2392) with your E-Mail. Responses to your E-Mail should then contain a References and/or In-Reply-To header containing the Message-ID of the E-Mail that was answered.
Edit: Just tested it with Zendesk and Zammad. They both seem to identify responses in that way.
You mention having a unique email address, not unlike a VERP (Variable Envelope Return Path) address. VERP is most pertinent if it's dealing with bounces, since it refers to the address used for the SMTP MAIL FROM:,
MAIL FROM:<ticket-id-2654654#example.com>
in particular it is helpful to identify which emails bounce - the email likely never arrives in a mailbox at the remote end. Note that the address used during the SMTP conversation like this will be recorded at the top of the received email with a 'Return-Path:' header.
Assuming an email doesn't bounce then how to ensure an email with a recognisable identifier comes back:
MysteriousPerson's custom Message-ID: header suggestion is excellent; also specify a VERP address in a Reply-To: header - so one or both of the identifiers you put there should be found in the reply to decode which ticket/user the original message was sent to. You have the choice of using the same VERP address in the From: header or something more human-friendly, depending on what you want the recipient to see. Since Reply-To: is specified, client software will use that for replies.
The main RFCs on SMTP and message format are likely to be helpful if you're not already aware of them.
received an email from a spammer addressed to a non-existent user in my domain, let's call it example.com. obviously the headers had been spoofed but i must assume the 'rcpt to' field was legit for it to reach me. i have all messages forwarded to my gmail from my domain's sendmail.
trouble is nothing in the message source in gmail is showing which of my the legit email addresses the spammer specified to reach me. all i see in the message source is the bogus email. i can't reproduce this either. this is the first 'received from' part:
> Received: from SQSZJWGPY ([1.52.114.198])
> by example.com (8.14.4/8.14.4) with ESMTP id s5PEIUCI003583;
> Wed, 25 Jun 2014 10:18:31 -0400
in all other emails the last line looks something like this:
for me#example.com; Wed, 25 Jun 2014 10:32:11 -0400
so the legit email is revealed. i know the envelope is not included in the message source but there must be a way to find out what the 'rcpt to' value was without going into sendmail logging and what not. how did the spammer hide the email he specified?
The contents of an email message, specifically, the to, cc and from headers, don't necessarily correspond to the envelope mail from and rcpt to of the message. The SMTP protocol, specified in RFC 5321, is where the envelope data is sent.
The message contents, specified in RFC 5322, contain the message headers and message body. The headers are where you find the to, cc and from headers that we usually use to identify out who sent the message and who else received the message.
However, there is nothing requiring that the from, to and cc headers match to the envelope mail from or rcpt to, though well behaved mail software will often have the association made clear. I say "often" because, for example, when you blind carbon copy (BCC) somebody on your message, your mail client will not include these recipients in the to or cc headers.
In your case, the rcpt to specified to sendmail is not put into a header by default, so is probably lost. If you really don't want to look into the sendmail logs you are probably out of luck for this one message.
If you expect you will continue to receive similar messages you could instruct sendmail to add the envelope rcpt to into a header. Then, without looking at the sendmail logs, you will have the rcpt to in a X-Envelope-To header.
The spammer probably has a SMTP server where he has a email account configured as administrator, then he probably can send emails from different senders. The SMTP server probably doesn't have some filters to control the output and input emails, then if you are an administrator of this server, you can send emails from sender like "example#yahoo.com" even if your domain name isn't yahoo.com. Once, some partners and I did a test in a company (customer) to demonstrate that their SMTP server can be victim from a phishing attack, we could send emails from different senders with different domain name.
I hope this information to help you.
Good luck.
after much testing and trial and error i have found the answer to my own question. bear in mind that i use sendmail 8.14.4 (5 years old) and i haven't done much tweaking to the sendmail.mc file.
if during the smtp session the sender specifies a non-existent account in the 'rcpt to' line followed by a valid one, the recipient's address is masked in the headers. e.g.
mail from: spammer#example.com
250 2.1.0 spammer#example.com... Sender ok
rcpt to: bad
550 5.1.1 bad... User unknown
rcpt to: good
250 2.1.5 good... Recipient ok
data
354 Enter mail, end with "." on a line by itself
looks good?
.
250 2.0.0 s5UHeBOj004847 Message accepted for delivery
the message arrives to user 'good' and nowhere in the header (or elsewhere in the message) it is indicated that it was sent to 'good'.
maybe spammers are doing this accidentally or deliberately, but they are doing it and this can be reproduced every time using above method, at least with my sendmail version.
that's all
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.
I'm working on a web application. A user will create an email message that will be sent to another person.
I would like the e-mail that gets sent to appear from the user's name and e-mail address of the user on my system. And if they reply to the e-mail then it should go directly to the sender's email address.
However I am worried about the email message looking like spam to email filters along the way.
Is there a proper way to do this?
I noticed on a "contact" page on a WordPress blog that something very similar is done. The e-mail headers look like:
To: email#domain.com
Subject: [Test Blog] =?UTF-8?B?aGVsbA==?=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From:=?UTF-8?B?aGVsbA==?=<sender#senderdomain.com>
Message-Id: <20090207234737.39C9522802F3#web7.sat.wordpress.com>
Date: Sat, 7 Feb 2009 23:47:37 +0000 (UTC)
Return-Path: donotreply#wordpress.com
What is interesting is that the display name in the "from" tag and the name that shows up in the subject line is encoded. I do not know if this helps with the spam filters or not, but thought it was at least worth mentioning.
Also, who would receive an undeliverable notification in this example? Would it go to sender#senderdomain.com or would it go to donotreply#wordpress.com?
Basically all you need to do is set the From header to the email address of the user sending the email. The value of From is what is displayed in a recipient's email client. Most spam detection systems in place today look only at the message content, not the email headers, so you currently wouldn't have that much of a problem based on what you set the From header to.
However, there are some systems which are gaining popularity which could prevent you from sending email with somebody else's email address - most notably SPF, the Sender Policy Framework Basically, a mail server that implements SPF will check the domain of the From address of each email it receives and check with that domain directly to see if it authorizes the email. For example, if your server is mydomain.com, the email address of the user is abcdef#gmail.com, and the recipient is blah#example.com,
mydomain.com contacts example.com via SMTP to try to send the email
example.com looks up the SPF records for gmail.com
example.com checks whether mydomain.com is on the list of domains allowed to send email with the domain gmail.com
If it's not, the email is blocked
Also, I found a forum post suggesting that Return-Path is the intended destination for undeliverable notifications. Apparently that header is set based on the value of the SMTP MAIL FROM command.
Setting email fields is generally trivial, but the exact method of doing so depends on the language and framework you are using, which you don't mention. Usually it is a matter of creating a new email object, and just doing something along the lines of:
email.from = "From Name <fromemailaddress#example.com>";
You can set the specific from address to your user's, if you like, it is not at all uncommon though I personally am not a fan. You could also set the from field to something like: "Sender Name (via Your Site Name) <yourresponseaddress#example.com>".
Don't do this.
It really depends on how your mail relay is set up, but actually just don't do it. From header should contain the email address that sent the email, in your case webmaster#whatever.com. If you want people to reply to a different address, you can always use the Reply-To header. Here are some notes.
If I understand the standard (RFC 822) correctly, this is exactly what the Sender header is for (see §4.4.2. SENDER / RESENT-SENDER). Still, I'd go with a different approach and use your sites official contact address in the From header and put the user's address in the Reply-To header. Maybe add some boilerplate text that clearly states where the mail is coming from.
One further advice besides the technical stuff: don't let anonymous users use this facility, you'd become a perfect platform for spamming. Also, out of kindness, you probably want to make sure that your (registered) users know that their email addresses are exposed to the recipients.
Be aware that doing this will make spam filters more suspicious of your email. Combined with suspicious looking content your email may get filtered.
Whoever is in the "From" header will receive the undeliverable notification.
For the filtering - it really depends more on the subject and body of your message than the From address. So with that said, a couple ideas....
Use HTML encoding rather than Plain Text with simple formatting (I know there's probably an argument going the other way but in my personal experience HTML gets through more often)
Always include a footer with ("This e-mail was sent to you from ... blah blah") to identify it; if you don't want people to know it's coming from your system (i.e. really impersonated from the "From" user) then you need to find a more legit way to take care of the requirement.
If at all possible, use a real address from your system as the "From" address with the address of the user as the "Reply-To".