I'm writing an app which allows users to send out a text-only email to a bunch of recipients. I want to try and generate the subject of this email from the body of the message, to avoid the need for a subject field
Is it safe enough to do this? Are these emails likely to fall foul of spam filters?
I'm already scanning the entire email for spam words, so there won't be any in the subject
you could download the widely used spamfilter Spamassassin and search for 'SUBJ' in the *.cf files, this will give you many spamrules that trigger based on subject (like empty subject, all caps, bad words, bad encoding of non-ascii characters etc)
I would suggest that if the mail is from a trusted source then there is not a problem. On the other hand since the mailbox dosent know that the subject is generated automatically it does not matter to them. And the third thing is that you need to check the guidelines that the email filters follow. Check out some ope source mail filter.
Related
How do you handle email bouncebacks with personalized subjects? We send bulk emails to thousands of clients daily. Currently we run a script that combs our inbox and places all emails with the same subject into various folders that match our SQL database. This works great until a personalized email subject is sent. Because these emails all have unique subjects our script ignores these emails. Does anyone have any suggestions on how to handle this? We can't always say ignore the first part of the email because what if the personalized part comes in the middle of the subject. We thought about passing a unique code into the subject that would be hidden...but this doesn't seem to work across all email clients. Any thoughts or suggestions would be really appreciated. Thank you all!
*added so when our script runs it is done through a process that compares the subject to our database using a dictionary that looks for exact matches.
When the email is sent out personalized, are there phrases that you use to personalize the subject? If so, I would keep track of the outbound subject phrases and tokenize the non personalized parts of the subjects. When the message bounces back, and it matches a personalized outbound subject, you can strip out the personalized strings, and you would be left with a matching set of tokens in the subject that match your out bound subject tokens.
If the subjects are sent out automated but completely personalized with no common tokens, you can store the target address and subject on the outbound route. When you get a bounce back that is randomly personalized, you can look in the outbound storage for the same recipient, subject combination and infer that the message is a personlized subject that indeed bounced back.
Are there any reasons (Spam, etc.) to include the name in the To: headers instead of just omitting them and only using the address?
No, it just looks pretty, that's mostly it.
When you're sending mail to multiple people it can be useful when some of the recipients' email addresses don't easily map to their names.
It usually displays in your email client. If you leave it out, it simply displays <example#test.com> instead of Example Test <example#test.com>.
Im guessing it might be a factor for spam detection too (so adding the recipients name makes it more likely to show up in the inbox)
I have been playing with email headers. I am trying to include a record identification number in the email header so that if I send an email and then it is replied to, the reply that I receive will be automatically allocated within my email client based on the record identification in the header.
When I have tried to do this, on reply to my email the original header including my record identification is deleted.
Is there are better way to do this? I was thinking I could just add it to the subject however I would rather the identifier be invisible to the user.
Address tags might be what you're looking for, if your email client supports it. You would put the tag in your reply-to address, not in an email header. I don't think you can expect your headers to remain in the reply.
Matching replies with the original message is exactly what the standard Message-ID: header is for. It's a unique string that identifies the email, and it's generally included in replies. You needn't -and shouldn't- invent any new headers nor any special processing of existing headers for this. (If you want to understand all the gory details, look at the email RFC documents.)
If they're not displaying for you, the problem is not that the information isn't there, but rather that your email-program isn't very smart. (Or maybe you have to turn on some option in the email program...)
I am sending email using cakephps email function. The email sends correctly but it is going to the spam folder.
Can anyone sugggest?
There can be many causes:
The email's content looks like spam (lots of links within a little amount of text, too much alpha-numeric gibberish, certain common spam words)
The server from which you're sending the emails has been black-listed
The email is not properly formatted (so in your case, check that you're using CakePHP's email function fully correctly)
I would try to send a good length, regular email without any links, as if you were writing to a friend, and see if it's a content issue. If the server you're emailing from has been identified as a source of spam and is black-listed by an ISP, there's not a whole lot you can change about that.
It can happen due to your mail content.
Check your mail contents that contain somethings that spam filter count.
Am trying to determine the best way to persist information from an originating email, through to a reply back.
Essentially, it is to pass a GUID from the original email (c#), whereby when the receiver replies back, that GUID is also sent back for reference.
I have tried setting the MessageID, whereby using Outlook, the In-Reply-To value is set with the original ID, however using some webclient email systems, that value is not created on reply. Is there another way to sent this info through email headers?
Some variation on VERP is probably the most reliable...
http://en.wikipedia.org/wiki/Variable_envelope_return_path
Specifically, instead of having all your replies coming to the same address, encode the information you want to persist into the From address for the email.
For example, in the case of a helpdesk ticket, you could use something like:
From: Helpdesk <support-ticket-123#example.com>
To: End User <user#example.org>
Subject: Ticket #123 - problem with computer.
That way, regardless of what the user edits in the subject or text, you know what ticket is being referred to by the receiving email address.
I don't think you'll be able to do anything that is perfectly reliable by headers alone -- the number of clients that would have to cooperate is immense.
Most systems that do this work by including something in the body of the email that is sent that allows it to identify the message, and including text instructing the recipient to include that block of text in the response. You could also try including it in the subject (and including text in the body to leave the subject unchanged). That's how some mailing list managers I've seen do it.
I stumbled upon this question, and it's been very informative. This, however, leaves me with one question: Will using VERP, or a variation of editing the 'reply-to' or 'from address', cause the messages to be locked up in spam filters?
I have read that spam senders often change the bounce address to prevent their servers from getting clogged with bad email address bounces. Is it a spam risk to assume this approach?
The most reliable way is to put the ID in the subject, which should be preserved throughout replies.
(It doesn't hurt to tell your users that they should keep the subject intact.)
RT, a popular ticketing system, does this. They use a simple subject format like "[Ticket #123]" and key off of 123.