I am using our email server at [mydomainhere].com to send emails through a web site UI. I just used the UI to send an email from [myemail]#yahoo.com. And received an Undeliverable message at my yahoo email address.
mta1400.mail.ne1.yahoo.com rejected your message to the following e-mail addresses:
[myemail]#yahoo.com
mta1400.mail.ne1.yahoo.com gave this error:
Message not accepted for policy reasons. See http://postmaster.yahoo.com/errors/postmaster-28.html
More information can be found here:
http://www.pcworld.com/article/2141120/yahoo-email-antispoofing-policy-breaks-mailing-lists.html
Any help would be appreciated.
Yes Allan, you are correct in assuming that the anti-spoofing that Yahoo (and now AOL) have turned on is permanent. The technology they are using is called DMARC. Yahoo has published a DMARC record in their DNS:
$ dig TXT _dmarc.yahoo.com. +short
"v=DMARC1; p=reject; sp=none; pct=100; rua=mailto:dmarc-yahoo-rua#yahoo-inc.com, mailto:dmarc_y_rua#yahoo.com;"
Every mail server that supports DMARC will look up that record in Yahoo's DNS and apply Yahoo's p=reject policy. In effect, what Yahoo has done is stated to the world, "if the email does not originate from this list of IPs (SPF) or bear this crytographic signature (DKIM), then reject (p=reject) it." Since your mail server is not in their list of mail servers IPs nor are the messages signed with Yahoo's DKIM key, a substantial and growing portion of the mail servers on the internet are going to reject it or deliver it to the Spam folder (Gmail).
In addition to the SPF & DKIM checks, DMARC also introduces the concept of alignment. In addition to passing SPF checks (which apply to the Envelope Sender), DMARC requires that the domain in the messages 'From' header passes SPF. This prevents you (and bad actors) from sending messages with a header From domain of Yahoo.com and an Envelope Sender domain of attacker.com, which the recipient will never see. This alignment also extends to the DKIM signature, requiring not just that the message is signed with DKIM, but also that the dkim signature domain (d= property) matches the From header domain.
we will just have to prevent users from using their yahoo email address in the sender email field
Coding in a check for the yahoo.com domain is a hack that won't last long. AOL has already joined the thousands of domain owners with DMARC p=reject policies. They won't be the last of the Very Large Email providers to publish p=reject DMARC policies. A much safer approach is to evaluate SPF against your mail servers public IP and the domain in the users selected email address. If the SPF check fails, then choose an option:
Inform the user that their choice of domains doesn't permit 3rd party senders and they should choose another.
Alter the From header to send from a domain you control:
From: "user#yahoo.com via" <my-app#my-domain.com>
As already stated, you could define Reply-To if you wish for replies to expose the senders real email address.
Set up local usernames that forward to the sender's real email address. If you've used Craigslist, you're familiar with the idea. You maintain a mapping of local addresses and the email address they forward to.
Based on what you've said about your web application, it seems like #2 is the best fit.
I have had a similar problem with mailing lists that I maintain (e-mails with a From address something#yahoo.com bounced). I solved my problem by changing the From, Reply-to and Errors-to fields of the e-mails' headers as follows:
From: Organization name <no-reply#somedomain.org>
Reply-to: my-email-address#yahoo.com
Errors-to: my-email-address#yahoo.com
I suspect that similar changes will fix your problem.
Related
I'm trying to analyze a mail header to figure which element (MUA, MTA...) creates each. My supposition is:
The sender MUA composes the body (including Content-Type, Mime, Content-Transfer-Encoding), and sends it via SMTP to the sender border MTA. MUA provides info for the the initial headers (From, To, Reply-To, ) which are inserted by this MTA
This MTA inserts MessageID and Return_Path (and all extra headers and X-Headers it desires)
Then it starts 'hoping'. On each hop the receiving MTA inserts 'Received:' header and each other header it considers
If order is kept and each MTA inserts its headers AT THE TOP of the message, it should be easy to figure which MTA has inserted each header... but I can't find a valid scheme
Fields as DKIM-Signature, Authentication-Results, Received-SPF... appear in different places. Which MTA creates each? Who DKIM-signs the email (I suppose it must be the sender border MTA) Who authenticates SPF-DKIM-DMARC?
A lot of X-Headers are added, many related to spam control, and I cant find which MTA (on with hop) created each
Could you help me, please?
The MUA (Mail User Agent, RFC term for mail client) will add most headers that you can see in email clients, in particular From: and To:. (You can sometimes see this in the To: header when someone has "funny" nicknames for someone in their address book. Or when "From:" and SMTP envelope from (as in the MAIL FROM: command) disagree, even though may servers will reject such messages, as it's often a spam indicator.) The MUA will set the Reply-To: header as well, especially if the MUA is really a customer management system. The MTA (Mail Transfer Agent, actual SMTP server) may include bounce information (VERP).
The MUA then submits the message to the MTA. Every program (mail server, firewall, etc) that touches the email can add headers. For example, the MTA would normally do the DKIM signing (and add the relevant headers). It must prepend Received: header (i.e., put it at the top) and it must not mess with other Received: headers. Still some programs like firewalls may mess with headers.
You can see multiple DKIM signatures (see DKIM selectors), for example, when an email gets resent in the context of a mailing list. You could see a DKIM signature from the original sender to the list, then more headers including an additional DKIM header when the mailing list server sends its to the final recipients.
As for X-... headers: these are non-standard headers (hence the X- prefix). Everything is off here. Some sending MTAs insert them for tracking purposes (e.g., to catch spammers among their customer), some mail receivers put their spam assessments in a special x-header. Even the MUA may put some x-headers in the emails, for example, Claws Mail puts in a header for the account the mail came from, when it downloaded it, and so on. You may or may not trust these, and in fact, MUAs may have settings to indicate which x-headers they should trust.
To that regards, even the Authentication results header and such can come form anywhere along the road. Even the initial sender could add one, like some anti virus programs do, to indicate that they scanned the outgoing mail. Again, it's up to the receiver to decide whether to trust these headers. Clearly you want the mail server closest to you to do DKIM checks and anything related to authentication, as you can hopefully trust that server's verdict.
So, does order indicate which mailer inserted a header? Yes, but... mail servers may or may not conform to all parts of the RFCs, and many mail servers follow Postel's law and be somewhat lenient in what they accept.
I'll like to process incoming email on a specific email. In aws docs it says
Although you are not required to publish an MX record to receive mail through Amazon SES, if you don't publish the record, Amazon SES will receive mail for your domain only if you explicitly route it to Amazon SES.
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiving-email-mx-record.html
How do I explicitly route email to SES?
After hours of research and failed attempts of having SES receive emails without the use of a MX record (had set up an additional Route via gSuite / Google Apps), here is my best suggestion on how to go about this.
Short Version
Create a subdomain and point its MX record to SES after inserting the TXT verification record. After creating the necessary ruleset to receive and save email from any#sub.domain.com, you can now have SES receive email from any email address you own (even if it's not verified with SES) by simply forwarding its emails to the SES enabled subdomain email address.
Long Version
Unfortunately, it does still require an MX record, but check it out...
You can create a custom subdomain on your primary domain and call it anything. In my case, I called it ses.mydomain.com
Next, I added my newly created subdomain to SES via the Domains link.
Immediately upon adding it as a domain to SES, a pop-up window appears displaying the required TXT verification record and MX mail record.
Shortly after assigning these two DNS records to my subdomain, the subdomain is verified and able to receive email after setting a few quick rules via Rule Sets!
Here's the cool part - you can still have SES receive email from any email address you have access to.
How you might ask?
By just setting up a forwarder on the email address you do want to send to SES, by forwarding it to the SES-enabled subdomain email address.
Meaning - If SES is able to receive email from someone#ses.example.com, but you want it to actually receive email from someone-else#example.com, then all you need to do is forward someone-else#example.com to someone#ses.example.com!
Remember, you still need to create the necessary rules to receive emails. See this AWS Blog Post for more information.
Use one of the AWS SES's inbound endpoints:
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/regions.html#region-select
e.g. for US-EAST-1 the inbound endpoint is inbound-smtp.us-east-1.amazonaws.com. For receiving only you do not use SMTP endpoints. The procedure is pretty much the same using MX records or not: somewhere (in your DNS or in your mail handling system) you must point to a SES inbound endpoint.
For example, my MX records point to Google Apps, but using 'Hosts' and 'Routing' (inside Google Apps/Gmail options) I managed to relay only one recipient to SES. So every e-mail my domain receives goes to Gmail recipients as usual, except for one special_recipient#mydomain.com which I relayed to SES (which, in turn, goes to SNS then to SQS).
from:
https://aws.amazon.com/blogs/aws/new-receive-and-process-incoming-email-with-amazon-ses/
Now you need to route your incoming email to SES for processing. You have two options here. You can set the domain’s MX (Mail Exchange) record to point to the SES SMTP endpoint in the region where you want to process incoming email. Or, you can configure your existing mail handling system to forward mail to the endpoint.
Is it possible to use SMTP as described in RFC 5321 to receive mail or is it prohibited by this spec?
SMTP is used only for sending mail - transferring mail to mail servers, and between mail servers. POP and IMAP are two popular protocols (but not the only protocols) for mail user agents (end-user email clients) to retrieve mail, which I'm guessing is what you're asking about.
To put it a different way, an SMTP conversation is initiated by software that wishes to transmit email to another device. It's not usually used as the last-hop step to deliver email to a user - those conversations are usually initiated by software that wishes to receive the email.
ESMTP extensions for email receiving
SMTP is used to receive email servers listed in MX recerds from "all internet".
If you want to use it to receive your email from relay accepting emails from "all internet":
with static IP address but without permanent internet connection you may use ETRN command [RFC-1985]
https://en.wikipedia.org/wiki/ETRN#ETRN
with dynamic IP address you may use ATRN [RFC-2625]
https://en.wikipedia.org/wiki/On-Demand_Mail_Relay
Both extensions are designed for "for domain emails" not for "single mailbox emails".
We use Google Apps' account to send site-generated mail from support#oursite.com. It was fine until some point (between April and June) the settings got changed and now when they click "Reply" they see support#oursite.com instead of user's email.
in April's letters both Reply-To and To headers are filled out with user's email;
in June's ones, Reply-To contains user's email but To header contains support#oursite.com.
In all cases FROM headers contain support#oursite.com; we try to put user's email into it but (supposedly) Google SMTP replaces it to support#oursite.com somehow.
The question is:
has anyone else encountered such a problem? (yes, I've searched, not the same cases found)
what solution did you find?
UPD: the behavior described above is for Gmail (both free and GApps) web client only. In any other client (e.g., Gmail for Android/Apple, etc.) hitting "Reply" results in the correct email in the "To" field.
I believe GMail has been doing this for a while - I'm surprised that this started happening to you just recently.
However, there may be a solution. See http://lifehacker.com/111166/how-to-use-gmail-as-your-smtp-server and read 'Update 3' at the bottom of the page.
Google Enterprise support says the following on this subject :
If the From address is your own account (either your primary or an
alias custom from) the 'Reply-to' address is changed to the To
address. This is implemented for replying to sent messages. If you
reply to a message you just sent, you are, in effect, sending another
message to all the To addresses. If you change the From address to a
non-sending address (not the primary and not an alias custom from) and
the reply-to should begin to work as expected without any further
problems.
Our Current email2fax gateway does not handle bounced emails very well. When a email is sent to the gateway the content is faxed out and a notification is sent to the original sender of the message.
Problems happen when the original user turns on a out of office agent and messages will bounces between the 2 email gateways.
I have tried to set in the outbound notification the following headers
From
Reply-To
But as this is a proprietary gateway it does not allow me to set a custom Return-PATH
some silly mail servers send replies back to that.
Are there any extra email headers that maybe I could set to say "Do not send a Notification back"
If not is there a email gateway that would be able to act like a proxy and sit in front of the gateway that would then allow me to programmable check the messages as they came in and drop out of office messages.
I would have thought an anti-spam program like SpamAssassin could be fine-tuned to catch out-of-office replies.
If your mail gateway can't even have an anti-spam system plugged into it then it really is a bad system to have around!
Try setting the Precedence: bulk-header (or junk) in your notifications. Usually OOO-notifiers like Unix vacation do not send notifications for incoming mails with that header.
As this header is slightly discouraged, you could try setting an empty Return-Path, as suggested in Precedence: header in email.