I am trying to search gmail api with custom header (this case it is named notification-id), but it does not work. Request I am making:
GET https://www.googleapis.com/gmail/v1/users/tme/messages?includeSpamTrash=true&q=notification-id%3A560d01cef318893c3c000016
I tried the same query using default header (rfc822msgid) from google mail api and it works with this request:
GET https://www.googleapis.com/gmail/v1/users/me/messages?includeSpamTrash=true&q=rfc822msgid%3A560d01d068c_6690c6f31857290%40ip-172-31-12-127.mail
Any ideas why it does not work with custom header?
I tried to do this myself a while back, and came to the conclusion that it was not possible. Someone please correct me if I'm wrong.
According to the Advanced search-documentation, you can search for the following headers:
from, to, subject
list:
Messages with the words info#example.com in the headers, sent to or
from this list
deliveredto:
Any message with username#gmail.com in the Delivered-To: field of the
message header (which can help you find messages forwarded from
another account or ones sent to an alias).
rfc822msgid:
Locates the exact message with the specified SMTP message-id.
Related
I want to block other user in ejabberd on basis of jid. I am trying to send iq stanza through send_stanza_c2s command. Like :-
send_stanza_c2s admin localhost Smack "<iq from='admin#localhost/Smack' type='set' id='msg1'><query xmlns="jabber:iq:privacy"><list name="blocked"><item type="jid" value="jack10#localhost" action="deny" order="3"/><message/></item></list></query></iq>"
But it is giving me error.
Error: {4,<<"not well-formed (invalid token)">>}
Please help me with this.
Also guide me on if blocking user is achievable only through privacy lists (XEP-0016).
The IQ request stanza you send to the server is not well formed, I.e. invalid. If you used Smack's API for privacy lists then you should report this as bug.
Struggling to find any useful information on this, so I'm hoping some light may be shed here.
I received an email to which I don't appear to have been addressed.
It's a legitimate email to our organisation, however there appears to be no reason for it to be delivered to me. Digging through the headers DOES reveal my email address, in a header field x-newtrunsreceiver.
ie.
x-sender: sender#sendersemail
x-newtrunsreceiver: legitimaterecipient1#ourorg
x-newtrunsreceiver: myemail#ourorg
x-newtrunsreceiver: legitimaterecipient2#ourorg
The recipients legitimaterecipient1 and legitimaterecipient2 are in the To: and Cc: fields respectively.
I am kind of assuming I've been BCc'd, but can't find any info on what the x-newtrunsreceiver header field is / does.
Any help welcomed.
MIME headers have absolutely nothing to do with who actually receives the message.
When a message is submitted to an SMTP server, the recipients are specified in the "RCPT TO" SMTP command. The MIME headers that follow the DATA command can contain anything. The SMTP server can in theory take a look at the To and CC headers, but there is absolutely no requirement or reason to do that.
Now the receiving SMTP server can add an extra header (e.g. Apparently-To), but, again, it has no obligation to do that.
I want to know more about the resent headers (resent-from, resent-to, resent-date etc) that get prepended to an email's header.
When do these headers get added? Do they get added by the server or the mail client program?
I need to write a Java program using JavaMail api to forward an email (without changing or parsing through it's original content). I would like the email to be redirected to the destination email address on arriving at the server for a specific recepient.
Any snippet where you have been able to forward / redirect a mime mail using the resent headers will be helpful.
Thank you
See section 3.6.6 of RFC 2822.
You should be able to use JavaMail to add these headers to a message. If the message was read from a folder on a mail server, you'll need to make a copy of the message first before you can change it. Use the MimeMessage copy constructor. You can then send it to whatever address you want, ignoring the addresses in the message, by using the Transport.send method that takes an array of addresses. If you need to preserve the original Message-ID (which may not be appropriate since you're modifying the message), you'll need to subclass MimeMessage and override the updateHeaders method.
im thinking what is the best RESTful way how confirm email and request reseting password. Im only aiming to find correct URI...
confirm email
PUT /users/{userId}/confirmEmail?code=xyz - does not seem much RESTful because of confirmEmail
PUT /users/{userId}/email?confirmedBy=xyz - maybe better? dunno
reset password (similar problem)
PUT /users/{userId}/resetPassword --DATA {email:xyz#xyz.xy} - same thinkin as before
PUT /users/{userId}/password --DATA {state:reseted,resent:xyz#xyz.xy} - hmmm... again Im not sure
are there any better ways in your mind?:-)
If you want your URIs to refer to resources, then call the resource confirmation and POST confirmations to user accounts.
POST /users/{userid}/confirmation
The true RESTful answer is the URL does not matter, you put it in the confirmation e-mail anyway for the recipient to follow. Use whatever is most convenient for your load balancer, reverse proxy, servers, etc.
For convenience you'll end up accepting the confirmation even if it comes in a GET request, because that's what the browsers of flesh-and-bones humans oblivious to Dr Roy T. Fielding et al. send when clicking on a link in an e-mail :-)
Having established it is completely academic, I'd argue you were right to think of PUT, as the client idempotently places evidence of having access to the e-mail. Repeating the request has no further effect.
Considering that he said a reset service for someone who forgot her password, and not a change password service for someone already logged in...
I would use 2 services. 1st to request the reset password mail, and 2nd to set the new password with the token received in the received mail.
For the 1st:
POST baseUrl/passwordReset
Request body
{
"email" : "my#self.com"
}
This could be POST or PUT, but since a mail delivery is not a resource subject to CRUD anyway, let's not be pedantic and use the old POST that was always used in html forms.
Obviously I would control that the same client (ip? browser? ...) doesn't make me send 20K mails in a minute.
Sending the mail to the user doesn't imply that the old password is not valid. That will only happen later in the second request when the new one updates it.
Response 204 (perhaps you should do it even if you don't know that email, because if you return error that means that when you don't return error you are confirming to a stranger that the given email is registered)
For the 2nd:
POST baseUrl/password
Request body
{
"token" : "3D21BA...4F",
"newPassword" : "m%4pW1!O"
}
Where the token is received in the mail. So the mail could have a link to a page including the token, when the page is loaded, the form is filled and submitted, being the token a hidden field that some javascript reads from the URL and puts here.
This is really a resource that you update, so POST. And I don't think it makes sense to have the same URI with 2 verbs for both, because they are not the same resource/entity at all.
Add
By the way, I would make both HTTPS only, and that's why I put all the sensitive information in the body, not URL parameters.
Firstly, I don't think that PUT is the right method for this. PUT broadly means "put this here", where the URL is identifying where the content should be located. You're really asking an existing resource to perform some action, which makes POST more correct.
To answer your direct question, a RESTful URL should identify the resource you want to handle your request. In this case, the resource is either the user, or some password-resetting resource within the user.
My preference would be for a password-resetting resource:
POST /users/{userid}/password-reset
This makes sense from a HTTP point of view, since you could issue a GET on the resource and receive something which indicates how to action a password reset (e.g. a HTML form prompting for the email address of the associated account).
EDIT:
For the purposes of email validation, there are two obvious options. You could either POST to a "confirm email" resource with the email address and confirmation data, to ask the server to process the confirmation, or you can execute a PUT to put the confirmation information on the server:
POST /users/{userid}/confirm-email
or
PUT /users/{userid}/email-confirmation
Here is a RESTful way.
Request
PUT /{userid}/email HTTP/1.1
Content-Type: text/json+confirmation-code
{"activateCode": "23sfgsg3twt3rgsdhgs"}
Response
HTTP/1.1 200 OK
Content-Type: text/json+email-status
{"email": "my-email#address.com", "active": "true"}
No verbs in the URI needed :)
I don't really see anything wrong with having confirmEmail like the 1st example. In the URL you have the key to the user, confirmEmail is the action, and the data with that action is in the query string.
I've recently worked on this, my take was
POST /{base_url}/password
because I was actually creating a new random password and sending it over to the user
and
PUT /{base_url}/confirmation?token=...
Because I am updating the confirmation that was already sent out when the user registered.
What's the difference between an email Sender, From and Return-Path value?
Example: I have a contact form where the user can input their email, would this be assigned to sender, from or return-path?
I had a quick search on the StackOverflow and couldn't find anything useful.
So, over SMTP when a message is submitted, the SMTP envelope (sender, recipients, etc.) is different from the actual data of the message.
The Sender header is used to identify in the message who submitted it. This is usually the same as the From header, which is who the message is from. However, it can differ in some cases where a mail agent is sending messages on behalf of someone else.
The Return-Path header is used to indicate to the recipient (or receiving MTA) where non-delivery receipts are to be sent.
For example, take a server that allows users to send mail from a web page. So, sender#yourcompany.com types in a message and submits it. The server then sends the message to its recipient with From set to sender#yourcompany.com. The actual SMTP submission uses different credentials, something like mailagent#mywebmail.com. So, the sender header is set to mailagent#mywebmail.com, to indicate the From header doesn't indicate who actually submitted the message.
In this case, if the message cannot be sent, it's probably better for the agent to receive the non-delivery report, and so Return-Path would also be set to mailagent#mywebmail.com so that any delivery reports go to it instead of the sender.
If you are doing just that, a form submission to send e-mail, then this is probably a direct parallel with how you'd set the headers.
The official RFC which defines this specification could be found here:
https://www.rfc-editor.org/rfc/rfc4021#section-2.1.2 (look at paragraph 2.1.2. and the following)
2.1.2. Header Field: From
Description:
Mailbox of message author
[...]
Related information:
Specifies the author(s) of the message; that is, the mailbox(es)
of the person(s) or system(s) responsible for the writing of the
message. Defined as standard by RFC 822.
2.1.3. Header Field: Sender
Description:
Mailbox of message sender
[...]
Related information:
Specifies the mailbox of the agent responsible for the actual
transmission of the message. Defined as standard by RFC 822.
2.1.22. Header Field: Return-Path
Description:
Message return path
[...]
Related information:
Return path for message response diagnostics. See also RFC 2821
[17]. Defined as standard by RFC 822.
A minor update to this: a sender should never set the Return-Path: header. There's no such thing as a Return-Path: header for a message in transit. That header is set by the MTA that makes final delivery, and is generally set to the value of the 5321.From unless the local system needs some kind of quirky routing.
It's a common misunderstanding because users rarely see an email without a Return-Path: header in their mailboxes. This is because they always see delivered messages, but an MTA should never see a Return-Path: header on a message in transit. See https://www.rfc-editor.org/rfc/rfc5321#section-4.4