I am using GMail API to create drafts and redirect user to be able to review and send.
However the Reply-To header seems to be ignored by GMail API
My header is:
X-Sender: email#from.domain
X-Receiver: email#to.domain
MIME-Version: 1.0
From: email#from.domain
To: email#to.domain
Reply-To: someotheremail#domain.tld
Subject: subject
Content-Type: text/html;charset=utf
Email Body
But when the recipient of the email hits reply button, the From address is used to reply instead of Reply-To.Tried to send the email from browser as well as fully automated via API too.
Any ideas ?
Ah got it. I must supply Return-Path: as well.
Related
I used request below and it worked before, but today when I want to get an access token, it crashed.
Request:
Post https://login.microsoftonline.com/common/oauth2/v2.0/token
Content-Type:application/x-www-form-urlencoded
client_id=azure_Ad_client_id
&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_secret=sampleCredentia1s
&grant_type=client_credentials
Error message: AADSTS9002326: Cross-origin token redemption is permitted only for the 'Single-Page Application' client-type.
The same for auth code flow:
=================================================
I do have a origin here, but I didn't set it. How can I remove it?
I don't have redirect URL in SPA platform.
===========================================
With Postman it's OK
I tried to reproduce the same in my environment and got the same error as below:
The error "AADSTS9002326: Cross-origin token redemption is permitted only for the 'Single-Page Application' client-type" usually occurs if the application has been registered as SPA or if the origin has been added as the header while requesting the access token.
Check whether the Azure AD Application is registered as SPA in the Portal like below:
Check whether you have added origin header while generating the access token, if yes then uncheck it:
I registered an Azure AD Application like below:
I generated the access token by using below parameters:
GET https://login.microsoftonline.com/common/oauth2/v2.0/token
client_id:ClientID
client_secret:ClientSecret
scope:https://graph.microsoft.com/.default
grant_type:client_credentials
Even using authorization code grant flow, I am able to generate the access token successfully as below:
GET
https://login.microsoftonline.com/common/oauth2/v2.0/token
grant_type:authorization_code
client_id:ClientID
scope:https://graph.microsoft.com/.default
code:code
redirect_uri:https://jwt.ms
client_secret:ClientSecret
This happened to me as well, it worked last week.
I think the issue might be that the extension somehow cannot avoid sending the Origin-header. Click the arrow on "COMPLETE REQUEST HEADERS" to expand it, and verify that Origin-header is indeed sent.
There is also text at the bottom:
"Note: XHR automatically adds headers like Accept, Accept-Language, Cookie, User-Agent, etc."
I think something has happened with either Chrome, or the Talend-extension itself that means it adds fields according to XHR. I assume this wasn't the case earlier...
AFAICS the extension has all the permissions needed to skip those, but still sends them.
Messages sent through the Gmail API to a Gmail address are getting tagged in Gmail with
Be careful with this message. It contains content that's typically used to steal personal information.
The message basically just says test. And the identical content message sent through Gmail SMTP doesn't get tagged with that warning.
It seems really strange that Gmail would mark messages that are coming through a Gmail owned API as suspicious but when they come through SMTP it does not warn about it.
I was getting this as well. Simply removing the 'from' portion of the email solved it for me. If you are authenticated gmail figures that stuff out on its own.
In our application we are implementing the Send As feature from Gmail client.
https://support.google.com/mail/answer/22370
We are setting the From, To and Reply To headers accordingly to the settings that are set for the external account. Are there other headers that should be set when sending message in behave of external account? For example when we have set another SMTP server for the current external account.
Well, according to User Messages API Document, these are all the headers you need to add:
Users.messages: send
Sends the specified message to the recipients in the To, Cc, and Bcc
headers. Try it now or see an example.
This method supports an /upload URI and accepts uploaded media with
the following characteristics:
Maximum file size: 35MB Accepted Media MIME types: message/rfc822
Be sure to be authorized first, and apply best practices on sending to external accounts.
Is there any reason, why I don't get email along with chat message retrieved by gmail.users.messages.get? When I try to execute the request via API explorer I can see the email in "From" field of the MessagePartHeader, however when I try it programmatically, the email is missing (using the same paramters as in API explorer).
How do I prevent the '....com via 2uix4h7xygsz66weerlq.apphosting.bounces.google.com' from showing up in the header when sending email from AppEngine? I'm sending to myself yet it still shows.
I found this page which says
https://support.google.com/mail/answer/1311182?hl=en-GB&ctx=mail&authuser=1#
I'm a sender and I don't want my recipients to see the "via" link. What can I do?
Gmail checks whether emails are correctly authenticated. If your messages are sent by a bulk mailing vendor or by third-party affiliates, please publish an SPF record that includes the IPs of the vendor or affiliates which send your messages and sign your messages with a DKIM signature that is associated with your domain.
Yet looking at the headers, it shows that SPF and DKIM are already set and passed!
Return-Path: <3OIblUgoJBXcWVif-mZXjibhVdg.XjhXcgjZjidsYZqx.Xjh#2uix4h7xygsz66weerlq.apphosting.bounces.google.com>
Received-SPF: pass (google.com: domain of 3OIblUgoJBXcWVif-mZXjibhVdg.XjhXcgjZjidsYZqx.Xjh#2uix4h7xygsz66weerlq.apphosting.bounces.google.com designates 209.85.212.72 as permitted sender) client-ip=209.85.212.72;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of 3OIblUgoJBXcWVif-mZXjibhVdg.XjhXcgjZjidsYZqx.Xjh#2uix4h7xygsz66weerlq.apphosting.bounces.google.com designates 209.85.212.72 as permitted sender) smtp.mail=3OIblUgoJBXcWVif-mZXjibhVdg.XjhXcgjZjidsYZqx.Xjh#2uix4h7xygsz66weerlq.apphosting.bounces.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=mime-version:reply-to:message-id:date:subject:from:to:content-type;
bh=chRsCD+FjUjL41bfEeXlAef5gWxlIYtGdgQGKtsk5nQ=;
b=g+3WZtFRy1F6d5cRX94eRcKaNk4yg8M1OS/qUDV9ju8El7XIxE5KGsR+6Jo5rOB5ZX
g3U3Gb9KRTOm3FQ7d7X3mVbZUauuZOYzmpijJ65R0Qnc5U0sljIB5IYmKropnxJHIeyi
DOuaL6FFMfrDclpWf1E9o8eXclkAxTdllRTQxjWrc91vucH89dMfs8jCF/KmWUFMECuX
Z69zmxKEnNn0FXZXP5i0FodxfZlb6qn7OSKeE4MVpehBIA7l0bsVv8pLOWQmBWSrQHqr
fD9dlC0r3+hYmYR8lxrR+7mtikt+hOnD3SIV7Vh0+MtZH3rOqKT5uJo262SGbD66Ckgf
yZ3A==
The code is rather mild
Message message = prepareMessage();
Transport.send(message);
Domains that want to reliably send emails should have DKIM and SPF set in their DNS configuration. This is needed to that you email does not get marked as spam.
If you send from #gmail.com, than Google sets this. But if you send mail from you custom domain, then you need to set this on your own.
In your case it seems that you send from custom domain, so google adds a "via" header along with it's own DKIM/SPF records so that this mail has better spam protection.