3 ms·

From what I gathered from the article, the input WAS valid. It's the software that was unable to handle a specific case of valid input.

• jacquesm 3y ago
  That's fine, and is exactly the kind of case that I was thinking of: your software has a different idea of what is valid than an upstream piece of software, so from your perspective it is invalid. So you need to pull this message out of the stream, sideline it so it can be looked at by someone qualified enough to make the call of what's the case (because it could well be either way) and processing for all other messages should continue as normal. After all the only reason you can say with confidence that it in fact was valid is because someone looked at it! You can only do that well after the fact. A message switch [1] that I worked on had to deal with messages sources from 100's of different parties and while in principle everybody was working from the same spec (CCITT [2]) every day some malformed messages would land in the 'error' queue. Usually the problem was on the side of the sender, but sometimes (fortunately rarely) it wasn't and then the software would be improved to be able to handle that case correctly as well. Given the size of the specs and the many variations on the protocols it wasn't weird at all to see parties get confused. What's surprising is that it happens as rarely as it does. The big takeaway here should be that even if something happens very rarely it should still not result in a massive cascade, the system should handle this gracefully. [1] https://www.kvsa.nl/en/ https://www.kvsa.nl/en/ [2] https://en.wikipedia.org/wiki/Group_4_compression https://en.wikipedia.org/wiki/Group_4_compression
  • dboreham 3y ago
    Exact same experience developing systems that process RFC-822 (and descendents) email messages.