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)
Related
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.
If you google "How to check an email address for existence" question, you will find, basically, only solutions using SMTP protocol what is not reliable. I tried this approach and found that Gmail SMTP server says "Yes, this email is registered here" on each and every email address I ask about. I suspect such strategy is used on the majority of popular email servers.
The method I would like to share is used in Gmail registration form to ensure you are going to register a brand new email. It uses AJAX request to ask Gmail server if given email exists or not
Request URL:https://accounts.google.com/InputValidator?resource=SignUp
Request Method:POST
Status Code:200
Remote Address:173.194.222.84:443
Response Headers
alt-svc:quic=":443"; ma=2592000; v="37,36,35"
cache-control:private, max-age=0
content-encoding:gzip
content-type:application/json; charset=utf-8
date:Wed, 29 Mar 2017 21:06:06 GMT
expires:Wed, 29 Mar 2017 21:06:06 GMT
server:GSE
set-cookie:GAPS=1:<redacted>;Path=/;Expires=Fri, 29-Mar-2019 21:06:06 GMT;Secure;HttpOnly;Priority=HIGH
status:200
strict-transport-security:max-age=10893354; includeSubDomains
x-content-type-options:nosniff
x-frame-options:DENY
x-xss-protection:1; mode=block
Request Headers
Provisional headers are shown
Content-type:application/json
Origin:https://accounts.google.com
Referer:https://accounts.google.com/SignUp?hl=en-GB
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Query String Parameters
resource=SignUp
Request Payload
{"input01":{"Input":"GmailAddress","GmailAddress":"andy.v.che","FirstName":"","LastName":""},"Locale":"en-GB"}
Response
{"input01":{"Valid":"false","ErrorMessage":"Someone already has that username. Note that we ignore full stops and capitalisation in usernames. Try another?","Errors":{"GmailAddress":"Someone already has that username. Note that we ignore full stops and capitalisation in usernames. Try another?"},"ErrorData":["andyvche959"]},"Locale":"en_GB"}
As you can see, there is "Valid":"false" in the response if such an email does exist, and (spoilers) "Valid":"true" if it doesn't.
Throttling queries down
Guys from Gmail do understand this method could be used by spammers to look for existing emails. That's why they don't allow massive scans using it. I was doing such a scan for some time and could scan only 200 emails a day approximately.
More details
I was scanning 1 email a minute, and if I was getting response "No, this email doesn't exist", I also asked if my own email exists. If I got "No, your email doesn't exist as well" answer, I could clearly understand that I got ban from Gmail server by my IP address. Then, I took a break for 45 minutes to get unbanned, then continued the loop. The number af emails scanned a day was fluctuating around 200.
You may ask: you did a scan like a spammer would perform, for what purpose did you do that scan then?
My answer is: I was trying to find a guy who wrote his email unclearly (bad cursive). There was no other option to find him.
There were 3 unclear letters in his written email but it was clear the domain of it is gmail.com, so I came up with an idea to find a way to check an email address for existence on Gmail, generate a list of all possible emails (trying to substitute unknown symbols with all possible English letters) and check them all for existence. Then, send a letter to all existing ones.
The right of this information to be published is discussed in this question. I understand this article will be very useful for spammers so I'm open to deleting it partially or even completely for the sake of security.
We send out password-reset emails to business partners who use our intranet. The body of the email contains a hyperlink:
`http://www.ourdomain.com/ResetPassword.aspx?token=....`
But some of the people who receive these emails are saying there's an extra dot in the domain name:
`http://www.ourdomain..com/ResetPassword.aspx?token=....`
I do not see where that could be happening in the program I've written. I store the base url in the web.config:
`http://www.ourdomain.com`
and attach the name of the aspx page and append the token to it.
Are there any corporate anti-virus programs out there which deliberately mangle hyperlinks discovered in the body of emails, to render them invalid and thus unclickable?
This seems to be per the spec of quoted-printable encoding. It just so happens that the length of text in the message breaks to a new line right at the .com (72 characters maybe?). Please verify that this is the case by sending yourself a message and analyzing the quoted-printable source of the message.
System.Net.Mail creating invalid emails and eml files? Inserting extra dots in host names
The solution would be to not use quoted-printable encoding if some email programs cannot correctly interpret the spec.
plainText.TransferEncoding = System.Net.Mime.TransferEncoding.SevenBit;
//or base64
I want to change the encoding of the message returned from RETR command in POP3.
I get this header in the reply:
Content-type: text/html; CHARSET=WINDOWS-1255
I want to change it to:
Content-type: text/html; CHARSET=UTF-*
Thank you very much. Sorry about my English...
You can't. The POP3 server knows nothing about the encoding of the message - it just stores the message (exactly how it got it) and then hands it over to the client. In fact - theoretically you could retrieve something via POP3, that isn't an email at all.
The encoding of the message is generated at the sending side, not the receiving side.
I'm fetching emails from a POP3 server and I'd like to make a difference between a regular email and DSN (Delivery Status Notification) / NDR (Non-Delivery Report/Receipt) messages.
What is the best/safest way to identify those messages? Are there any particular message-headers I should be looking for?
Thanks in advance!
Some mail servers implement RFC 3464. Those that do will typically generate Delivery Status Notifications with a message header Content-Type of multipart/report and three component parts (text/plain, message/delivery-status and message/rfc822). So you could detect those characteristics of the message and process accordingly. The message will generally look like this:
From: "Mail Delivery System" <MAILER-DAEMON#example.com>
Subject: Delivery Status Notification (Failure) Content-Type:
multipart/report; report-type=delivery-status
Content-Type: text/plain A human readable explanation of the
Delivery Status Notification.
Content-Type: message/delivery-status A structured machine readable
reason for the Delivery Status Notification.
Content-Type: message/rfc822 The original message.
For those mail servers that generate Delivery Status Notifications in an unstructured format, it is probably still necessary to detect their notifications by analysing the text of the From: and Subject: message headers.