Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Major European payment processor can't send email to Google Workspace users

atha.io

Post reply on HN
Print view View original

391–400 of 443 posts

Re: Major European payment processor can't send email to Google Workspace users

#391

Post by bmn__ »

s17n wrote: post #94
st_goliath wrote: post #9

> Viva.com's outgoing verification emails lack a Message-ID header, a requirement that has been part of the Internet Message Format specification (RFC 5322) since 2008 > ... > `Message-ID` is one of the most basic required headers in email. Section 3.6. of the RFC in question ( https://www.rfc-editor.org/rfc/rfc5322.html ) says: +----------------+--------+------------+----------------------------+ | Field | Min | Max…

The reason that European tech sucks is that people in Europe are open to such arguments. If an engineer in the US started talking about SHOULD vs MUST, some PM would just give them that "what the fuck did I just listen to" face, spend the next few minutes gently trying to convince them that the customer experience matters more than the spec, and if they fail, escalate and get the decision they want. For example, why…

> some PM would just give them that "what the fuck did I just listen to" face

Some people have become way too comfortable taking for granted that it is okay to treat others in an uncivil fashion. To those I say: keep it up, and we shall revert to the fundamentals of society where violence is an option and one day you are copping punches in the face, or getting shackled and thrown in a ditch somewhere for the ravens. Behave like an animal, get treated like one.

Re: Major European payment processor can't send email to Google Workspace users

#392

Post by MonstraG »

mrweasel wrote: post #357
saurik wrote: post #12

My pet peeve are services that go out of their way to include a text/plain alternative message part but send something useless, such as the message without the key link. One time I seriously ran into a service just send a short one-sentence note along the lines of "this is a plain text email" as the plain text part. If you don't want to support plain text, maybe just don't send the alternative part?

This might be me being old, but I still don't understand why html emails aren't the exception. If you want to do a fancy newsletter, trying to sell me crap, I can see why you'd need the images, the css and html. In most other cases, I don't really get the point.

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

Re: Major European payment processor can't send email to Google Workspace users

#393

Post by Arnt »

roenxi wrote: post #388
nerdsniper wrote: post #312

Earlier quoted context omitted.

> the full implications must be understood and carefully weighed before choosing a different course. In this case, the full implication is that your email might be undeliverable. "Should" indicates that the consequences for this fall on the entity that is deviating from the thing they "should" be doing.

But the RFC language clearly anticipates there are situations and good reasons leading to a message that does not include a message-id. Google therefore would be rejecting RFC-compliant emails, and they are the ones who have to justify themselves. Theoretically, anyway, I expect in practice they'll just ignore the issue or have their own good reason. But they should accept emails with no message-id; there it does str…

There are indeed such situations. Two situations AFAICR, and neither of them apply to when you connect to someone else's MX.

Gmail rejects the vast majority of compliant messages, I think they've stated in public that they reject >99.9% of messages, and hearsay has it that the percentage for with minor errors like this is even higher.

There are good reasons why a message might be unreadable. For example, message-id is often used by the threading algorithms in MUAs and IMAP servers, and many don't test whether their threading code handles ID-less messages. I use one that deduplicates by ID, what do you think it does when the ID is empty or missing? I don't know, I haven't tested and I'm not going to.

Re: Major European payment processor can't send email to Google Workspace users

#394

Post by Arnt »

BeetleB wrote: post #244
Arnt wrote: post #142

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…

FYI slightly over 10% of RFCs contain at least one occurrence of SHALL. Even that small minority uses other words for most requirements.

Re: Major European payment processor can't send email to Google Workspace users

#395

Post by Foobar8568 »

BeetleB wrote: post #244
Arnt wrote: post #142

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…

Could was yeah nice to have. Should, was yeah the system shall have it, but it's ok if not. Shall : ffs we will hunt you and kill you if you don't implement it.

Re: Major European payment processor can't send email to Google Workspace users

#397

Post by mrweasel »

MonstraG wrote: post #392
mrweasel wrote: post #357

Earlier quoted context omitted.

This might be me being old, but I still don't understand why html emails aren't the exception. If you want to do a fancy newsletter, trying to sell me crap, I can see why you'd need the images, the css and html. In most other cases, I don't really get the point.

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.

Re: Major European payment processor can't send email to Google Workspace users

#398

Post by philipallstar »

dathinab wrote: post #304
philipallstar wrote: post #169

Earlier quoted context omitted.

As indicated in the RFC, it uses another RFC[0] to define those words. Here's the relevant excerpt from that one: 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. [0] https://www.rfc-editor.org/rfc/rfc2119

yeah, but that RFC isn't the only relevant document Mail RFCs do not cover at all spam detection and malicious mail rejection, but it's a thing every large mail provider has and you really have to care about when producing automated mails all looking similar. And large mail providers like google tend to document what "base line" of additional requirements they have for accepting (automated mail). Having a Message-Id…

I think the question for the sender is: do I have a good enough reason to reject the SHOULD requirement? If not, then I should implement it.

Re: Major European payment processor can't send email to Google Workspace users

#399

Post by Arnt »

Dylan16807 wrote: post #374
strken wrote: post #303

Earlier quoted context omitted.

Pulling exact quotes out, SHOULD means "there may exist valid reasons in particular circumstances to ignore a particular item" while MAY means "an item is truly optional." I don't think this can be interpreted as simply "should is optional".

They're both optional, but one comes attached to a big warning message.

Well… yes… no… SHOULD means that you must either do the thing or understand the consequences of not doing it. That's not simply optional, the two options are to ① spend time on writing code and ② spend time on learning the consequences. Either way you need to think hard and spend time. And that's why the definition of SHOULD includes the word "must".

Re: Major European payment processor can't send email to Google Workspace users

#400

Post by 5o1ecist »

Arnt wrote: post #142
st_goliath wrote: post #9

> Viva.com's outgoing verification emails lack a Message-ID header, a requirement that has been part of the Internet Message Format specification (RFC 5322) since 2008 > ... > `Message-ID` is one of the most basic required headers in email. Section 3.6. of the RFC in question ( https://www.rfc-editor.org/rfc/rfc5322.html ) says: +----------------+--------+------------+----------------------------+ | Field | Min | Max…

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/…

[flagged]
Post reply on HN