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.
Related
I have a very specific problem with the Gmail Schema Whitelist Request process. Based on the guideline I should send a real-life email coming from my production servers including the markup / schema to schema.whitelisting+sample#gmail.com. Unfortunately my product does not allow the specific email adress from google, I guess because of the plus character ("+"), for registering. I want to trigger a confirmation email (One-Click Action: confirmaction). Any suggestions how to go on?
As per advised before by the support, I tried to send my sample to schema.whitelisting#gmail.com. You can try sending your sample there too.
I'd like to know if the following is actually possible:
A mailto link that does not contain an email address, but somehow auto populates the TO: field with the email of the original sender.
For example:
"a href="mailto:ORIGINALSENDER?subject=UNSUBSCRIBE&body=I would like to unsubscribe from future emails">Click here to send an unsubscribe email /a"
Is this possible without having to specify an email address in the link itself? Is there a class or function i can call to autopopulate the To: field?
The reason i ask is we send out curated email templates to individual customers and they are sent via a specific system. This system does not have an unsubscribe function, unfortunately. I am not able to use or suggest a system that does as i am but a lowly cog in the corporate machine.
In a word, no, not dynamically in an email that I'm aware of. Are you sending from the same email address each time? Can you set up an additional email address to handle unsubscribes and just have that hardcoded? (i.e. unsubscribe#yourdomain.com and have that monitored)
If you're using different email addresses, then consider replacing 'click here to unsubscribe' with something to the effect of 'to unsubscribe, reply to this email with unsubscribe in the subject line'
Lastly, making a recommendation and giving a good argument for using a system that better suits your requirements is a first step towards being more than a lowly cog in the corporate machine :)
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.
I'm working on a feature for a client to send them email updates whenever a specific event occurs on their site. When the message shows up in Gmail, the messages get grouped together in conversation view even through they aren't the same conversation. It appears that this is due to the fact that Gmail groups based only on the subject. The client is adamant that we not change the subject line (don't get me started).
Does anyone know how I can disable this by sending a special header in the mail or am I out of luck?
There appears to be no way to prevent this, short of turning off conversation view (have you considered that?).
My guess is that Gmail is actually threading based on its own Thread-Topic header field, which it adds (overwriting any value you pass; it just copies the Subject field) - there's no way of telling, though, unless you can change that field after the fact. Which leads to the suggestion of writing an IMAP application to download the message, edit the headers, and re-upload it again. You'd need to investigate the feasibility of this, though.
I have tried sending and HTML formatted email using ACYmailing for Joomla AND Mailchimp. It works for yahoo, msn, aim, my work domain but not for gmail.
I can send plain emails from my server to gmail but the HTML formatted newsletter doesn't work.
Someone suggested it may be my HTML code ~~~> Pastebin
I couldn't find a problem with it.
Some ideas:
Maybe GMail recognizes it as spam. Try some different content
Did you set the headers of the email correctly?
Did you specify a correct sender / sender name?
Are you receiving a rejection or failed email response? If it is being rejected you should get an email explaining why which will be sent (although you will need to specify a correct from / reply-to email address to receive this).
The first thing I would check is if the IP you are sending from has been blacklisted by any spam services - most deliverability issues I have experienced have been due to this. You can check a fairly extensive list of spam blacklists (together with some additional email validation services) at MX Toolbox
If everything appears fine there it may be due to Gmail's fairly strict antispam criteria. To be accepted, an email should contain in the headers a valid email address for Return-Path. If this is not valid then there must be a Reply-To header with a valid email address.
Another important weapon in Googles antispam arsenal is SPF record checking - essentially a way of validating that an IP address is authorised to send email for a particular domain. This is worth checking however as far as I am aware a missing SPF record will only cause the mail to go into spam rather than not be delivered.
Gmail has three tabs now, especially if you're part of their partner network. I encountered the same issue until I noticed the three tabs. They are "Primary", "Social", and "Promotions". All of my MailChimp email wound up under the Promotions tab. Check there for your emails from MailChimp and possibly other e-blast emails. I don't have the solution yet on how to get MailChimp emails to go directly to the Primary area of the inbox.
Just in case you're actually sending the HTML you reference in your question, note that it's invalid - you haven't wrapped it in the necessary <html> and <body> tags.
I realize it's likely you just forgot to include those tags in the pastebin reference, but just in case. Note that the w3c validator found several (minor) errors in the referenced fragment.