That's unfortunate. I've mostly worked with sendmail, and I've never
seen a case where the QID wasn't sent back to the originating MTA, so
I wasn't aware that the RFCs don't require that behaviour.
Officially, everything after the "250 " is just ASCII text without any
specific format (that's not true for ALL SMTP messages, but it is true
for this one). And yes, sending the queue identifier is extremely common,
but like I said it's not a requirement (also, we use sendmail and we
don't have that specific format of the response code you have).
As a practical matter I've never had to give anyone the queue
identifier of a message (because it's not normally logged on the
client; really, most people are happy with recipients and a time, and
they are really happy if you have a message-id).
That doesn't match my experience.
I can say when I've done the searching, yes, I figure OUT the queue
identifier and use that for searching. But no one I've ever asked for
information for ever had any idea what the queue identifier was. And
when I've been asked for tracking information for email, no one has ever
asked me for the queue identifier.
I think this should be a lot more generic. So ... an alternate proposal.
[ details snipped for brevity, but the summary is be to create a
"post hook" and use that instead ]
I'd have no problem with that as long as the post hook provides the same
information gathered in my patch (i.e., sender and recipient addresses,
message ID, relay server and port, and resulting status and QID).
Just so I make it clear ... I'm not proposing writing this myself. I
think it would be worthwhile code to add, but if you want this I would
recommend you writing it yourself; my to-do list is kind of long. Now
if you want some help with that, I'd be glad to provide it (and I'd be
willing to write a test for it).
--Ken
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers