We're building a web app which contains a form of what documents to request from a client. So
A user ticks for example driver license, passport and application letter on that form and click "Send document request".
The application sends an email to the client which says "Please send us your 1) driver license 2) passport 3) application letter". It sends the email using it's own robot account like "noreply#ourcompany.com"
The client gets the email asking him to reply back with requested documents. He replies on that email with text like "Ok, great, thanks! I have attached my driver license, passport and letter to this letter" and attaches the files.
The user from the first step should get the letter client sends on the third step.
How can I achieve the behavior on the fourth step? I guess there is something like 'Reply-To' header I should set to the real user's email.
I've created an example for you to confirm the logic. Please add feedback to comments and I'll edit accordingly. The idea here is that with your feedback, we can create a Narrative of emails to form a complete and successful conversation.
Does the following logic matches your intent?
An email is ACCEPTED via HTML form FROM "User1" <user1#example.com>
This email is ORIGINALLY SENT FROM "No-Reply" <noreply#ourcompany.com>
This email is SENT TO "User2" <user2#example.com>
ANY replies to This email ARE in REPLY-TO "User1" <user1#example.com>
...is this correct?
If so, here's a working example of a text/plain email including headers + content:
From: "No-Reply" <noreply#ourcompany.com>
To: "User2" <user2#example.com>
Reply-To: "User1" <user1#example.com>
Subject: Document Request
MIME-Version: 1.0 (Created with SublimeText 3)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Good morning, User2.
Please send us your 1) driver license 2) passport 3) application letter.
Thank you,
Ourcompany Inc.
I tried to install ReadTheDocs on my linux server following the documentation: http://read-the-docs.readthedocs.io/en/latest/install.html
However I do not receive the activation email.
I was able to see the output of the email on the server
Hello from example.com!
You're receiving this e-mail because you or someone else has requested a password for your user account at example.com.
It can be safely ignored if you did not request a password reset. Click the link below to reset your password.
http://xxxxx:8080/accounts/password/reset/key/xxxxxxxxxx/
In case you forgot, your username is xxxxxxxxxxxx.
Thank you for using example.com!
example.com
note: This email is a password reset email, it has the same problem as the activation email. (I didn't receive any email from my ReadTheDocs installation)
There are two things that got my attention.
1. Where does read the docs configure the website name, I would like to change example.com to th real website name.
2. The sending adres currently is no-reply#readthedocs.org, where can I change it? I think its also a part of the issue.
Here are the other headers of the email
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: [example.com] Password Reset E-mail
From: no-reply#readthedocs.org
To: xxx#xxxxx.nl
Date: Tue, 12 Jul 2016 11:30:49 -0000
So actually I have two questions
Where can I change the content of the email and things like the sender adres.
What happend with the email (why won't I receive it)
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'm seeing mangled URL parameters coming from IE9 desktop clients. The links are sent via email, and all of the mangled URLs come from the plain-text version of the email.
I'm almost sure that it has nothing to do with my stack (django, nginx, mandrill) The values for the parameters have characters exactly transposed. The original character is the mangled one minus 13 places (eg. rznvy_cynva = email_plain, ubgryfpbz = hotelscom).
Here is one example of a mangled request that came through:
GET /book/48465?sid=rznvy_cynva&order=q09362qs55-741722-442521-98n2-n88s4nnr87192n&checkOut=07-17-15&affiliate=ubgryfpbz&checkIn=07-16-15 HTTP/1.1" 302 5 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"
All of the requests with mangled URLs have the same user-agent as the example.
The IP addresses associated with the mangled URLs aren't restricted to any location.
Looking up the user-agent, this seems to be restricted to desktop Windows 7, IE9 users.
It is anti-malware software on your recipients' computers. It gets the links and scans your pages for any possible vulnerabilities. It uses rot13 obfuscation to ensure that it doesn't take any unwanted actions ("buy now", etc.).
https://security.stackexchange.com/questions/48684/help-investigating-potential-website-attack-url-rewriting-and-rot-13-obfuscatio
The solution is to track down what anti-malware software / company is performing the scans, and get your site whitelisted if possible.
This is going into the realm of speculation, but I'm also guessing you cannot get any answers which don't, so here goes ...
The rot13 encryption does not look like an accident. I have two guesses to offer;
Somebody is sharing their email and obfuscating query parameters in links so as to break the "order now", "unsubscribe" etc links while maintaining the overall integrity of the email messages. Maybe this is a feature of a spam-reporting tool or similar?
Alternatively, the queries are made from within a test network where users are not supposed to click on links, but the tools in there need pretty much unrestricted Internet access; so the admin set up an HTTP proxy which rewrites the query URLs to dismantle most GET transactions with parameters. (POST requests I guess would still probably work?)
Your observation that the IP addresses seem to be nonlocalized somewhat contradicts these hypotheses, but it could just mean that you are looking at TOR endpoints or similar.
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.