/mail/ will tell you why you received any given mail.

Do you have custom fields or custom forms?

Yes, both. I don't see how either of those could be involved with a column change, though, could it? Changes to our custom field do show on the timeline, too, but nothing is showing here.

There might be some crazy edge case of empty custom field that was previously hidden in a custom form and is being initialized for the first time, but not generating a visible transaction, so is getting lumped under "other". Hard to say, I can't really recreate how this might happen. Do you have "other" email sent to "on" but everything else "off" ? Knowing those would be important in a reproduction case as well.

Initialisation doesn't seem to fit the pattern, as I would have expected an earlier column change to trigger it if that would. There are also over a dozen transactions on the timeline of this task before the section I pasted here, including comments (one deleted; I wonder if that's relevant), column changes, reassignments, and status changes.

And yes, I do have "other" email turned on, so it makes perfect sense for me to receive notifications about "other" transactions. So I guess part of the bug is identified: "other" transactions are tagged and thus the email sent even if the transaction isn't visible.

But to be able to reproduce it, we kinda need to know what the "other" transaction actually was, don't we?

OK. The type of the other transaction is subpriority. From the database:

             id: 9641
           phid: PHID-XACT-TASK-th2fmuxardoypm2
     authorPHID: PHID-USER-55zwskc2gpy2olvlwnjf
     objectPHID: PHID-TASK-fx32td737asu3gpgyi3c
     viewPolicy: public
     editPolicy: PHID-USER-55zwskc2gpy2olvlwnjf
    commentPHID: NULL
 commentVersion: 0
transactionType: subpriority
       oldValue: "0.0077892676007758"
       newValue: 0.0057832296190288
  contentSource: {"source":"web","params":[]}
       metadata: []
    dateCreated: 1478664574
   dateModified: 1478664574

This transaction shares the same creation and modification date as the column change. I guess the 'subpriority' is used to maintain the task order on the workboard, so this probably means the task was dragged from one column to another (rather than using the 'Move to Column' action). It may only be relevant if the workboard is set to order by priority, rather than natural. This fits with my experience, as most incorrectly sent mail is about column changes, and I have seen an increase in such mail correlating with an increase in dragging tasks on our workboards.

I'll see if I can reproduce it on a clean install.

Hmm yeah, we record where in the workboard card is in the list, sticky. We could probably ignore that transaction.

Related thought: I wonder how the sticky task order fares when a task is on multiple workboards; since the subpriority seems to be a task parameter, not a workboard card parameter, I guess moving it on one workboard may clobber its position on another; quite possibly not a problem in practice.

Re scenario 1, I found another way to investigate it rather than digging up old logs. Question, though: is Phab supposed to send email to users who are unverified? Looking at mail logs, it seems one of our most recently added users was sent quite a lot of mail, perhaps all mail they would ordinarily get, prior to verification. If Phab is supposed to send mail to unverified users, then this would be an enhancement request which I could submit with a proper description of the use case. If not, I can investigate how to reproduce the behaviour.

is Phab supposed to send email to users who are unverified?

Yes.

Disabled users do not receive mail, but unverified users (and unapproved users) do.

https://secure.phabricator.com/diffusion/P/browse/master/src/applications/metamta/query/PhabricatorMetaMTAActorQuery.php;ff677c1964b15d61cf9a4ddd727c1da97b63fe00$51-94

At a minimum, we need to send unverified users verification email.

Thanks for that confirmation. I like the look of your code comment: "Possibly we should white-list this kind of mail and deny all other types of mail." I'll create an enhancement request task related to that.

We should restrict this bug report to addressing scenario 2.

Dragging a card on a workboard while in a priority-ordered view changes the global priority (see T8135). Mail tags in "other" groups are arbitrary, unclear, and going away (see T10448). I'm going to merge this into T10448.