Allow Haraka-generated emails to be routed as normal

[AprilGrimoire]

• [√] I already searched past issues
• [√] I already checked the wiki/TODO page

Is your feature request related to a problem? Please describe.

I am implementing a plugin that mimics the behavior of major email providers that maintain a Sent folder of sent emails (even though on those providers this might not be an IMAP mailbox but an ad-hoc folder on the web page). Sometimes tools don't place a copy in Sent via IMAP nor Bcc the sender, and I think it is a good idea to have a full record of sent mails maintained by Haraka.

It works by creating a duplication of submitted mails, which is tagged with a header flag and enveloped to the sender. Then a sieve on the sender's mailbox places it into a special mailbox (for example, ServerSent).

Now it mostly works, however the duplicated mails (via send_email) don't get delivered via LMTP. I tried to modify haraka-plugin-dovecot to hook onto pre_send_trans_email, however this isn't easy because there aren't per-recipient hooks for Haraka-generated mails.

Describe the solution you'd like

Add option to allow Haraka-generated emails to go through a similar path as inbound emails

Describe alternatives you've considered

Add per-recipient hooks dedicated for Haraka-generated emails (like pre_send_trans_email)

Currently I'm trying to workaround this issue by letting Haraka deliver the mail to itself via SMTP.

Additional context

[msimerson]

You can tell outbound to queue emails via outbound's queue.wants mechanism. For example, if you want the dovecot plugin to enqueue the message, you'd set queue.wants=dovecot. Of course, the plugin needs to have queue hooks populated. There are included haraka plugins that provide this and there's also the mongodb and wildduck plugins.

You can also specify exactly where (via a URI) a delivery should be made by setting an explicit queue.next_hop, eg: queue.next_hop=lmtp://....:26

[AprilGrimoire]

Yes, but that'll limit the usability of this plugin for other potential users. Now I've got it to work with SMTP loopback.

What's the standard for submitting a plugin to the 'known plugins' list? Does it need to be sufficiently tested? Given that it interacts with many moving parts, I have no idea how to properly test it.

[msimerson]

Yes, but that'll limit the usability of this plugin for other potential users.

Will it?

What's the standard for submitting a plugin to the 'known plugins' list? Does it need to be sufficiently tested? Given that it interacts with many moving parts, I have no idea how to properly test it.

Create a PR that adds it. Make sure the link works. It's hard for plugins to have end-to-end / functional tests but it's straight forward to have unit tests that verify your functions at least mostly do what you expect.

Matt

[AprilGrimoire]

Yes, but that'll limit the usability of this plugin for other potential users.

Will it?

What if other users are not using dovecot, or are using other methods than lmtp (for example, piping) to deliver mails locally?

[AprilGrimoire]

I see other plugins (for example haraka-plugin-dovecot, which I'm submitting a pull request for) also don't have unit tests. Can you provide a good example for me to follow?

[msimerson]

What if other users are not using dovecot, or are using other methods than lmtp (for example, piping) to deliver mails locally?

I wouldn't worry about that. Let actual future needs drive any changes, rather than guessing at how it might be used. Should more flexibility be needed, one could, for example, let the values set in queue.wants and queue.next_hop to values configurable in the .ini file.

Can you provide a good example for me to follow?

Yeah, the dovecot plugin seems to be an orphan. It was adopted and I just set it up for automated CI testing and publishing to NPM. Better examples are:

• https://github.com/haraka/haraka-plugin-known-senders
• https://github.com/haraka/haraka-plugin-helo.checks

[AprilGrimoire]

If later (but might not be very near future) I submit a pull request adding this feature to allow more hooks for system-generated mails, are you interested in merging it?

[msimerson]

In your plugin(s), you have final say. If you're talking about the dovecot plugin, then I'd point out that most PRs against Haraka and plugins are merged. Especially if they have tests to verify that they do what is expected.