🚀 go-pugleaf

I like [a] better (give an SMTP error rather than accept a piece of mail for
later rejection).  If you're most interested in tolerating a system that doesn't
interpret your error codes, maybe you can narrow how you read the specification
so that the error code you generate will be one that the remote system will
interpret the way you want (as a permanent error).  If the system in question
won't interpret anything as a permanent error, this mechanism won't help much.

One of the good reasons for preferring [a] when possible is that it gives faster
error turnaround to the user, not to mention causing less overhead for your
system because it doesn't have to handle composition, enqueueing, and delivery
of the error message piece of mail.  The significant reason for preferring [b],
other than the reason you give of confused SMTP-user ends, is that if you always
accept mail for later delivery, the SMTP-user end doesn't have to wait around
while you check for the permanent-failure condition in question.

                Craig Everhart