Version?

I'm saying for you, not for me. Nevermind, I'm gathering that having verbal conversations isn't a priority for you guys and you don't see the value in it. No problem.

You already have all that in this public forum. We take feedback, feature requests, bug reports, have an open roadmap and design process - all for paying and non-paying customers.

Allow me to clarify: as a product manager I've found it incredibly useful to talk to both current paying customers as well as prospective paying customers and users of existing free products to learn about their needs and things that work well and don't work well in the spirit of improving our products. I find that qualitative conversations like this can be very useful, sometimes more useful than quantitative and written communication.

I understand your suggestion, but taking feedback over phone is just like the worst ever for us given customers outnumber us 1,000,000 to 1 or so. It's not scalable which is why we ask people to participate here.

I'm not sure I understand. You want Phacility to spend development resources to understand your needs as a non-paying customer? As a thank-you?

@epriestley we're actually not, we're a SaaS users of Phabricator, self-hosted (dev.doctor.com). We are indeed free installs, but my gut is that our needs are no different than those SaaS folks that pay you. I'm offering my time as a form of thank you for what you've offered for free, though :) if you're interested in talk to large-scale customers and learning what their needs are (and even what they might pay for, as an example).

@Taskle, if you're a Phacility SAAS customer can you ping me at support@phacility.com with your instance name? I can't immediately find it. We're working to formalize the SAAS/prioritization relationship a little better, but we can push more weight behind requests if they're coming from paying customers vs free self-installs.

Just wanted to chime in as a SaaS customer. :) We've been using Phab from a team of 15 to now we're about 100 people, and we use it for both our engineering teams as well as task management for our client services teams.

This also has SAAS customer interest.

In T12372#215275, @epriestley wrote:

Great, thanks for testing it! We'll upstream that and I'll file something to put a longer-term fix in place.

"witter.com" <fakeemailtest+163@t>

ah yes this is my very favorite email address of all

Great, thanks for testing it! We'll upstream that and I'll file something to put a longer-term fix in place.

Confirming that the patch above works (tested using send-test --to)!

Earlier, I predicted:

I think D17374 covered everything I wanted to cover.

We'll probably implement a Phabricator-side mute-this-thread in connection with T10448, I'm just guessing that some of the users complaining that GMail mute doesn't work won't consider clicking a link in the email body, then clicking "Mute Thread" to be an acceptable solution.

In T12240#211220, @epriestley wrote:

We could also implement "Mute Thread" in Phabricator, but I assume no one would be willing to click twice to mute a thread.

I'm pretty sure we can't generate our own Message-ID with Amazon SES, at least -- although we use the HTTP API, not the SMTP API, and maybe the rules differ. Not sure about other providers.

