On Sun, Jan 02, 2022 at 11:01:06PM +0000, Felix Ingram <f.ing...@gmail.com> wrote:
> > > > 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 It's probably easy enough to get Postfix to place email in a virtual mailbox directory for an IMAP account that doesn't exist yet, by using a regexp/pcre lookup table for virtual_alias_maps, or even a tcp:host:port lookup table if the logic gets complicated. But the real trick will be having something notice when a new virtual mailbox directory has been created (e.g., /var/vmail/f...@sub.domain.tld/) for which there is no IMAP user yet (i.e., f...@sub.domain.tld), update Dovecot's password file to create the user, and securely convey the password to the expected user. A content-filter, or the process on the back end of a tcp lookup, or similar might be able to do that, or something else outside Postfix, that just monitors/audits the existence of virtual mailboxes with no corresponding IMAP account, but it doesn't sound right to me. At least, conveying the password to the right person sounds dangerous. Perhaps IMAP account creation for new virtual mailbox directories can be done via the web interface you are writing. cheers, raf
