> On 2 Jan 2022, at 22:08, DL Neil <Postfix@Rangi.Cloud> wrote:
>
> On 03/01/2022 10.41, Felix Ingram wrote:
>> Thanks Max,
>>
>> I’m making something similar to a disposable email service, which is why I
>> need to accept mail for any user. There’s still some validation for domains,
>> etc, so I’m not too worried about accepting everything. I was looking to use
>> Cyrus, which has a setting to create mailboxes as needed, but I’m preferring
>> Dovecot for other reasons. As I’m using Postgres for the DB, I think I’m
>> okay with doing an update for every mail - the service isn’t particularly
>> high volume and updates would be the equivalent of just adding users to
>> Dovecot through some other means.
>>
>> I’m leaning towards a content filter though, as I am planning on adding some
>> other functionality in the future. (e.g. handling verification emails from
>> certain users, etc. I should look at how majordomo works for this list…).
>> With the content filter, I could create the user if needed, then put the
>> mail back into the queue for postfix to lmtp over to Dovecot. Though that
>> would also be possible with your two-step lmtp idea, so I’ll have a look at
>> my options for that.
>
>
> Am also following this, if only for curiosity's sake.
>
> In addition to 'named accounts', which are often implemented as virtual
> users (and/or domains), the existing Postfix/Dovecot mechanism allows
> 'catch-all' addresses (receive any msgs sent to the domain, for which
> there is no account).
>
> Rather than dealing with the complexity of lmtp, etc, in 'the middle',
> why not consider working from the 'back-end'?
>
> The story seems to be:
> 1 user wants to use a one-off address
> 2 user either invents same or system generates and sends to third-party
>
> - need to maintain a linkage between that user and that address, in the
> same way that is normal-case, excepting this is temporary/one-off
>
> 3 one-off address is used by third-party/incoming message
> 4 Postfix ascertains is not a real/virtual email-address on this domain
> 5 thus, msg is dumped into the 'catch-all' account
>
> Custom code:
> 6 access the 'catch-all' imap/pop account
> 7 tie temporary-address to actual-user
> 8 forward, or 'dump' msg into user's permanent address/mbx
> 9 mark one-off email address as 'used'/'drop'
> - ie never forward and/or send appropriate 'bounce' response to any
> spam-assumed follow-up messages-received hereafter.
>
>
> NB a feature of 'catch-all' accounts is that if someone makes a typo in
> an established account-name, the message will be distributed to the
> 'catch all' account, ie there will be no bounce-message sent 'back' to
> warn the sender of his/her mistake, eg
>
> mailbox: f...@domain.tld
> error: f...@domain.tld
>
> As outlined above, "Ferd" will be treated as a temporary-address but
> will (presumably) not be 'registered' to a real user-account!
This looks similar to what I have planned but there are a few requirements for
how it will be used:
* Users need to be able to have email accepted without creating addresses
beforehand. There are a number of situations where people will need an address
that will work but won’t be able to log on to create it ahead of time.
* Multiple addresses need to end up in the same mailbox - at the moment I use a
little regex magic in my virtual aliases to redirect as needed.
* Multiple users need to access the same mailbox - this will be handled through
a web interface that we’re writing.
The catch-all address is interesting, however. We’re doing some DNS tricks and
the mailbox that mail ends up in will be based on the subdomain it is sent to,
so it’s unlikely that we’ll need a catch-all (if someone mis-types the address,
then the DNS won’t resolve. In your example, Fred and Ferd would both go to the
same mailbox, as it would be based on whatever is after the ‘@‘).
I think a content-filter will be the quickest win for now: get an email, update
the DB, use sendmail to pass it on to Dovecot via lmtp.
Regards,
Felix
