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.
Related
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
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.
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.
We need to pass some data in emails that can be used for tracking and correlation, we were looking at using a custom header or a token in the subject/body.
Does anyone know of an email header that can be used that will not be removed by email servers? I know you can add X- headers to specify custom content but it seems you can never be sure they won't survive either the server stripping them or being removed when the email is forwarded.
The token option also doesn't seem ideal as it can easily be removed by the user, are there any other better techniques?
Thanks for your time
A server should not be stripping X- headers (as long as they are correctly formatted, anyway), unless perhaps you happen to pick a name for that X- header that the server uses for its own purposes. But there is no header that cannot be stripped or altered by a server or user. A proper forward operation should preserve the headers, and an improper forward isn't guaranteed to retain any headers.
A header is probably the best method, both because most users won't be aware that headers besides "From", "To", and "Subject" even exist and because that's really the place for such metadata. Encoding it in the Message-Id header might be slightly more robust than in an X- header. Or if it's very short, you could encode it in the subject line as a "ticket number" or the like.
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