I am developing an application which enables the user to do a reply via email. However, when a user replies to an email, the original email is also appended to the user's response.
This original email text is being appended in different ways for different clients. For gmail it starts as
On Tue, Jan 4, 2011 at 6:24 PM, User
wrote:
Like wise it's different for each client.
Is there any way to identify the original email text from user's reply?
There are three popular ways of tracing the parent of an email message, all done via the message headers rather than the message body.
The In-Reply-To header, when present, should contain the value of the Message-ID header of the parent message.
The References header, when present, should contain a space-separated list containing some of the message-ids of the message's ancestors, ordered from oldest to most recent. The last one in the header should be the value of the Message-ID header of the parent message.
The non-standard Thread-Index header is Microsoft Outlook-specific. When present, it contains a base64-encoded value. If you decode this value, remove the last 5 bytes from the resulting byte array, and re-base64-encode the result, you'll have the value of the Thread-Index header of the parent message -- if the parent had a Thread-Index header.
Related
I'm sending mass messages with custom messages per subscriber, when I get the bounce-back I use my own cocktail to read the STMP emails.
What I haven't figure it out is how to add a unique ID for each email that is sent out, so in my bounce-back I can read the email's code and look for that particular ID, currently when I read the bounce I look for the recipient email compare to what I have based on creation date plus the email...
Is not efficient and 20 emails out of 1K or so gets lost cuz I can't find in bounce the headers due to some servers custom messages although it does return headers but I have nothing to compared with...
So is there a way to add this UUID in Swift services? I have seen that Swift is adding its own UUID but I haven't been able to retrieve it, when the message is sent I want that UUID so that I can save it and then latter I can read it from the bounces...
So, if I can't retrieve it, can I add my own?
I wanna have a relation email and UUID that was use when that message was sent.
$message_out = (new \Swift_Message($out->subject))
->setFrom($out->from_email, $out->from_name)
->setTo($out->email)
->setBody($content, 'text/html')
->setReplyTo('noreply#foo.com', 'No reply');
$message_out->send($mensaje_mail, $errors_sent);
Is this a header I can add the retrieve it in the bounce-back messages?
Thank you.
From what I've read, every Message-ID must be unique, however it is possible to create repeated Message-IDs if we force the header with a fixed value. So I don't understand what the point of them saying that the Message-ID should be unique, but they are very easy to create duplicates. If they can easily be generated by anyone with a little reading and basic programmatic knowledge, why do Message-IDs exist and what are they used for, which I can easily duplicate?
Short answer: For threading in email clients.
The message-id header is defined in RFC 2822:
The "Message-ID:" field contains a single unique message identifier.
The "References:" and "In-Reply-To:" field each contain one or more
unique message identifiers
The message ID is used to show which message is a reply to which other message, for example. That way mail clients can show a tree of emails with their replies even if other things like the Subject don't change. (Counting leading Re:s of the subject line would be a bad way to determine ancestors and children: not every mail client adds them, and some use language specific ones.)
https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.4
in conjunction with the References and In-Reply-To fields, mail clients use Message-ID to organize multiple messages into threads.
https://en.wikipedia.org/wiki/Message-ID
and at least some clients will consider two messages with the same ID to be the same thing and discard one of them.
Mail user agents usually display threads of Emails by chaining messages together according to the In-Reply-To and References header fields that contain the Message-IDs of other messages. Although a mail usually only replies to one other message, it may be the case that one message answers multiple others. The standard allows multiple entries in both fields. What can I expect when I send an email that References or is In-Reply-To multiple IDs this way?
Is it good practice to do so?
Does it confuse widespread MUAs?
Is there any common ground on how to display such a message in a
threaded view?
The "In-Reply-To:" field will contain the contents of the
"Message-ID:" field of the message to which this one is a reply (the
"parent message"). If there is more than one parent message, then
the "In-Reply-To:" field will contain the contents of all of the
parents' "Message-ID:" fields. If there is no "Message-ID:" field in
any of the parent messages, then the new message will have no "In-
Reply-To:" field.
Technically there COULD be a reason where you would reply to multiple emails and it would be valid to place multiple message ids in the In-Reply-To header. I can’t think of any program that actually supports this. As to MUAs they won’t care the delivery that the MUA cares about is the To, Cc, Bcc headers.
The In-Reply-To header and References header would control how threads are displayed. Not sure if any mail clients would have an issue handling the multiple In-Reply-To headers. 99% of the time there would only be a single message ID in the In-Reply-To header. So it’s feasible mail applications won’t support it. However they would support the additional reference entries. And this shouldn’t pose an issue.
We're considering using an external application to send e-mails where the attachments have huge filesizes.
One of our users states the requirement: it must be possible to ORDER attachments, so that I can refer to them as "the first attachment", "the second attachment" and the receiver will see the attachments in the same order I sent them.
She claims any normal email clients support this: the sender chooses the order, the recipients client always shows the attachments in this order.
I can't verify that claim. Is this true? Is it stated anywhere? How (technically) are attachments ordered?
Well... Inside the message there is order. Attachments are sent sequentially one-after-the-other inside MIME text. But RFC makes no statement on how these should be displayed in email client. And it even might depend on your email generating software to keep the order you added the attachments in (JavaMail does so)
Things you could consider:
Prefix your attachment filenames with a number 1_first_attachment.txt 2_contract.pdf and so on.
Use HTML for your emails and create a section "attachments: a, b, c" with linkd to the attachments using Content-ID (href="cid:xxx")
Actual, when u load the document to the email, and load next, they gonna be in order anyway. They not gonna be mixed.
if u afraid that particular ur email gonna mix attachments, just add numerical order)
This is example where i just adding files. I just by holding shift click on the files in that order that i wanted and that is all.
And i receive this message with attachments in the same order as it was sent.
If I poll an IMAP server for an Envelope structure SELECT INBOX, FETCH UID ALL - I will get an envelope structure in return.
For all fields in the envelope structure that are an email address, from, sender, reply-to, etc, I have noticed this is how an email address is represented:
(("Name on Email Account" NIL "emailaddress" "domain.com"))
or for accounts with no email name set -
((NIL NIL "emailaddressnoname" "domain.com"))
I can see the 1st value is the name, the 3rd value is the email address name & the 4th value is the domain name - but what is the 2nd value for? I've polled for hundreds of emails from many different IMAP servers and this value is always NIL & I'm afraid that one day it's not going to be NIL and it's going to mess up my parsing code.
In the part of the RFC that defines Envelope structure (https://www.rfc-editor.org/rfc/rfc822) nothing is mentioned about this.
Anybody know what's going on?
From RFC 3501, section 7.4.2 (Fetch Responses), subsection ENVELOPE:
An address structure is a parenthesized list that describes an
electronic mail address. The fields of an address structure
are in the following order: personal name, [SMTP]
at-domain-list (source route), mailbox name, and host name.
The second portion represents source routes, which are obsolete on the Internet, so can be effectively ignored.
There is also information about group list syntax, which is also nearly obsolete, but you may come across it occasionally.