On 2022-07-23 at 09:08:17 UTC-0400 (Sat, 23 Jul 2022 15:08:17 +0200)
Jaroslaw Rafa via mailop <r...@rafa.eu.org>
is rumored to have said:
Dnia 23.07.2022 o godz. 15:25:43 Atro Tossavainen via mailop pisze:
Ideally, a SMTP return code should differentiate the reason for
rejection.
There should be a different code for non-existing user, technical
problems
(like mailbox full) or policy-based reject.
You know, they actually did think of that.
https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.3
https://datatracker.ietf.org/doc/html/rfc3463#page-14
I meant if the mail servers were actually *using* it...
The mail servers acting as MXs for the overwhelming majority of active
addresses all send extended codes in 4xx and 5xx replies.
Whether they are differentiated usefully varies. e.g. virtually all
rejections at end-of-data sent by the systems I manage are '554 5.7.1'
which has a clear but very non-specific meaning: a policy violation. In
the case of my systems, all of those rejections are based on content
filtering, because all other policy criteria that might reject a message
are applied at RCPT and/or (rarely) the initial DATA reply.
It has been said in other mails in this thread that there is often the
case
that the same code is returned for all kinds of rejections...
I think it is not correct to say 'all' kinds. It is true that formally
defined basic reply codes at each SMTP stage are restricted, so
well-behaved receivers will always use one of the legal basic codes, but
as enhanced codes are formally part of the free-form 'text' of the reply
as seen by the SMTP specs, they can be more varied. They can also be
very generic, if that's what the admin wants.
I have heard that complaint from senders when they ACTUALLY mean that
the basic reply code is always 550 or 554 depending on the stage, and
that they don't want to do the work of figuring out how to handle the
differences between the possible extended codes. It is useful for an ESP
to view their failure handling as being as good as it can get, as that
avoids making it better. Their return on the investment of developing
better bounce handling is not good.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
