Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Delivery Status Notification requests #41

Open
gwire opened this issue Dec 24, 2021 · 3 comments
Open

Support for Delivery Status Notification requests #41

gwire opened this issue Dec 24, 2021 · 3 comments
Labels
enhancement New functionality slated to be implemented someday

Comments

@gwire
Copy link

gwire commented Dec 24, 2021

I would be good if swaks could generate test DSN (RFC 3461) notification responses.

As a minimal feature, it would be useful to be able to request a response based on one or more of failure, delay, or success. eg

swaks --to [email protected] --dsn-notify=failure,delay,success

Then, if DSN is advertised after EHLO

<-  250-DSN

the RCPT TO: command has a NOTIFY= option appended to it.

 -> RCPT TO:<[email protected]> NOTIFY=FAILURE,DELAY,SUCCESS
@fm
Copy link

fm commented Aug 10, 2023

I would love this as well, I was about to email @jetmore to see if it was possible, until I found this issue

@jetmore jetmore added the enhancement New functionality slated to be implemented someday label Nov 5, 2023
@jetmore jetmore added this to the backlog-feature milestone Nov 13, 2023
@georglauterbach
Copy link

Chiming in here as one of the core maintainers of docker-mailserver/docker-mailserver.

I am currently refactoring our test suite to move away from nc to swaks. For our DSN tests, this is required. Support for DSN would be awesome.

@polarathene
Copy link

Is --dsn-notify sufficient? Or is the request to only support a portion of the DSN extension? (NOTIFY parameter, which is what everyone here is interested in?)

  • A library that implements support for this lettre (Rust) handles the RCPT command with support for multiple RCPT parameters.
  • Looking at RFC 3461, there is more than just NOTIFY parameter for implementing the DSN extension.

Chiming in here as one of the core maintainers of docker-mailserver/docker-mailserver.

We now use swaks where possible. Thanks for such a great project, it really helped simplify our tests! 😁

For reference here is our test for DSN support (PR that introduced it) in docker-mailserver / DMS.

Reference

This is not necessary to know, but provides information/links regarding the test for better grokking what we're doing under the hood through convenience methods.

Collapsed as probably not relevant

The test presently handles sending these mails via netcat / nc (here is the _nc_wrapper() function):

_nc_wrapper 'emails/nc_raw/dsn/unauthenticated'
_nc_wrapper 'emails/nc_raw/dsn/authenticated' '0.0.0.0 465'
_nc_wrapper 'emails/nc_raw/dsn/authenticated' '0.0.0.0 587'

Where the two files referenced are [dsn/unauthenticated.txt](https://github.com/docker-mailserver/docker-mailserver/blob/25c7024cc4c7a6ee81be70144f6ecaf4fddf44ca/test/files/emails/nc_raw/dsn/unauthenticated.txt) and [dsn/authenticated.txt](https://github.com/docker-mailserver/docker-mailserver/blob/25c7024cc4c7a6ee81be70144f6ecaf4fddf44ca/test/files/emails/nc_raw/dsn/authenticated.txt).

We now have swaks used in most tests which is called via our _send_email() method.

Adapting test for swaks

Our _send_email() method will call swaks with some defaults, so the above _nc_wrapper snippet would only need to be changed to (or whatever equivalent --dsn-notify would use):

# Send a test mail to ports 25, 465, 587
_send_email --port 25 --dsn-notify=success,failure

_send_email --port 465 \
  --dsn-notify=success,failure \
  --auth-user [email protected] \
  --auth-password mypassword

_send_email --port 587 \
  --dsn-notify=success,failure \
  --auth-user [email protected] \
  --auth-password mypassword

To run the test, we have documentation here but is roughly:

# Requires these already installed: docker, jq, make, parallel

# Clone DMS repo and pull in the BATS testing submodule:
git clone --recurse-submodules --depth 1 https://github.com/docker-mailserver/docker-mailserver

# Run specific test (dsn.bats):
make clean generate-accounts test/dsn

Presently the Docker image will be built (Debian base) and installs swaks via the package manager in a shell script. You can modify that script file to add your unreleased swaks version, or if you're comfortable with Docker and only need to copy a local file into the image add a COPY instruction in the Dockerfile.


Testing with DMS

You seem to have your own test-suite but if it helps implement this feature more easily, DMS can quickly / easily provide a mail server for testing (Postfix, Dovecot, etc):

  • Running with DSN configured (ports 465 and 587 offer it, port 25 disables by default).
  • Just need docker installed.
# Run DMS:
# PERMIT_DOCKER=container relaxes some security checks (eg: DNS related)
docker run --rm -it -d \
  --hostname mail.example.test \
  --name dms \
  --env PERMIT_DOCKER=container \
  mailserver/docker-mailserver

# Add a user account:
docker exec -it dms setup email add [email protected] bad-password

# For convenience, add your WIP swaks release into the running container:
docker cp /path/to/local/swaks dms:/path/in/container/swaks

# Run that copied over swaks within the container:
# NOTE: DMS defaults only enable DSN on submission(s) ports for authenticated users.
docker exec -it dms /path/in/container/swaks \
  --dsn-notify=success,failure \
  --protocol SSMTPA \
  --auth-user [email protected] \
  --auth-password bad-password
  --server 0.0.0.0

# If you need shell access within the container just use:
docker exec -it dms bash

# When you're done bring the container down (--rm from `docker run` will handle cleanup):
docker stop dms

We'll soon be adding a feature that would allow for testing #44 too if that interests you (SMTP Auth through Postfix delegates to Dovecot which handles XOAUTH support).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New functionality slated to be implemented someday
Projects
None yet
Development

No branches or pull requests

5 participants