Tag Archives: SMTP

Dovecot LDA vs Procmail

I have a mail server configuration based on Postfix for the smtp, Dovecot for the imap and virtual users receiving e-mails in maildir boxes.

I am also using Amavis and Spamassassin for content filtering.

I am not going now to describe this configuration, I think there are already a lot of very good tutorials about it all over the web. Moreover, the openSUSE maintainers made such a configuration quite easy : a sensible part of the work just consists in commenting out some line in the configuration files.

However, with the basic setup, I had an issue with permissions :  all e-mails delivered by Postfix were created with permissions set to 600.

A typical use case with which I got into trouble was spam learning, done with a cron script with a dedicated account (“vscan”, you don’t want to execute such a script with root, right ?).

In that case, what I need is files to be created with permissions 660.

It seems easy and rather obvious at first, but actually there is not such a setting in Postfix.

Actually, it is not really the job of the MTA to do it, so in the case of Postfix it doesn’t bother with the transmission of such a parameter.
Then, I tried to use Procmail and set UMASK in /etc/procmailrc, but this just didn’t have any effect.

After searching and trying in vain a couple of hours, I found out that Dovecot can also deliver e-mails from the MTA to the maildir with Dovecot LDA.

So I tested it out. The configuration is pretty straightforward.

Add the line in bold to the virtual user configuration in /etc/postfix/main.cf :

[...]
virtual_mailbox_domains = domain.com
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /home/vmail
virtual_minimum_uid = 100
virtual_gid_maps = static:1002
virtual_uid_maps = static:1001
virtual_transport = dovecot
[...]

Now, add these lines in /etc/postfix/master.cf :

[...]
# Dovecot LDA
dovecot   unix  -       n       n       -       -       pipe
   flags=DRhu user=vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
[...]

Finally, configure /etc/dovecot/dovecot.conf with these sections :

[...]
protocol lda {
  # If you wish to use plugins you need to specify plugin directory
  # For example quota enforcing is implemented by plugin
  module_dir = /usr/lib/dovecot/modules/lda
  # Address from LDA should send MDNs like out of quota
  postmaster_address = postmaster@domain.com
  # UNIX socket path to master authentication server to find users.
  auth_socket_path = /var/run/dovecot/auth-master
}
[...]
auth default {
[...]
  socket listen {
	master {
		# Master socket provides access to userdb information. It's typically
		# used to give Dovecot's local delivery agent access to userdb so it
		# can find mailbox locations.
	      	path = /var/run/dovecot/auth-master
      		mode = 0660
		user = vmail
		group = vmail
	}
	client {
		# The client socket is generally safe to export to everyone. Typical use
		# is to export it to your SMTP server so it can do SMTP AUTH lookups
		# using it.
		path = /var/run/dovecot/auth-client
		mode = 0660
	}
  }
}
[...]

And that’s all !
Restart Postfix and Dovecot, check the log to ensure that everything works fine.
Now all new mails should come out in the maildir folder with permissions set to 660.

Definitely, in my opinion, Dovecot LDA is the way to go : simple and extensible. Good bye Procmail and your cluttered configuration file.

Postfix : TLS not working outside my network

As I just finished setting TLS and SASL to secure the access to my Postfix server, I realized that it was working only from inside my network.

What I got from my lan :

$ telnet mars 25
Trying 192.168.222.10...
Connected to phocean.net.
Connected to phocean.net.
Escape character is '^]'.
220 phocean.net ESMTP Postfix (Debian/GNU)
220 phocean.net ESMTP Postfix (Debian/GNU)
ehlo phocean.net
ehlo phocean.net
250-phocean.net
250-phocean.net
250-PIPELINING
250-SIZE 200000000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH NTLM DIGEST-MD5 CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

I shows well that the TLS handshake is initiated.

But from this outside, I just got this weired thing :

$ telnet phocean.net 25
$ telnet phocean.net 25
Trying 81.64.194.119...
Connected to phocean.net.
Connected to phocean.net.
Escape character is '^]'.
220 **********************************************
ehlo phocean.net
ehlo phocean.net
502 5.5.2 Error: command not recognized

Of course, the firewall, a Cisco Pix one, was properly set to redirect port 25 UDP/TCP to my server.

However, I soon focused my effort on this equipment. I considered a while that the cause could be some filtering from my provider, but most probably, the problem came from the Pix.

That was not difficult to figure out : it had some protocol inspector activated for SMTP :

$ sh ru
[...]
fixup protocol smtp 25
[...]

Just after :

> no fixup protocol smtp 25

… it started to work perfectly well !!!

The engine for the SMTP protocol could not recognize the TLS handshake, considered that the SMTP session as not valid and therefore blocked it !

I can deactivate it without any fear as my Postfix server is already pretty well secured, or at least configured to reject any weired SMTP dialog.

Postfix : “error writing message: File too large”

I suddenly started to received some undelivered mail notifications while I was trying to send some messages to a mailbox hosted on my Postfix server.

The cause described in the notification was :

error writing message: File too large

The first thing I did was checking my configuration file, main.cf.
It seemed all right :

[...]
mailbox_size_limit = 0
message_size_limit = 200000000
[...]

Note that “0” means unlimited.
I checked the mailbox in question : it was nearing the size of 50 Mb.

I started to think that during some Postfix update, the meaning of the value “0” may have changed.
I tried different values without success.

I started to become crazy with that, but, finally, after quite a long time spent on google, I finally found the trick, which is just a simple line to add in main.cf :

virtual_mailbox_limit = 0

Indeed, I use virtual users as mail account ! I just never imagined there was a differtent setting for virtual users (which can be a convenient setting in some case).