(Presuming this is resolved since it's been open for a while without feedback.)

This is likely just some of the secure hosts having different configuration. Ideally, we'd get the rCORE deployment stuff aligned to deploy them with it.

Any ideas on how we can move forward with this?

These CSS rules:

OK weird, I can't reproduce it anymore. Anyway, I'll add the response body from differential.querydiffs here. It shouldn't contain any sensitive information, but I'll restrict the visibility of the file given that it does contain email addresses.

(You can use T12270 to give feedback or report bugs on Badges, specifically)

Please read and follow Contributing Bug Reports. Also, we don't accept bug reports against prototype applications.

Yes, it is not "incorrect" but it is not human-readable format problem same with T8973 either. Chinese / Japanese / Korean unicode should be shown as what it is instead of some unreadable unicode digitals, especially in TRANSLATION functions, otherwise how to translate and confirm that?

Tried again with node v6.9.4 (current version of node with CentOS7), and still has same problem 😢

Happy to accept a patch for this (deleting that one line of code) if someone wants to claim that they tested the scenario above and it worked correctly.

This behavior is not "incorrect", it just isn't the most human-readable format we could use. I'm going to merge this into T8973, which discusses this and other potential improvements to human-readability for JSON encoded for presentation.

When I checked the source code I saw that the anchor tag was being applied
to the profile image, so I assumed that the link should be clickable only
inside the area of the profile image.

Why do you think its a bug?

Yes, I was referring to a small area around the hovercard which was clickable. Not a big issue, but just something I noticed the other day. 😄

Great, thank you!

After D17489 you should be able to do this:

Sounds reasonable to me.

Hrrm -- I can adjust bin/mail send-test to accept raw email addresses, and then you can use it to send a message to test+00001@gmail.com, test+00002@gmail.com and similar. Shouldn't be too involved.

Any suggestions to test this on staging without mass emailing everyone / patching prod? I am trying to test this on staging with bin/mail show-outbound --id xxxx (staging has mail disabled), but the recipients / To: list look fine with or without the patch.

I going guess the here is that a small margin around the area of the hovercard is clickable? Or maybe your using a browser that displays a more nefarious issue? In Chrome/Mac I can't reproduce anything unexpected or can't find anything I'm prevented in doing, like copying text from the hovercard. Hovercards are meant to be small bits of information, and then click through to the profile. I'm not sure what "bug" there is in having a larger click area.

What is the bug that you're reporting here?

Different parts of the repository page may or may not load indicating error. I refreshed on the page with the commit a few times and sometimes it says the commit is missing and other times it can't load the content, and other times it can't load the paths, but sometimes it can load them.

Thanks for the quick fix and the huge amount of detail under the hood, we'll give that patch a shot!

Internally, PHPMailer sends headers through two adjustment phases:

I know someone who has a normalname@domain.horse address and frequently finds services which won't accept it (since they're hard-coded for 3-letter TLDs) so I'd guess users with ={^_^}=@nekoneko.com addresses run into more frequent problems. We should handle .horse, .technology, etc., properly.

I am sure these email addresses are valid, but they are from people who run their own mailserver and can easily add a reasonable address for themselves, so I agree with your conclusion. More importantly, I want to thank you for your quick response, for phabricator, and your passion!

Can you test if this fixes the issue in your environment?

I think this is the controlling specification -- 2008 was a simpler time when no sequence of non-whitespace characters could ever be longer than 78 bytes, and a thousand bytes of memory was an untold wealth of riches:

I think the actual issue is that we're not wrapping the header. When I generate a synthetic message locally with a "To:" header with a length of ~50,000 bytes, the raw output is an unbroken line ~50,00 bytes long. I suspect this is RFC-violating and that whatever the mail gets handed to next gets upset by it.

Perfect, thanks!

The default -- PhabricatorMailImplementationPHPMailerLiteAdapter

What is metamta.mail-adapter set to?

See also T12046 for why all open source is sketchy voodoo and the eventual pathway forward here is likely replacing it with first-party code.

That is, the problem would be:

I guess we actually have to test this use case:

I can fix if it's one line, I just assumed it was something super hard with external urls or something.

I blame the fun police.

https://secure.phabricator.com/source/phabricator/browse/master/src/infrastructure/markup/PhabricatorMarkupEngine.php;4c7d464f8bf2627ef7455596fde2ae5667e67a57$356

Macros are disabled in Phame posts, via markup engine. This originated in D2202.

Ok, i'm an idiot.
I configured wrong endpoint.
It's working now.
Still, it might be good idea for mentioning this policy in install doc - it's not really obvious that you need

"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"

For IAM policy to work.

Probably worth mentioning that this creds are configured using IAM instead of root creds.
Policy for this user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::files.example.com",
                "arn:aws:s3:::files.example.com/*"
            ]
        }
    ]
}

I tried removing white space: nowrap; (from one of .phabricator-action-view button.phabricator-action-view-item, .phabricator-action-view-item) in the browser inspector on FF and it looks like it goes back to normal (even when expanding).

Yeah Chrome is fine as well.

I've followed the steps you listed above but am not able to reproduce the issue. Do you have more information you can give us on how to reproduce the bug? Without reproduction steps the upstream cannot move forward.

Thank you for the very thorough reply.
That's not a big deal and it certainly can wait!

In our case these are commits from landed Differential diffs. Permissions
for the web user are there and correct, but I'm not sure I understand all
the details around the daemon vs. web user, and the daemon is doing the
work for this git commit parser.

Thank you for your quick reaction (and sorry that I didn't reply sooner). I think a black color with a 1px black text-shadow looks better. The blue is confusing (it sort of looks like a link).
So I suggest:

.phui-document-view .phabricator-remarkup .remarkup-header strong {
  color: #000000;
  text-shadow: 0 0 1px #000000;
}

mkdir: cannot create directory ‘/var/storage/3f/49’: Permission denied

Occasionally, even after running the re-parse command, the basics of the commit will import but the content itself will not. A phd restart will almost immediately allow the commit to then import.

But other interfaces around Phabricator are not going to fair as well, just FYI.

Server side reduces this quite a bit: