Feature request: Local-only mode

[iskunk]

In my use case, I'd like to receive mail from system daemons / cron jobs / etc. but don't want to set up authentication for an external/third-party SMTP relay. Partly because the credentials could allow access to more than just SMTP relaying if they are ever leaked (see: Gmail) and also because nowadays, setting up a third-party e-mail service with simple non-2FA username + password authentication can be non-trivial, if even supported at all (see: also Gmail).

There is currently no good way to get this functionality, because if I leave SMARTHOST unset, or set it to a dummy destination (e.g. localhost) then dma will either attempt direct delivery (a quixotic task in today's world of spam-spewing home Internet connections) or keep retrying delivery for a long time.

This would effectively be the opposite of the NULLCLIENT directive. Any attempt to send to a remote destination, or to an alias that resolves to a remote destination, should fail immediately.

[corecode]

maybe something like NOREMOTE?  Happy to take a patch.

…

On 14/02/2023 01:25, Daniel Richard G. wrote: In my use case, I'd like to receive mail from system daemons / cron jobs / etc. but don't want to set up authentication for an external/third-party SMTP relay. Partly because the credentials could allow access to more than just SMTP relaying if they are ever leaked (see: Gmail) and also because nowadays, setting up a third-party e-mail service with simple non-2FA username + password authentication can be non-trivial, if even supported at all (see: also Gmail). There is currently no good way to get this functionality, because if I leave |SMARTHOST| unset, or set it to a dummy destination (e.g. |localhost|) then dma will either attempt direct delivery (a quixotic task in today's world of spam-spewing home Internet connections) or keep retrying delivery for a long time. This would effectively be the opposite of the |NULLCLIENT| directive. Any attempt to send to a remote destination, or to an alias that resolves to a remote destination, should fail immediately. — Reply to this email directly, view it on GitHub <#121>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABLOO437I5CYISNDCJBKBTWXMXNTANCNFSM6AAAAAAU3GHDLU>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[iskunk]

The code looks straightforward enough... I can try putting something together. I have a couple questions:

• This option is basically a tri-state with NULLCLIENT, so the operating mode is one of (normal, nullclient, noremote). I think it would thus be desirable to name these in a more unified manner, so that they don't appear unrelated. Also, I'd argue that having option keywords in the negative form isn't ideal, and the meaning of "null client" isn't obvious. How about renaming NULLCLIENT to REMOTEONLY (while retaining recognition of the former), have this new one be LOCALONLY, and normal mode is the absence of either? Specifying both keywords would be an error.

• Do I understand correctly that in NULLCLIENT mode, dma should send a message with only a local username to the smarthost? So it is expected that the smarthost will qualify/recognize that local name, and dma shouldn't return an error in such a case?

[corecode]

• I like your proposal. We can also put the operating modes as arguments to a new DELIVERYMODE config key, e.g. DELIVERYMODE LOCALONLY; I'll leave it to you to decide what you prefer and which config key name you use.

• I think so? Makes sense to me.

[iskunk]

All right, my PR is up. Let me know what you think.