I am sending a text only email using TIdMessage and TIdSMTP.
For the Body I use a simple concatenated string like
Body := SomeText + #13#10 +
SomeOtherText + #13#10 +
SomeMoreText + #13#10 +
FinalText;
Anyway in the generated email some of the "#13#10" aren't ignored. I log the Body variable and I can see that the text goes to new line, anyway in the email this doesn't happen. The strange thing is that doesn't happen on every line but only on some lines.
Do you have an idea on why this happens? Can you suggest something to check for? Is there some possible confict between #13#10 and an text email body in some conditions?
UPDATE
After more investigation (thanks to your comments) I realized it is an Outlook visualization problem, anyway the problem is still not clear to me.
This is the body of the email opened in NotePad++ (I opened the msg file saved from outlook) where I show also line breaks (you can see #13#10 as CR LF. I highlighted in red and green the 2 line breaks that are problematic in outlook (but you can see that in NP++ they look like all the other linebreaks):
The email in Outlook looks like this (please note that outlook says that the message has extra line breaks and that they hahve been removed, but he offers an option to restore them:
After choosing that option the email is ok:
I don't understand why this happens only on some line breaks. Does this help you to understand the problem better?
You could try using IdMessage.NoEncode := True so that the Body will not be RCF 821 encoded.
Or better use modern encoding IdMessage.ContentType := 'text/html' and replace #13#10 with <br>
EDIT:
This is an Outlook Express issue.
Look Here and Here.
A workaround would be to add 2 empty characters to the beginning of each line of text in order to make Outlook not remove the breaks.
Note that Microsoft support also suggests using HTML format as a possible workaround with Outlook Express:
Method 2. Use HTML or Rich Text format
You can use HTML or Rich Text formats when you create new items. Or you can change existing posts to these formats.
It might be the email client stripping out some line breaks, if your ContentType is plain text.
Related
Using Mandrill I'm sending an email that has a link:
<a href="http://www.slotted.co/NzIyNnx0c2NvdHRAc2xvdHRlZC5jbw==">
http://www.slotted.co/NzIyNnx0c2NvdHRAc2xvdHRlZC5jbw==
</a>
As expected Mandrill replaces my HREF with a tracking link:
http://mandrillapp.com/track/click/30319089/www.slotted.co?p=eyJzIjoiT1h4VE04RlV2bWp5R2YzNjZkNnNWaFpOemJ3IiwidiI6MSwicCI6IntcInVcIjozMDMxOTA4OSxcInZcIjoxLFwidXJsXCI6XCJodHRwOlxcXC9cXFwvd3d3LnNsb3R0ZWQuY29cXFwvTnpJeU5ueDBjMiBOdmRIUkFjMnh2ZEhSbFpDNWpidz09XCIsXCJpZFwiOlwiM2NmMWE4MzUzNGE1NDg4ZTg1OTUwMDkxZmFhY2M5NTNcIixcInVybF9pZHNcIjpbXCI3YWM1ODFiMTJkY2E0YWM4YzZlMmM3ZDU2OWU2YzQ5MmMxNDIxMDJmXCJdfSJ9
This link redirects to:
http://www.slotted.co/NzIyNnx0c2%20NvdHRAc2xvdHRlZC5jbw==
Notice the extra %20 in the middle of the path which obviously breaks the link. You can try it yourself.
Seems like a bug, but I'm still on the free plan, so no way to report it. Any suggestions?
See this answer:
We typically see this kind of issue with SMTP libraries or frameworks
that generate HTML with no true line breaks. The SMTP specs state that
the line length for email shouldn't exceed 1000 characters. When that
limit is reached, a line break gets inserted automatically when the
message data is being transmitted over SMTP. This unfortunately often
happens right in the middle of a word or a URL, for example. You'll
want to take a look at your SMTP library to see if you can modify how
line breaks are being handled.
If you're using HTML line breaks like <br> that are being used to
indicate a break, those unfortunately won't help in this case. Adding
your own line breaks (not HTML line breaks, but actual line breaks in
the data such as a newline or end of line - usually \r\n - will help
ensure that the forced line breaks aren't arbitrarily added in the
SMTP conversation in inconvenient places.
My Rails app processes incoming emails by splitting them into multiple lines. This is what I currently use on the plain text version of the body: lines = email.body.split("\n")
This works well unless the sentences are longer than ~74 characters as most email clients will automatically add a line break per RFC 2822.
Example email: https://gist.github.com/marckohlbrugge/39c17b928eb17d330d63
Looking at the plain text part there seems to be no way to discern between a line break added by the user versus the email client. You could ignore any line break happening at the 75th position, but I think there might be a chance of false positives. (I could be wrong.)
The HTML part has all the information we need, but I'm not sure about a universal way to process this. Is replacing every div and br with a newline and then stripping al other HTML elements enough? What about all the other block-element tags? What about inline elements styled as block-elements? What if an email doesn't have an HTML part?
I did find some interesting code examples in Convert HTML to plain text (with inclusion of s), but replacing a list of html tags with newlines doesn't seem like a complete (exhaustive) solution.
Is it worth looking at something like this mail library as they've probably already thought about the edge cases? ;)
I am using TIdMessage and when I assign empty subject e.g. IdMsg->Subject = ""; outgoing message does not have "Subject:" header.
If I add subject by having a space e.g. IdMsg->Subject = " "; then the message has Subject: header even though it trims the space - the output is not: "Subject:[sp][sp][cr][lf]" but it is "Subject:[cr][lf]". This is clearly not consistent with the rest of headers which all have a space after the colon and before actual data so the empty subject should be "Subject:[sp][sp][cr][lf]".
I understand that the TIdMessage tries to optimize message by removing headers or trimming them but it is just being too smart here.
Is there a way to force having a Subject header with 2 spaces behind it (without editing the TIdMessage source code)?
For those wondering about the reason - I want to make sure that dumb email reading programs/scripts correctly interpret as "empty subject" which is the reason for all of this and not as something else and removing Subject: header is not much of an optimization anyway.
Your space character actually survives the encoding process when TIdMessageClient is generating the header data being sent, but then the space is getting trimmed by TIdHeaderList when it is parsing the final header data and folding long headers to fit within email line length restrictions. Each line generated for a given header by the folding process gets right-trimmed, and since your header data only consists of whitespace, it gets discarded.
The only way to disable that folding is to set the TIdMessage.LastGeneratedHeaders.FoldLines property to False, which is not advisable unless you know your headers will always be short enough to never need folding.
Another option is to set the TIdMessage.Subject to a blank string, and then use the TIdMessage.ExtraHeaders property instead. You will have to use ExtraHeaders.Add() instead of ExtraHeaders.Values so that the string is added as-is and avoids folding:
Msg.ExtraHeaders.Add('Subject: ');
Does Indy9 have any way to get a specific raw email header (say, "Subject" or "From") which still includes the transfer-encoding (ie: has not been mangled by DecodeHeader on older versions of Delphi with poor Unicode support), or would I have to parse the entire email header manually to extract this information?
The TIdMessage.RawHeaders property is what you are looking for, eg:
Subject := IdMessage1.RawHeaders.Values['Subject'];
I have solved the problem, calling IdMessage1.Headers.Values['Subject'] BEFORE calling IdMessage1.ProcessHeaders gives different results than after.
I am unsure of the best way to handle this. In my index view I display a message that is contained in TempData["message"]. This allows me to display certain error or informational messages to the user when coming from another action (for example, if a user tries to enter the Edit action when they don't have access, it kicks them back to the Index with a message of "You are not authorized to edit this data").
Prior to displaying the message, I run Html.Encode(TempData["message"]). However, I have recently come into the issue where for longer messages I want to be able to separate the lines out via line breaks (<br>). Unfortunately (and obviously), the <br> gets encoded by Html.Encode so it doesn't cause an actual line break.
How do I process line breaks correctly in Html Encoded strings?
The easiest solution I've seen is:
#MvcHtmlString.Create(Html.Encode(TempData["message"]).Replace(Environment.NewLine, "<br />"))
If you are using a razor view, you should not have to call Html.Encode normally. By default, Razor html encodes all output. From Scott Gu's blog introducing Razor:
By default content emitted using a # block is automatically HTML encoded to better protect against XSS attack scenarios.
I agree with #Roger's comment - there is not really any need to encode anything that you have total control over.
If you still wish to be better safe than sorry (which isn't a bad thing), you could use the Microsoft AntiXss library and use the .GetSafeHtmlFragment(input) method - see HTML Sanitization in Anti-XSS Library
e.g.
<%= AntiXss.GetSafeHtmlFragment(TempData["message"]) %>
FYI, the Microsoft Web Protection Library (A.K.A. Microsoft AntiXSS Library) developers seem to have broken the assembly and pulled all previous versions that were working. It is no longer a viable solution in its current state. I was looking at it as a solution for this problem before reading the comments. All 18 of the current ratings for the latest release are negative and complain about it being broken with no updates from the developers so I didn't even try it.
I went with #ICodeForCoffee's solution since I'm using Razor. It is simple and seems to work quite well. I needed to take potentially lengthy descriptions with line breaks and format them so the line breaks would come through in the page.
Just for completeness, here's the code I used which is #ICodeForCoffee's code modified to use the description field of the view's model:
#MvcHtmlString.Create(Html.Encode(Model.Description).Replace(Environment.NewLine, "<br />"))
"Process" the message in the controller:
HTMLEncode the message
Insert the line break tags
Add message to the TempData collection.
Try this:
StringBuilder sb = new StringBuilder();
foreach(string message in messages)
{
sb.Append(string.Format("{0}<br />", Server.HtmlEncode(message));
}
TempData["message"] = sb.ToString();