It all started with a routine delivery attempt to my sinkhole SMTP server that I use as a spamtrap:

remote 165.227.10.85:36462 at 2017-07-03 13:30:28
220 This server does not deliver email.
EHLO mail.travelshopnews7.com
[...]
MAIL FROM:<newsletter@travelshopnews7.com>
250 Okay, I'll believe you for now
RCPT TO:<redacted@redacted>
250 Okay, I'll believe you for now
DATA
354 Send away
[...]
. <end of data>
554 Rejected with ID 433b5458d9d3e8a93020aca44406d2ec1d8ba82a
QUIT
221 Goodbye

That ID is the hash of the whole message and its important envelope information (including the sending IP). So far, so normal, and these people stood out in a good way by actually QUITing instead of just dropping the connection. But then:

remote 165.227.10.85:39084 at 2017-07-03 13:37:10
220 This server does not deliver email.
EHLO mail.travelshopnews7.com
[...]
554 Rejected with ID 433b5458d9d3e8a93020aca44406d2ec1d8ba82a

They re-delivered the exact same message again. And again. And again. In less than 24 hours (up to July 4th at 9:28 am) they did 21 deliveries, despite getting a permanent refusal after each DATA. At that point I got tired of logging repeated deliveries for the same message and put them in a category of earlier blocks:

remote 165.227.10.85:50676 at 2017-07-04 10:38:10
220 This server does not deliver email.
EHLO mail.travelshopnews7.com
[...]
MAIL FROM:<newsletter@travelshopnews7.com>
550 Bad address
RCPT TO:<redacted@redacted>
503 Out of sequence command
[...]

You can guess what happened next:

remote 165.227.10.85:34094 at 2017-07-04 11:48:36
220 This server does not deliver email.
EHLO mail.travelshopnews7.com
[...]
MAIL FROM:<newsletter@travelshopnews7.com>
550 Bad address
RCPT TO:<redacted@redacted>
503 Out of sequence command
[...]

They didn't stop there, of course.

remote 165.227.10.85:53824 at 2017-07-13 15:37:31
220 This server does not deliver email.
EHLO mail.travelshopnews7.com
[...]
MAIL FROM:<newsletter@travelshopnews7.com>
550 Bad address
RCPT TO:<redacted@redacted>
503 Out of sequence command
[...]

Out of curiosity I switched things over so that I'd capture their message again and it turns out that they're still sending, although they've now switched over to trying to deliver a different message. Apparently they do have some sort of delivery expiry, presumably based purely on the message's age and totally ignoring SMTP status codes.

(As before they're still re-delivering their new message despite the post-DATA permanent rejection; so far, it's been two more deliveries of the exact same message.)

These people are not completely ignoring SMTP status codes, because they know that they didn't deliver the message so they'll try again. Well, I suppose they could be slamming everyone with dozens or hundreds of copies of every message even when the first copy was successfully delivered, but I don't believe they'd be that bad. This may be an optimistic assumption.

(Based on what shows up on www.<domain>, they appear to be running something called 'nuevoMailer v.6.5'. The program's website claims that it's 'a self-hosted email marketing software for managing mailing lists, sending email campaigns and following up with autoresponders and triggers'. I expect that their view of 'managing mailing lists' does not include 'respecting SMTP permanent failures' and is more about, say, conveniently importing massive lists of email addresses through a nice web GUI.)