> what should it do with the non local messages or local messages directly > at aliases?OK, so I gather that the Submission Server cannot do that (yet). My suggestion for a future version would then be: How about running dovecot-lda, if the user happens to be local, or a local alias? Or at least provide some sort of pattern matching: anything matching *@example.com , pass the message to dovecot-lda . It feels strange that a plug-in accessing the local user database for authentication purposes, and running on the same Dovecot server instance, needs to use an MTA to deliver a local message, it is like going out to come back in again. But I do not know much about mail servers yet. Have I missed some important concept here that makes this idea silly indeed? Regards, rdiez
On 02/11/2020 21:33, R. Diez wrote:> >> what should it do with the non local messages or local messages directly >> at aliases? > > OK, so I gather that the Submission Server cannot do that (yet). > > My suggestion for a future version would then be: How about running > dovecot-lda, if the user happens to be local, or a local alias? Or at > least provide some sort of pattern matching: anything matching > *@example.com , pass the message to dovecot-lda . > > It feels strange that a plug-in accessing the local user database for > authentication purposes, and running on the same Dovecot server > instance, needs to use an MTA to deliver a local message, it is like > going out to come back in again. But I do not know much about mail > servers yet. Have I missed some important concept here that makes this > idea silly indeed? > > Regards, > ? rdiezsending email only to only local users seems like a really specific and limited use case. MTAs can handle both this use case and the more general one. Besides how would you differentiate between real local users and aliases? If you were to implement? sending anything matching *@example.com to dovecot-lda what would happen if the destination was an alias and not a real user? Which real user should the email be delivered to? John
It would be worth a $5 VPS investment to set up a proper email server with dovecot and postfix. Observe how they work together. Use maximum verbosity and read the logs. You can use one of those cheap TLDs nobody but the spammers use. They cost a dollar or so. Namecheap is peddling cyou. ? Original Message ? From: rdiezmail-2006 at yahoo.de Sent: November 2, 2020 12:33 PM To: john at voipsupport.it Cc: dovecot at dovecot.org Subject: Re: Delivering locally through the Submission Server> what should it do with the non local messages or local messages directly > at aliases?OK, so I gather that the Submission Server cannot do that (yet). My suggestion for a future version would then be: How about running dovecot-lda, if the user happens to be local, or a local alias? Or at least provide some sort of pattern matching: anything matching *@example.com , pass the message to dovecot-lda . It feels strange that a plug-in accessing the local user database for authentication purposes, and running on the same Dovecot server instance, needs to use an MTA to deliver a local message, it is like going out to come back in again. But I do not know much about mail servers yet. Have I missed some important concept here that makes this idea silly indeed? Regards, ?? rdiez
Piotr Auksztulewicz
2020-Nov-03 10:31 UTC
Delivering locally through the Submission Server
On Mon, Nov 02, 2020 at 09:33:08PM +0100, R. Diez wrote:> OK, so I gather that the Submission Server cannot do that (yet).And probably would never do. It isn't its job description. Actually, it is just a convenience/workaround feature, which comes handy only if your own MTA cannot handle dovecot's SASL authentication (must be something real strange) or there are some integration/security/policy issue perceived (but I cannot think of any, actually). In this case you can set up dovecot's submission server, which uses dovecot's authentication settings, so you have single source of authentication, and whitelist dovecot IP address in your MTA so it accepts anything that dovecot's submission server lets through. But I don't think it is a good idea personally, it is more open to exploitation this way, unless the address is 127.0.0.1, in which case you can simply set up SASL over Unix sockets, which is as secure as your host server is.> It feels strange that a plug-in accessing the local user database for > authentication purposes, and running on the same Dovecot server instance, > needs to use an MTA to deliver a local message, it is like going out to come > back in again. But I do not know much about mail servers yet. Have I missed > some important concept here that makes this idea silly indeed?The idea is to have one software package that does one defined set of functions really well, as not to complicate things by lumping everything together. Delivering mail is a generally complex process that needs a separate expertise than storing/indexing/accessing email messages. The concepts of MTA, MDA, MSA, MS and MUA are even outlined in the RFCs (see for example RFC 5598 Chapter 4.), so it is no surprise that separate software packages exits for these functions. In this context, dovecot is primarily a MS and, consequently, a MDA; but it also contains an add-on MSA - namely the submission server. To have a complete email system, you also need MTA - and users need MUAs. You can provide the MUA yourself (e.g. a webmail package) or just let users shoose their MUAs themselves (IMAP clients mostly). You may provide your MTA yourself and integrate it with dovecot. In a simple case it is easy, lots of tutorials exist. Alternatively, you could have someone else provide MTA service for you if you and the other party come to an agreement. Only in this case the dovecot submission server is useful, IMHO. -- Piotr "Malgond" Auksztulewicz firstname at lastname.net
> And probably would never do. It isn't its job description.> [...] > The idea is to have one software package that does one defined set of > functions really well, as not to complicate things by lumping everything > together. Delivering mail is a generally complex process that needs > a separate expertise than storing/indexing/accessing email messages. > [...] > I didn't know about BURL, thanks. Looks interesting. I am sometimes > really annoyed by double upload when sending big files. I wonder if my > mail clients support this... need to check. Maybe then I'll configure > dovecot sumbission just for BURL sake. You have realised just now how the Unix philosophy can easily break down. The BURL case makes it clear that strict separation does not fit the bill in this case. Separating mail storage from sieve/filtering from sending (MTA) etc. creates integration costs and data duplication. Sometimes I wonder whether it would not be better to have an integrated mail server that knows how to send, receive, filter and store e-mail. Like a database server, that not only knows how to store, index, query and replicate data, but can also run stored procedures that have access to all features (over an internal API) and can run anything at all, including running external tools. Or even like Microsoft Access, where you can do all that plus even code a GUI. The Emacs of Mail. 8-) Regards, rdiez