421–430 of 443 posts
Earlier quoted context omitted.
[flagged]
Please don't cross into attacking another user, no matter how wrong they are or you feel they are. We're trying for something different here. (I know you know this and are not in the habit of doing it, but it bears repeating for others.) https://news.ycombinator.com/newsguidelines.html
Earlier quoted context omitted.
Per RFC2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. So, it's fairly explicit that the sender should use message-id unless there's a good reason to not do so. The spec is quiet about the recipients behavior…
Not a specification but "Be liberal in what you accept?" comes to mind. (which I always personally hated but i'm just one shoveler).
Earlier quoted context omitted.
It's not required but they need to understand the implications. In this case the implication is that Google drops the mail. So clearly they didn't understand the implications.
Yes, but this might be googles fault for not respecting/missinterpretating the spec.
Earlier quoted context omitted.
SHOULD is a requirement. It means that you have to do it unless you know some specific reason that the requirement doesn't apply in your case. "I don't want to" is not a valid excuse, "I don't see a reason to" isn't either. IIRC this particular rule is a SHOULD because MUAs often send messages without a Message-ID to their submission server, and the submission server adds one if necessary. https://www.rfc-editor.org/…
> SHOULD is a requirement. I once had a job where reading standards documents was my bread and butter. SHOULD is not a requirement. It is a recommendation. For requirements they use SHALL. My team was writing code that was safety related. Bad bugs could mean lives lost. We happily ignored a lot of SHOULDs and were open about it. We did it not because we had a good reason, but because it was convenient. We never justi…
> SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
To validly disregard a SHOULD, you need to (a) fully understand the implications, and (b) accept them.
Any time someone disregards a SHOULD and then complains about the result, they are necessarily in the wrong. Either they didn’t fully understand the implications, or they don’t actually accept them.
Earlier quoted context omitted.
I know you're looking for "pedant points" but the specification generally take a backseat to implementation. If Message-ID is expected out here where the rubber meets the road, then you are the squeaky wheel in this scenario for not including it.
> the specification generally take a backseat to implementation. And we should be raising hell for it. Should never happen. Using your popularity to violate protocol should be not be tolerated
Earlier quoted context omitted.
What comes to mind - You are sending a receipt and want table alignment for items - You want to put a logo of your company so that readers can recognize who's the email from - You want to make unsubscribe link smaller and the "open the thing I'm notifying you about" link bigger, so that people would know which one is which without reading the url - You want to add a header
Mostly those seems to be more about you as a sender wanting to do some branding or manipulation of the reader. I don't really see how it benefit the receiver, which should be the main concern of all communications.
Earlier quoted context omitted.
The email landed in the spam folder. A bounced email means it didn't find the inbox. If it didn't find an inbox there would be no log for him to check. Technical knowledge of emails and what the terms mean out him instantly as a liar. The fact this is still up on the front page is an embarrassment for the tech community in my opinion.
[flagged]
An email bouncing means it was rejected because it did not find an inbox or a recipient. You AI to question if that is true. So if the email service provider says we don't know who that belongs to, why would they provide logs.
And what email service provider is rejecting an email over a RFC thing when millions of emails a day because most devs don't care about the RFCs and only an idiot would have two different mail infrastructure and code versions running for gmail and workspaces. Especially on the sending and receiving part.
So are you going to apologies for being confidently wrong? Because I'm technically and confidently right. Again, which is why the hardcore nerds are leaving this the fuck alone because they saw me wreck the post in minutes of it being posted.
[flagged]
1. Email didn’t arrive in his inbox of his Google workspace 2. He checked workspace email logs (with admin you can do this on gsuite) 3. It showed the intentional non-accept 4. Comprehending the problem, he switched to personal Gmail 5. The email arrived 6. He informed the sender of the original problem which he worked around 7. Sender is tech-illiterate and did not realize what the problem is. This is common with fi…
> 2. He checked workspace email logs (with admin you can do this on gsuite)
But it didn't arrive, so how was it in his email logs!?!?!?! Are you tech literate? Isn't this the second time you've been asked or was I rate limited at that point?
Earlier quoted context omitted.
I had one who sent me the booking details of another client in the plaintext part. I reported it to them nearly a year ago and they didn't reply, so screw anonymity, it was Avis.
text/plain != plaintext This is about media types, not encryption.