When sending bulk emails I was receiving several error messages that said:
553 5.1.3 The recipient address <john#example.com > is not a valid RFC-5321 address.
The format of the email addresses looked completely valid so I couldn't figure out at first why these messages weren't being delivered.
Upon further inspection, I noticed that the recipient email addresses for each of the failed messages had a single space on the end. It's not as hard to see in the example I provided above, but the error report I was viewing had smaller font and would sometimes put a line break where the space was, so it wasn't as obvious. By the way, I was using the SendGrid API to send these emails, but I don't think that the issue would be unique to using SendGrid.
if you are using node.js API for sending emails to people, you just need to add .trimRight() to your recipients email address in your API, so in this way the white space will be removed and you can successfully send your email. :)
I was using Django Restful Api and my mistake was, when registering the users, I had interchanged the email field with the username field. So the Smtp server was using the username as the email address used to send the verification emails. I corrected that interchanged the fields correctly and it worked.
Related
I use CDO to send emails for years and since last month there is a strange behaviour when the recipient is yahoo. I get an error:
554 5.7.1 : Data command rejected: SMTP authentication is required for Yahoo mail delivery
However, if I enter TWO recipients separated by comma (even the same address twice), there is no problem and the mail goes ok!!!
Has anybody faced such a problem? It's crazy, isn't it?
Well it seems yahoo has introduced a new security check and do does not accept email from unauthenticated senders of any domain (my case).
So If I enter my email smtp password to send email, there is no problem at all.
Please note that I don't hav a yahoo account, my email is #otenet.gr (which permits unathenticated send mail).
PS
However, the security chek is easily bypassed by just having TWO recipients...
I have user in my system who can send emails through my API. The API uses SendGrid to send the emails with their username as the sender + reply-to address.
user_1#mydomain.com
user_2#mydomain.com
user_3#mydomain.com
What I would like to do is allow people to reply to these emails but I'm unsure how to do this.
Obviously if I try to reply as is - I get an error saying the email couldn't be delivered.
Is there something to do with SendGrid which can handle previously unseen addresses #mydomain.com or do I need to do something to set them up initially in the first place?
The solution was to use incoming web-hooks.
I am building an app that incorporates Postmark App's Incoming Email capability to keep a threaded list of replies to an email. Their documentation suggests adding the post ID to the reply-to address - for example reply+POSTID#domain.com. However, when I attempt to use this method with cPanel, the emails are bounced back.
I have reply#domain.com set up, without adding the post ID the email is forwarded to the Postmark App inbox address, adding the ID breaks it. Is there any way to do this in a WHM/cPanel environment? It is a VPS account so I have full access if there is another way to tackle this.
Are the messages bounced back from Postmark or is it a cpanel error? I can probably help you out there! Do you have an MX record setup for Inbound via http://developer.postmarkapp.com/developer-inbound-mx.html ? Once you have that going Postmark will accept messages from any address on that domain and parse off the addresses with + chars in them. Are we sure cpanel can handle email addresses with special characters?
We have an application that allows users exchange messages, and delivers the message through email. But we don't reveal sender's email, instead; every time a message is sent out a new email address gets generated for the "From" field. Something similar to the way Facebook or LinkedIn send out messages.
Everything works fine, except the recipient's email client caches all these email addresses.
For instance, if Jack sends two messages to Jill, the sender's addresses can be: a123#FakeEmail.com and a456#FakeEmail.com, so next time Jill composes a new message and starts typing Jack's name, the email client suggests two addresses for Jack.
So my question is, how we can prevent email caching on client's machine? Is there something similar to HTTP header Pragma: no-cache for SMTP?
Thanks
Nivresh
OK, here is what I ended up doing. To prevent Outlook and other mail clients from suggesting several dummy email addresses generated for the same contact name, I add a special character to the beginning of the sender's name. This can be a space or if you use Unicode, you can add a zero-width space (\u200B) to the beginning of the name.
So in my example, the email is sent from "\u200BJack" which will be shown as "Jack". The dummy email address will be saved in mail client under the name of "\u200BJack" and when the recipient later on tries to send an email to Jack, email client won't suggest this address.
Hope this helps someone.
I'm creating an email a friend type system where I need our mail server to send emails from the user of the site to their friend, i.e. from fred#gmail.com, to tony#gmail.com.
If, as is the case in this example, the user's are both part of Gmail the friend would receive an email with the warning "This message may not have been sent by: fred#gmail.com.
I thought that by then adding a 'sender' header with our email (e.g. us#company.com) this should indicate to Gmail that we are the sender and are effectively openly spoofing the sender at their request. Is this true, can you get around Gmail's warning using the 'sender' header?
I realise this is similar to the following question but I'm more interested in whether the sender header should have an effect: Email sent from web server causes gmail to treat as phishing. How to get rid of this?
More info:
I'm using netmailbot to send emails from our mail server using the '-customheader' parameter with 'sender' and 'x-sender' e.g. '-customheader sender:us#company.com x-sender:us#company.com'
If gmail doesn't fail miserably, you have no way to suppress this warning.
Google is in control of both accounts and therefore knows, that this mail wasn't send by fred using their infrastructure.
There was used some third party infrastructure (yours) and this is all this warning is about.
You can set an arbitrary email address as "from" and Google has no knowledge if this is legitimate use (if fred really wrote the message). Anyone could have written that message. Normally fred would use Googles infrastructure to send mails and then they would know its him.
A cleaner solution would be to put your email address ("noreply#company.com") as from header (that would be honest) and set fred#gmail.com as reply-to header (so he gets the replies).