Delivering locally through the Submission Server
Hi all:
I am learning Dovecot step by step. I have enabled the Submission Server, in the hope that I would not need to learn other MTAs like Postfix.
The Submission Server is very comfortable: it picks up the existing Dovecot configuration, so that you do not need to configure any user authentication separately. It is working fine on my test setup.
My first thought was that, if the recipient is a local mailbox, the Submission Server would not need to relay the message to any external SMTP server, as it could just deliver it locally. After all, it is running on the same Dovecot.
But it cannot do that, can it? Is there a work-around? I am still hoping that the mail server still works locally if the Internet connection fails. But I would need to learn some Postfix magic for that, would I?
Thanks in advance, rdiez
On 02/11/2020 20:17, R. Diez wrote:
https://doc.dovecot.org/admin_manual/submission_server/
what should it do with the non local messages or local messages directly at aliases?
John
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:
sending 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@yahoo.de Sent: November 2, 2020 12:33 PM To: john@voipsupport.it Cc: dovecot@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
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.
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@lastname.net
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
R> I am learning Dovecot step by step. I have enabled the Submission R> Server, in the hope that I would not need to learn other MTAs like R> Postfix.
It's not that hard to setup postfix to accept incoming email from the internet and your local users, and to then pass it to dovecot as needed. Dovecot is for IMAP/POP (shudder) access of your stored emails. It's not for sending email, or even receiving it from the outside world.
R> The Submission Server is very comfortable: it picks up the existing R> Dovecot configuration, so that you do not need to configure any R> user authentication separately. It is working fine on my test R> setup.
It's not hard to setup postfix/dovecot to use the same authentication. My system used plain files. Trivial.
R> My first thought was that, if the recipient is a local mailbox, the R> Submission Server would not need to relay the message to any R> external SMTP server, as it could just deliver it locally. After R> all, it is running on the same Dovecot.
Really, you're trying to optimize the wrong thing. Just setup a linode (or anything else except digital ocean since charter.net blocks them completely for email delivery) at $5/month and install postfix/dovecot together. Works great.
John
participants (5)
-
John Fawcett
-
John Stoffel
-
lists
-
Piotr Auksztulewicz
-
R. Diez