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.
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.
How I did understand, message/delivery-status is a mime type of message part,
which contains the data formatted for the mail server to read (Wiki)
Does it mean that I can ignore it while receiving message from mail server? If not, could you give more explanation of present mime type.
How should I parse it and do I need to present it to user?
I found it on official specifications https://www.rfc-editor.org/rfc/rfc3464#section-2.1
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 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.
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