man Qpsmtpd::DSN (3): RFC 1893

DESCRIPTION

The Qpsmtpd::DSN implements the Enhanced Mail System Status Codes from RFC 1893.

USAGE

Any qpsmtpd plugin can access these status codes. All sub routines are used the same way:
use Qpsmtpd::DSN;
...;
return Qpsmtpd::DSN->relaying_denied();

 return Qpsmtpd::DSN->relaying_denied("Relaying from $ip denied");

 return Qpsmtpd::DSN->relaying_denied(DENY,"Relaying from $ip denied");

If no status message was given, it will use the predefined one from the RFC. If the first argument is numeric, it will use this as a return code, else the default return code is used. See below which default return code is used in the different functions.

The first example will return (DENY, ``Relaying denied''); the others (DENY, ``Relaying from $ip denied''); which will be returned to qpsmtpd.

In those sub routines which don't start with addr_, sys_, net_, proto_, media_, sec_ I've added a default message which describes the status better than the RFC message.

ADDRESS STATUS

addr_unspecified: X.1.0 default: DENYSOFT
no_such_user, addr_bad_dest_mbox: X.1.1 default: DENY
addr_bad_dest_system: X.1.2 default: DENY
addr_bad_dest_syntax: X.1.3 default: DENY
addr_dest_ambigous: X.1.4 default: DENYSOFT
addr_rcpt_ok: X.1.5 default: OK
addr_mbox_moved: X.1.6 default: DENY
addr_bad_from_syntax: X.1.7 default: DENY
addr_bad_from_system: X.1.8 default: DENY

MAILBOX STATUS

mbox_unspecified: X.2.0 default: DENYSOFT
mbox_disabled: X.2.1 default: DENY ...but RFC says:
   The mailbox exists, but is not accepting messages.  This may
   be a permanent error if the mailbox will never be re-enabled
   or a transient error if the mailbox is only temporarily
   disabled.
mbox_full: X.2.2 default: DENYSOFT
mbox_msg_too_long: X.2.3 default: DENY
mbox_list_expansion_problem: X.2.4 default: DENYSOFT

MAIL SYSTEM STATUS

sys_unspecified: X.3.0 default: DENYSOFT
sys_disk_full: X.3.1 default: DENYSOFT
sys_not_accepting_mail: X.3.2 default: DENYSOFT
sys_not_supported: X.3.3 default: DENYSOFT
          Selected features specified for the message are not
          supported by the destination system.  This can occur in
          gateways when features from one domain cannot be mapped onto
          the supported feature in another.
sys_msg_too_big: X.3.4 default DENY

NETWORK AND ROUTING STATUS

net_unspecified: X.4.0 default: DENYSOFT
net_directory_server_failed, temp_resolver_failed: X.4.3 default: DENYSOFT
net_system_congested: X.4.5 default: DENYSOFT
net_routing_loop, too_many_hops: X.4.6 default: DENY, but RFC says:
  A routing loop caused the message to be forwarded too many
  times, either because of incorrect routing tables or a user
  forwarding loop. This is useful only as a persistent
  transient error.
Why do we want to DENYSOFT something like this?

MAIL DELIVERY PROTOCOL STATUS

proto_unspecified: X.5.0 default: DENYSOFT
proto_invalid_command: X.5.1 default: DENY
proto_syntax_error: X.5.2 default: DENY
proto_rcpt_list_too_long, too_many_rcpts: X.5.3 default: DENYSOFT
proto_invalid_cmd_args: X.5.4 default: DENY
proto_wrong_version: X.5.5 default: DENYSOFT

MESSAGE CONTENT OR MESSAGE MEDIA STATUS

media_unspecified: X.6.0 default: DENYSOFT
media_unsupported: X.6.1 default: DENY
media_conv_prohibited: X.6.2 default: DENY
media_conv_unsupported: X.6.3 default: DENYSOFT
media_conv_lossy: X.6.4 default: DENYSOFT

SECURITY OR POLICY STATUS

sec_unspecified: X.7.0 default: DENYSOFT
sec_sender_unauthorized, bad_sender_ip, relaying_denied: X.7.1 default: DENY
sec_list_dest_prohibited: X.7.2 default: DENY
sec_conv_failed: X.7.3 default: DENY
sec_feature_unsupported: X.7.4 default: DENY
sec_crypto_failure: X.7.5 default: DENY
sec_crypto_algorithm_unsupported: X.7.6 default: DENYSOFT
sec_msg_integrity_failure: X.7.7 default: DENY