649462 - email_in.pl should be able to cope with strange line breaks coming from Outlook

Status: NEW

(Bugzilla :: Incoming Email, defect)

Description

[Marc Schumann [:Wurblzap]]

Outlook distinguishes between end-of-line and end-of-paragraph. If I type something in a single line, and I finish the line using the Enter key, I end the paragraph. If I finish the line using Ctrl-Shift-Enter, I end the line (keeping the paragraph). That's me using Outlook 2010, sending HTML mail.

Now, Outlook transcribes an end-of-line as a regular end-of-line, and an end-of-paragraph as two consecutive end-of-lines. This results in email_in.pl rejecting mails because of insufficient information (e.g. component missing) -- even if I typed all information just fine one line after the other, email_in.pl stops after the first end-of-paragraph, seeing a single empty line.

Workaround, of course, is to use Ctrl-Shift-Enter to finish these first lines (@product, @component, ...). This works just fine, and I can do this. But I don't want to train my Outlook-ridden Bugzilla users to do this; I don't think I'd succeed.

I'd rather see email_in.pl be able to accept such mails.

Comment 1

[Max Kanat-Alexander]

Arrrgh, Outlook! Sigh. This is the default behavior and it will affect everybody sending an email to email_in who composes in text/html and sends in multipart/alternative?

It should be easy enough to look and see if the line after the blank line starts with @, but the problem is that in the future, we may make "@mkanat" the way of addressing a comment to somebody. When we used to require "@field=" we could have checked for that, but we don't check for it anymore.

I suppose if we wanted to get *really* complex, what we could do is check if the next @ actually is a valid field, and treat it as the start of a comment if there's a newline before it. However, that will still be somewhat fragile--many @fields are not in fielddefs, and many more could be added by extensions as arguments to Bug->create without being validatable.

Comment 2

[Max Kanat-Alexander]

I think another possibility is that we should start stripping HTML and attempting to use the HTML part of the message validly, particularly if we can tell that the message came from Outlook. (I wonder if there's an "change HTML to Markdown" module?) That would also let us take pure-HTML emails, which one of my clients wants anyhow. This would be a separate bug from this one, though. And it may cause the same problem in any case, which is that <p> will probably translate into "line newline newline".