In T13053#235208, @epriestley wrote:

Hrrrm...

Hrrrm...

Vaguely related, the subject line for this mail is currently something like:

🐱 🐟

contains complex HTML elements (like inline comments) which would also need to be stored in a structured way and then rendered just-in-time

While it's on my mind -- these messages link to /mail/whatever/123/ right now, but that page doesn't hyperlink links in the mail body, which is a fairly significant usability issue since the workflow is: click the link to go to the mail, read the mail body, copy paste the link in the mail body into your address bar.

This report doesn't include working reproduction instructions so we can't move forward.

I can't reproduce this; it may have been fixed by D18776 + D18778.

My call with Mailgun was generally reassuring. Based on an uncharitable reading of the January 5th disclosure, my major concern was that they might be starting from a cultural position which was blind to internal actors as threats and everyone just used root / hunter2 written on a sticky note to log in to everything or something like that.

I suppose another reasonable attacker is "laptop thieves", but deleting any locally stored mail which was accidentally transmitted in the open seems like a reasonable way to recover from any confusion that arises until we figure out how foolproof the behavior needs to be.

The intended trigger for "Must Encrypt" is Herald rules like this:

The "Must Encrypt" change will necessarily link into the existing /mail/ web UI so users can read the mail content, so it's probably worth considering possible improvements.

Although I'm suppressing the X-Phabricator-To and X-Phabricator-Cc headers for "Must Encrypt" mail (and the "To: ..." and "Cc: ..." footers in the body), the recipients will still be visible in the actual "To" and "Cc" lines if metamta.one-mail-per-recipient has been configured to false instead of the default (which is true).

On Thread-Topic, this very old thread suggests that Outlook can show the header in some cases: https://bugzilla.mozilla.org/show_bug.cgi?id=411601

(They got back to me and we're scheduling a call.)

Mailgun has yet to respond to me after about three weeks, so I send them a followup.

This is resolved as far as I'm aware. See also T11767 (improvements to these limits), PHI125 (similar issue with non-UTF8 attachments failing to insert) and T13053 (planning).

I'm rolling this forward into T13053.

Mostly from the HN thread, other possible providers we haven't tried yet include Mandrill, Postmark, and Sparkpost.

T12677 documents previous general issues with mail providers. Mailgun gets the worst of it there, but just because we've been with them for a while without anything too awful happening.

The install in PHI271 reported this as fixed after upgrading.

Oh, yes, sorry, looked at the wrong tab.

Do you mean "follow up in PHI55"?

I'm going to presume this is resolved by D18598 -- I updated T11767 with more plans and context for smoothing over the behavior, but I think it will no longer be disastrously bad. I'll follow up in PHI36 PHI55.

This doesn't affect us, but more fuel on the fire -- XSS in example code which ships with PHPMailer (we don't distribute this code):

A possibly exceptional case here is users who unsubscribe themselves. We could wait for complaints or special case that.

There's also bin/mail receive-test but that only accepts mail --to an existing object, not a random email address, right now. We could make that more flexible to make testing a little easier (raw_mail.txt must be a full piece of mail with proper headers and encoding, but bin/mail receive-test accepts just the plain text of a body and simulates all the headers/encoding/envelope stuff).

Something like:

I think I have a fix but can't find the command line trick you showed me to test it.

The easiest fix is probably to add a TYPE_CREATE transaction into ReplyHandler or MailReceiver alongside the other creation transactions.

I think that these use to exist and were moved to a help document somewhere.

What is the problem? What is wrong/not working?

I'm not sure I understand something:

I am running into this issue too and am on commits:

Oh, this doesn't isolate things because they're on different databases, and thus we establish different connections. The daemon insert does not happen inside a transaction.