(dropped this since I don't have time to fully test, but I might come back to this in the future)

Possible followups from D17344:

Example: I disabled a bogus user when the "confirm your e-mail" MTA job was on its ~200th attempt. It's now at its ~240th attempt :)

Those seem to have been the magic words:

We could also implement "Mute Thread" in Phabricator, but I assume no one would be willing to click twice to mute a thread.

If we use SMTP envelope To, doesn't Alice potentially get multiple messages still (envelope "To: Alice", envelope "To: All-About-Alice@lists.company.com")? The list rewrites the envelope to go to all the list members, right? Or is there more magic there I don't know about?

One issue with one-mail-per-recipient is that gmail does not permit muting an email conversation if you are the only TO recipient.

In T12240#211112, @epriestley wrote:

To jump back further, the root-ier cause is that you're using mailing lists?

If we implemented T3980, could you create projects for mailing lists instead of "Mailing List" users, then do one-mail-per-recipient + private-replies and be generally OK?

(D17331 should fix the outdated discussion of the option in Config.)

I imagine that the rest of the process will work like this:

AWS got back to me with essentially a form response that didn't address any of the particulars of our case.

Sometimes people will "Reply All" and everyone will get two mails, one from the user and one from Phabricator turning their mail into a comment.

To jump back further, the root-ier cause is that you're using mailing lists?

In T12240#211108, @epriestley wrote:

Oh, I didn't even realize that was a thing. I assumed SMTP went like "okay here is a message: <message body>".

I don't think we have control over the SMTP envelope for at least some of of the APIs we implement, although perhaps I'm mistaken. In some cases I chose the non-SMTP version of things (e.g., POST some JSON) when an SMTP version was available since I mostly know how JSON works but do not mostly know how SMTP works. It's possible we could revisit those decisions and do more SMTP to get greater access to envelopes, although I'd guess not all adapters provide us envelope access.

Some more thoughts: even if we can't control the Reply-to in all cases, phabricator can look at the TO header and perhaps choose not to send mail if it looks like it was already sent to a given user.

We already attempt to do this -- are you seeing it not work in practice? Rough pathway is:

Oh, I didn't even realize that was a thing. I assumed SMTP went like "okay here is a message: <message body>".

Some more thoughts: even if we can't control the Reply-to in all cases, phabricator can look at the TO header and perhaps choose not to send mail if it looks like it was already sent to a given user. Of course, given the above, this is spoofable.

Unless I'm missing something, I think the instructions here cause X to receive two mails (they are on "To" for both).

Or, more generally, if we send two mails:

• We no longer send normal mail to unverified addresses. Consequently, mail sent between creating an account and that user verifying their address (for example, assigning them tasks) is now dropped.
• We no longer send "sorry, we ignored your mail because we don't recognize the address" replies if we don't recognize the sender, unless phabricator.allow-email-users is set.
  • I would like to eventually (post-Nuance?) remove this option, stop allowing "email users", and move away from "grey users".
• We no longer send a misleading error about "no default user" if an application address is not configured with a default user.
• This install now delivers outbound mail through Mailgun instead of SES.
• The queued backlog appears to have flushed.

• I think this sends the recipients many copies of the email, particularly if they are on mailing lists? Why do you believe that users will receive only one copy of the mail if we send ten messages with their address in "To"?
• Are you sure "Reply-To" overrides "Reply All" in all major clients? I haven't tested this personally, but I can't immediately find any references to this behavior on Google. I believe we already use "Reply-To", so I would expect "Reply All" to already be a non-problem if "Reply-To" overrode it. My pre-existing belief was that "Reply-To" replaced only "From", not the entire recipient list, under "Reply All".

A sub-issue here is that we're bouncing a lot of email like this, for an exciting product called "Penisole" from reputable domain "bloggay.com":

Add some kind of notification to user accounts like "some email you would have been sent was dropped because you haven't verified your address yet"?

My plan here is:

My guess is that this is just something dumb and mostly out of our control, and we fell through the cracks because the email volume we send from this install is tiny. We sent 41,877 messages in January at a cost of $0.00 -- this is too few messages to even qualify for charges, which start once you send 2,000 messages in a single day.

The changelog from Mailchimp (opt-in only) is from noreply@phacility.com, but I can't think of anything else off the top of my head

In T12237#211025, @epriestley wrote:

Although I'm somewhat confused by this because it came to the address for my personal AWS account.

I appealed this, but the FAQ says "Due to the way spamtrap sending is reported, it will take a minimum of three weeks before we can confirm that a fix you have put in place has succeeded.".

@chad, just to make sure my ducks are in a row, you aren't using noreply@phabricator.com in association with any marketing mail, right? I don't want to claim "we only send transactional mail" if that isn't true.

SES is definitely rejecting mail, though:

Although I'm somewhat confused by this because it came to the address for my personal AWS account.

I'm just going to merge this into T10448, this task doesn't have anything not already covered there.

Patch attached which addresses this - filter and object selection done on a new getToOrCCAddresses call. This patch is based off stable branch commit 58375fa9e6db4a389fd6029ee1ad14ddb0dc9e90.

libcurl supports SMTP (see https://curl.haxx.se/libcurl/c/smtp-mail.html) and can be used instead, provided that the relevant functions are exposed to PHP. This avoids needing to shell out to an external executable.

From a cursory read of CVE-2016-10045, it seems like PHP may be written in such a way that mail() can not be invoked safely. Silly PHP!

updated advisory; https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10045-Vuln-Patch-Bypass.html
I don't think this changes the plan you suggest, just linking for completeness.

This appears to be the fix:

Note that there is a Sender-related RCE in PHPMailer until Dec 2016, see T12046 for discussion.

This got done at some point, I believe, since we have an SPF record now.

Thansk

I think this is fixed now (config change on the Mailgun upstream side). Let me know if you're still seeing issues.

Test v4