RCPT TO extensions not implemented

[rhbvkleef]

Refer to DSN recipient extensions.

https://www.lifewire.com/what-is-dsn-delivery-status-notification-for-smtp-email-3860942

[mworrell]

Maybe you can sketch a possible way to enable the bounce emails?
Currently we only return the error and do not send any bounces.

That is currently up to the party sending us the email, and interpreting the status messages.

Can you describe your use case?

[mworrell]

Or... maybe you are referring to the gen_smtp_client?

[juhlig]

Just my two cents :)

For one, RFC 3461 describing DSNs is probably more enlightening here than the link the OP provided.

I'm not a huge fan of the DSN extension. It may be useful for debugging a client's delivery issues, but it places a burden on servers in that they must then also manage the creation and delivery of the DSNs. Plus, to be RFC compliant, it must send all the DSNs a client asks for, ie it cannot decide to only send failure DSNs and not success DSNs, otherwise it would violate the RFC.

To get a DSN-enabled client, it must (should?) be able to issue the RET and ENVID extensions to the MAIL FROM command, and the NOTIFY and ORCPT extensions to the RCPT TO command, given that the server supports the ESMTP DSN extension.

To get a DSN-enabled server, it must announce the DSN extension in the reply to the EHLO command, accept and understand the above command extensions, and act accordingly when it deposits the message in a local mailbox or relays it further.