When I Pull Mail, how do I know whether a mail is Answered for Exchange, IndexBox.Search(SearchQuery.Answered) and IndexBox.Fetch(uid,MessageSummaryItems.Flags) can not get Replied to Mail?
I'm not entirely sure what you are asking because it seems to me that you've answered your own question.
folder.Search (SearchQuery.Answered)
This will return the UniqueIds of the messages that you have replied to.
folder.Fetch (..., MessageSummaryItems.Flags)
This will return a list of message summary records that will have the Flags field populated. You could then iterate over the list to find which messages had the Answered flag set.
If your question is not about how to know which messages have been replied to, but instead you are asking how to get the reply message, there is no IMAP command specifically for doing that.
What you would have to do is Fetch() the Envelope for the original message in order to get its Message-Id value and then you could try:
folder.Search (SearchQuery.HeaderContains ("References", msgid).Or (SearchQuery.HeaderContains ("In-Reply-To", msgid)));
Hope that helps.
Related
Is it possible to set the "reply-to" header field in a Mailgun list? While conversations are sometimes nice, people are getting annoyed at the volume of mail from one particular list, in which respondents ignore the instruction to send the message to a certain email address and hit reply, resulting in dozens (or more) messages containing things like "Got it!" or "I'm coming!" when only one person needs to see the response.
For this particular list, the ideal situation would be to limit the allowed senders to just a few people, but as none of them use services quite as nice as Gmail or a standalone email client (additional SMTP logins cannot be established), I've not found any way to limit the inanity. Does anyone know how to do this?
I am not sure if you are still looking for the answer, but you can set the Reply-To header using the API.
h:Reply-To
I have been using it with an email hash - each user gets a unique hash in the reply-to field so I know who is replying. Basically the reply-to looks like this:
"h:Reply-To" : "inboundaddress+hash#mydomain.com"
In the routes panel add the following and you can redirect to your email or to an HTTP endpoint:
match_recipient("^inboundaddress\+(.*)#mydomain.com")
Hope that helps.
Justin
You can programmatically add the header "Reply-To" in the data you are sending.
For example, this snippet works well in Python:
import requests
url = 'https://api.mailgun.net/v3/YOUR_ACCOUNT/messages'
auth = ('api', 'YOUR_KEY')
data = {
'from': 'Info <info#email.com>',
'to': ['user1#email.com', 'user2#email.com'],
'subject': 'test email',
'html': '<b>hello!</b> that's all.,
'text': 'plain text here',
'o:tag': ['categoria 1', 'categoria 2']
}
data['h:Reply-To']="My name <my#email.com>" # <------------- HERE!
res = requests.post(url, auth=auth, data=data)
Please check this issue in mailgun-js
https://github.com/bojand/mailgun-js/issues/57
You just need to add 'h:Reply-To' to your email configuration object:
const options = {from, to, subject, text, html};
if(replyToAddress){
options['h:Reply-To'] = replyToAddress;
}
That will add new header to the e-mail :)
I have been looking for the exact same functionality and have not yet found one. I even tried using the Routes but that did nothing more than forward an email before sending it out to everyone else. I opened a ticket with support and received the same reply. There is not a way to set that at this time.
This is one of those hard to explain questions. I've tried my best below, hopefully it is clear what I mean.
Emails are coming in to an address (foo#example.com), and are being forwarded to another email address (bar#subdomain.example.com). The second email address further pipes the email to a simple script, but the script needs to actually know the second email address as it provides meta-data that is crucial to sorting the message (that is, the script gets piped any email sent to *#subdomain.example.com, and it needs to see that it got forwarded to bar#subdomain.example.com in order to correctly process the incoming message).
Originally, I thought that the virtual alias used to forward messages from foo#example.com to bar#subdomain.example.com would update the envelope-to header, but it remains unchanged the same. None of the other headers nor the "received" line reflect that the message was forwarded. My theory is that maybe the pipe instructions for *#subdomain.example.com can be updated to somehow pass the actual address on to the script, but I am not sure how.
For reference, I have included a few examples below:
Headers, after being forwarded:
From sender#example.com Sun Dec 11 19:53:40 2011
Envelope-to: foo#example.com
Received: ...
Subject: Test 6
The valias file for subdomain.example.com (/etc/valiases/subdomain.example.com):
*: "|/home/user/example_script.x.php"
And I answered my own question. It turns out, the recipient is accessible in an environment variable. In my case, since I am using PHP, I can just use the following variable:
$_ENV['RECIPIENT']
I this is probably a strange question, but I thought I'd go ahead and ask. Say, I send an email, using IMAP SMTP, through a special client. This client adds a few custom headers to the email message before sending it on its way. The recipient receives this email and responds to me directly (and maybe CC's a few people as well).
My question is this: Given the above example, would these X-headers persist throughout all the new messages within the thread?
One thing I can think of is the client would be aware of the original email message it sent. All subsequent responses to this email would have a "Reply-To" header whose value equals the "Message-Id" of the previous email. I don't see why I couldn't crawl up these thread of replies until I get to the original message sent by the client, thereby deriving the original custom headers.
Maybe I'm over-thinking this. Any suggestions? :)
A message reply does not necessarily contain anything of the original message. The MUA is likely to suggest a modified (e.g. prepended with "Re:") version of the original subject, and obviously the addresses are utilised for appropriate defaults as well. None of the other content of the message forms part of the reply (unless the sender deliberately includes it, as with quoting or forwarding). Any X- headers that you have in your message will certainly not be included in the reply (unless you have control over that MUA).
However, your plan of tracking the original message is certainly feasible: see Section 3.6.4 of RFC 5322. Every message should (not must) have a Message-ID header, and should have In-Reply-To and References headers when appropriate.
The "Message-ID:" field contains a single unique message identifier. The "References:" and "In-Reply-To:" fields each contain one or more unique message identifiers, optionally separated by [whitespace].
In-Reply-To is mention to identify the message (or messages) that is (are) being replied to, while References identifies the entire thread of conversation. The References header is meant to contain the entire contents of the References header of the message being replied to, so you only need the last message to identify the entire thread.
Note that In-Reply-To and Reply-To are not the same thing (the latter specifies the address that the sender wishes replies to be sent to).
Assuming that you have the original message, then you should be able to use the References header of any reply to identify the original message. Not every MUA will handle References or In-Reply-To correctly, but most will.
As far as I know, there's no reason to think any email client would propagate any header lines it doesn't understand. Most will preserve the subject (usually adding "Re: " if necessary) and derive their "To: " and "Cc: " lines from the previous message's headers, but that's about it. I suppose some (but not all) will generate an "In-Reply-To" line, but that's as far as it goes.
Your idea of having a client crawl back through the thread looking for specific headers sounds like it might be do-able, but you'd have to write your own email client if you want that feature, and you'd still be blocked by the fact that not all email clients preserve message threading in any way.
How would one go about changing the 'From' field of the contact form email to that of the sender's? For instance, if a customer was to fill in the form with the email 'test#test.com', how can I make the generated email be from 'test#test.com'?
I've looked at the 'email sender' field in the system admin panels, but this only allows for a range of preset store emails.
Many thanks
The place where this gets sent is in app/code/core/Mage/Contacts/controllers/IndexController.php at abouts line 100. It looks like the reply-to address for the emails is already set to the email address from the post, so if you're just looking to get easier replies, I'd suggest not fooling with it.
Another issue that you'll likely see is that sending email with a spoofed "from" address may cause your site to quickly become blacklisted from many email providers, which may affect the rest of your business.
That said, if you still want to do this, in that file change this code a bit:
$mailTemplate->setDesignConfig(array('area' => 'frontend'))
->setReplyTo($post['email'])
->sendTransactional(
Mage::getStoreConfig(self::XML_PATH_EMAIL_TEMPLATE),
Mage::getStoreConfig(self::XML_PATH_EMAIL_SENDER), // change this
Mage::getStoreConfig(self::XML_PATH_EMAIL_RECIPIENT),
null,
array('data' => $postObject)
);
Hope that helps!
Thanks,
Joe
Magento Contact Form - been receiving email from myself is a newer duplicate of this question and Joe's answer got me on the right path. In my answer to the duplicate question, I wrote a custom module to override app/code/core/Mage/Contacts/controllers/IndexController.php and ended up changing the indicated line above to array('name'=>$post['name'], 'email'=>$post['email']), to make the fix.
IMHO, when I do urgent small fixes in the core that have to stay until properly overloaded, I'm sure to end each line with a comment with my initials twice //CKCK hack to fix ___ and then you can grep for this and see all of your mods via ssh shell: app/code/core$ grep -rn "CKCK" *
I'm also using github for version control, which helps, too.
I am currently extending an e-mail system with an autoresponse feature. In a dark past, I've seen some awesome mail loops, and I'm now trying to avoid such a thing from happening to me.
I've looked at how other tools ('mailbot', 'vacation') are doing this, grepped my own mail archive for suspicious mail headers, but I wonder if there is something else I can add.
My process at this point:
Refuse if sender address is invalid (this should get rid of messages with <> sender)
Refuse if sender address matches one of the following:
'^root#',
'^hostmaster#',
'^postmaster#',
'^nobody#',
'^www#',
'-request#'
Refuse if one of these headers (after whitespace normalization and lowercasing) is present:
'^precedence: junk$',
'^precedence: bulk$',
'^precedence: list$',
'^list-id:',
'^content-type: multipart/report$',
'^x-autogenerated: reply$',
'^auto-submit: yes$',
'^subject: auto-response$'
Refuse if sender address was already seen by the autoresponder in the recent past.
Refuse if the sender address is my own address :)
Accept and send autoresponse, prepending Auto-response: to the subject, setting headers Precedence: bulk and Auto-Submit: yes to hopefully prevent some remote mailer from propagating the autoresponse any further.
Is there anything I'm missing?
In my research so far I've come up with these rules.
Treat inbound message as autogenerated, ignore it and blacklist the sender if...
Return-Path header is <> or missing/invalid
Auto-Submitted header is present with any value other than "no"
X-Auto-Response-Suppress header is present
In-Reply-To header is missing
Note: If I'm reading RFC3834 correctly, your own programs SHOULD set this, but so far it seems some autoresponders omit this (freshdesk.com)
When sending outbound messages, be sure to...
Set the Auto-Submitted: auto-generated header (or auto-replied as appropriate)
Set your SMTP MAIL FROM: command with the null address <>
Note some delivery services including Amazon SES will set their own value here, so this may not be feasible
Check the recipient against the blacklist built up by the inbound side and abort sending to known autoresponders
Consider sending not more than 1 message per unit time (long like 24 hours) to a given recipient
Notes on other answers and points
I think ignoring Precedence: list messages will cause false positives, at least for my app's configuration
I believe the OP's "auto-submit" rule is a typo and the official header is Auto-Submitted
References
RFC3834
This SO question about Precedence header has several good answers
Wikipedia Email Loop Article
desk.com article
Comments welcome and I'll update this answer as this is a good question and I'd like to see an authoritative answer created.
Update 2014-05-22
To find if an inbound message is an "out-of-office" or other automatic reply, we use that procedure:
First, Find if header "In-Reply-To" is present. If not, that is an auto-reply.
Else, check if 1 of these header is present:
X-Auto-Response-Suppress (any value)
Precedence (value contains bulk, or junk or list)
X-Webmin-Autoreply (value 1)
X-Autogenerated (value Reply)
X-AutoReply (value YES)
Include a phrase like "This is an automatically-generated response" in the body somewhere. If your message body is HTML (not plain text) you can use a style to make it not visible.
Check for this phrase before responding. If it exists, odds are good it's an automated response.