Configuration Check - Postfix

Submitted by Vince42 on Wed, 01/06/2016 - 17:13 Pro Licensee

Hi,

after some changes I received the information "Virtualmin's configuration has not been checked since it was last updated. Click the button below to verify it now. Re-check and refresh configuration".

When I press the button, the check claims: "Your Postfix configuration is missing the system's mail hostname domain.tld from the mydestination line, which will cause mail to bounce."

First problem: the hostname is host.domain.tld, the domain name is domain.tld - is this just a failure in the right wording?

Second problem: my main.cf is correct and works seamlessly:

### Domain, host etc
mydomain = domain.tld
myhostname = host.domain.tld
# Name used in outgoing mails, default: myhostname, better: mydomain
myorigin = $mydomain
# Domains to receive mail for
mydestination = localhost, localhost.$mydomain, $myhostname, $mydomain

Why is Virtualmin complaining about this configuration or considering it as erroneous?

Cheers Vince

Status: 
Active

Comments

Submitted by andreychek on Wed, 01/06/2016 - 17:24

Howdy -- hmm, what output do you receive if you run the command "hostname"?

Even though you have $myhostname set in the mydestination line at the moment, you may also want to put the output of the "hostname" command there now.

I'll talk to Jamie about how Virtualmin performs those tests though, as having $myhostname in that line should normally be sufficient.

Submitted by Vince42 on Wed, 01/06/2016 - 17:34 Pro Licensee

Hi,

the hostname returns exactly what is specified under $myhostname.

I appended , domain.tld, host.domain.tld to the mydestination line in main.cf, but I still get the same error when re-checking the configuration.

Cheers Vince

Submitted by andreychek on Wed, 01/06/2016 - 20:36

Just to verify -- did you restart Postfix after making that change? I believe Virtualmin uses the postconf tool to determine the value of that setting, so it may not show up as active until Postfix is restarted.

Submitted by Vince42 on Fri, 01/08/2016 - 16:06 Pro Licensee

postconf -n says

mydestination = localhost, localhost.$mydomain, $myhostname, $mydomain
mydomain = domain.tld
myhostname = host.domain.tld

Even after modifying main.cf by adding domain.tld and host.domain.tld, properly restarting the postfix service and postconf -n displaying domain.tld and host.domain.tld at the end of the mydestination line as expected, the configuration check fails. This is really strange ...

PS: Drupal says
Notice: Undefined index: #entity_type in rdf_preprocess_field() (line 545 of /home/virtualmin/public_html/modules/rdf/rdf.module).
Notice: Undefined index: #entity_type in rdf_preprocess_field() (line 545 of /home/virtualmin/public_html/modules/rdf/rdf.module).
Notice: Undefined index: #entity_type in rdf_preprocess_field() (line 545 of /home/virtualmin/public_html/modules/rdf/rdf.module).

Submitted by Vince42 on Fri, 01/08/2016 - 16:18 Pro Licensee

But Drupal says that I am neither allowed to create posts in the forum nor to create any issue ... I hope that this is a Drupal error, that will be fixed soon, as I got some more issues ... ^^

Submitted by Vince42 on Wed, 01/20/2016 - 15:41 Pro Licensee

So there is no solution for this issue?

Submitted by andreychek on Wed, 01/20/2016 - 15:49

I think I may have missed your messages somehow, as they were occurring right around the time we were swapping out website out... sorry!

Are you able to make posts now? It's possible you were seeing an issue that's corrected now.

As far as your server issue goes -- I'm not sure what might cause that, and we haven't been able to reproduce anything like it.

Would it be possible to log into your system and take a look?

I've marked your request as private... if you wanted, you could put your login details here, where only the Virtualmin staff can see them.

Submitted by Vince42 on Tue, 01/26/2016 - 16:20 Pro Licensee

Yes, there must have been some "glitch" indeed - just remembered this open issue. Yes, I am able to post again. :)

I can allow you to log into my server - no problem ... as I would never put my credentials into some web system, could we exchange encrypted mails? We could also make a team viewer session ... whichever you prefer ...

Submitted by andreychek on Tue, 01/26/2016 - 22:07

Well, i'm not really setup for encrypted emails, and we don't prefer to use teamviewer.

Another option would be to use the Virtualmin Remote Support module, which uses SSH keys for access.

Details of using that are available here:

https://www.virtualmin.com/documentation/system/support

With that, you could just enable remote support, and then we could remotely access your system without having to exchange a password. Would that work?

Submitted by Vince42 on Sun, 02/21/2016 - 15:03 Pro Licensee

Hi,

sorry, have been busy lately ... I just enabled the remote login.

Submitted by Vince42 on Sun, 02/21/2016 - 15:37 Pro Licensee

Okay, just noticed that the configuration warning is gone - what was the reason? Let me know when I can retry the configuration re-check myself ... :)

Submitted by andreychek on Sun, 02/21/2016 - 16:36

I didn't actually have a chance to log in yet... so it sounds like something else caused that to get corrected.

Was Webmin or Virtualmin updated or restarted recently? Or was the hostname perhaps changed?

Submitted by Vince42 on Thu, 02/25/2016 - 13:57 Pro Licensee

This is really odd ... the warning disappeared from the system information page - but the failure still exists. At least it is now less annoying. :)

To answer your question: nothing has changed (Webmin, Virtualmin, hostname).

I can enable the support login again, but would appreciate a certain time window, so that the login option is not open for too long.

Submitted by andreychek on Thu, 02/25/2016 - 14:03

Just to clarify, what failure is it that you're seeing at the moment?

Submitted by Vince42 on Thu, 02/25/2016 - 15:08 Pro Licensee

I run Virtualmin - System Settings - Re-Check Configuration and get:

The status of your system is being checked to ensure that all enabled features are available, that the mail server is properly configured, and that quotas are active .. Your system has 31.12 GB of memory, which is at or above the Virtualmin recommended minimum of 256 MB. BIND DNS server is installed, and the system is configured to use it. Your Postfix configuration is missing the system's mail hostname domain.tld from the mydestination line, which will cause mail to bounce. .. your system is not ready for use by Virtualmin.

But my system is set up correctly and works without problems.

PS: The Subject of the comment is not displayed anywhere - is that a desired behaviour?

Submitted by Vince42 on Mon, 03/07/2016 - 17:24 Pro Licensee

I guess we should come back to the plan that you log into my server and run the configuration check yourself. As I dislike to enable remote login "all the time" I would be happy, if you could give me a period of time when you will be able to log in and to scrutinize my problem.

Submitted by andreychek on Mon, 03/07/2016 - 18:46

Hmm, could you perhaps set it for 3 days? That should be more than enough, but is long enough that if we need to get Jamie involved he'd be able to take a look as well.

Submitted by Vince42 on Tue, 03/08/2016 - 15:12 Pro Licensee

I just enabled the remote login unti 2016-03-11.

Could you please also log into webmin itself and check the loading performance? For a few days now it takes half a minute to load webmin or virtualmin - and I got no clue where that comes from. Or should I open another issue for that behaviour?

Submitted by andreychek on Wed, 03/09/2016 - 10:13

I attempted to log into SSH, but that didn't seem to work. Is root login via SSH perhaps disabled in the SSH config file?

Submitted by Vince42 on Wed, 03/09/2016 - 13:47 Pro Licensee

oops, sorry, my bad, yes - I just added root to the AllowUsers, please try again.

Submitted by Vince42 on Sun, 03/13/2016 - 13:47 Pro Licensee

the login period is over and the problem persists - what did you find out?

Submitted by Vince42 on Tue, 03/22/2016 - 18:59 Pro Licensee

sorry for being so impatient, but what were your findings regarding the configuration problem?

Submitted by andreychek on Tue, 03/22/2016 - 23:24

Sorry for the delay -- I need to sort out a couple of things with Jamie regarding your Postfix config, and then we'll get back with you with how we can resolve that.

Submitted by Vince42 on Mon, 04/11/2016 - 15:07 Pro Licensee

Did you find the time to talk to Jamie about my Postfix config?

Submitted by JamieCameron on Mon, 04/11/2016 - 21:39

Is it possible for you to attach your entire /etc/postfix/main.cf file to this bug report?

Submitted by andreychek on Tue, 04/12/2016 - 00:29

I have more information for you Jamie, I'll be in touch with all of that.

Submitted by Vince42 on Tue, 04/26/2016 - 17:25 Pro Licensee

any news regarding the configuration check?

Submitted by andreychek on Tue, 04/26/2016 - 18:16

I'm talking with Jamie about this issue -- he's interested in seeing the following:

  • Full contents of /etc/postfix/main.cf

  • Output of "hostname -f"

  • Contents of /etc/mailname (if any)

Submitted by Vince42 on Wed, 04/27/2016 - 17:02 Pro Licensee

No problem:

/etc/postfix/main.cf

### Domain, host etc
mydomain = eec.de
myhostname = x3.eec.de
# Name used in outgoing mails, default: myhostname, better: mydomain
myorigin = $mydomain
# Domains to receive mail for
mydestination = localhost, localhost.$mydomain, $myhostname, $mydomain
#mydestination = localhost, localhost.$mydomain, $myhostname, $mydomain, x3.eec.de, eec.de
# Clients to relay mail from
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
# Destinations to relay mail to
relayhost =
#smtp_helo_name = $myhostname
smtpd_banner = $myhostname ESMTP $mail_name

### Masquerade
#masquerade_domains = mx24.net
#masquerade_exceptions = root
#masquerade_classes = envelope_sender, header_sender, header_recipient

### Users and groups
#mail_owner = postfix
#setgid_group = maildrop

### Internet interfaces and protocols (default: all)
#inet_interfaces = all
#inet_protocols = all

### Commands
#sendmail_path = /usr/sbin/sendmail
#newaliases_path = /usr/bin/newaliases
#mailq_path = /usr/bin/mailq
#debugger_command =
#  PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
#  ddd $daemon_directory/$process_name $process_id & sleep 5

### Reject codes
unknown_local_recipient_reject_code = 450
unknown_address_reject_code = 554
unknown_hostname_reject_code = 554
unknown_client_reject_code = 554

### Operation mode settings
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
#defer_transports =
#disable_mime_output_conversion = no
# Notify users of new mails
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Trouble to report to the postmaster (bounce, 2bounce, delay, policy, protocol, resource, software
notify_classes = resource, software

### Directories
#command_directory = /usr/sbin
#daemon_directory = /usr/lib/postfix
#data_directory = /var/lib/postfix
#queue_directory = /var/spool/postfix
#program_directory = /usr/lib/postfix
#mail_spool_directory = /var/spool/mail
#html_directory = /usr/share/doc/packages/postfix/html
#manpage_directory = /usr/share/man
#sample_directory = /usr/share/doc/packages/postfix/samples
#readme_directory = /usr/share/doc/packages/postfix/README_FILES
readme_directory = no

### Maps
#alias_maps = mysql:/etc/postfix/mysql-alias.cf
#canonical_maps = hash:/etc/postfix/canonical
#relocated_maps = hash:/etc/postfix/relocated
#transport_maps = hash:/etc/postfix/transport
#sender_canonical_maps = hash:/etc/postfix/sender_canonical
#sender_bcc_maps = hash:/etc/postfix/recipient_bcc
#sender_dependent_default_transport_maps = hash:/etc/postfix/dependent
#virtual_alias_domains = hash:/etc/postfix/virtual
#virtual_maps = hash:/etc/postfix/virtual
#virtual_maps = mysql:/etc/postfix/mysql-virtual.cf
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
virtual_alias_maps = hash:/etc/postfix/virtual
sender_bcc_maps = hash:/etc/postfix/bcc

### Mailbox
#mailbox_transport=
mailbox_transport=lmtp:unix:private/dovecot-lmtp
#mailbox_command = /usr/lib/dovecot/deliver -c /etc/dovecot/conf.d/01-mail-stack-delivery.conf -m "${EXTENSION}"
#mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
message_size_limit = 0
home_mailbox = Maildir/

### TLS parameters
##We need to allow non-TLS clients to still authenticate by user name and password:
#smtpd_tls_auth_only = no
#smtp_tls_note_starttls_offer = yes
##smtpd_tls_cafile = /etc/ca/
#smtpd_tls_loglevel = 1
#smtpd_tls_received_header = yes
#smtpd_tls_session_cache_timeout = 3600s
#tls_random_source = dev:/dev/urandom
##smtp_tls_enforce_peername = no
##smtp_tls_per_site =
##smtp_enforce_tls = no
#smtp_use_tls = yes
#smtpd_tls_security_level = may
#smtpd_tls_mandatory_ciphers = medium
#smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_cert_file=/etc/ssl/certs/mx24.crt
smtpd_tls_key_file=/etc/ssl/private/mx24.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

### SSL parameters
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

### SMTPD
#smtpd_sasl_security_options = noanonymous
#smtpd_sasl_application_name = smtpd
#smtpd_sasl_local_domain = $myhostname
#smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
#smtpd_sasl_type = dovecot
#smtpd_sasl_path = private/dovecot-auth
#smtpd_sasl_local_domain = $myhostname
#smtpd_sasl_authenticated_header = yes
#smtpd_helo_required = yes
#strict_8bitmime = no
#strict_rfc821_envelopes = yes
#disable_vrfy_command = yes
#smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_relay_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_restriction_classes =
  standards_only
  grey_only
  rbl_only
  standards_grey
  standards_rbl_grey
standards_only =
  reject_non_fqdn_sender
  reject_non_fqdn_recipient
  reject_unknown_sender_domain
  reject_unknown_recipient_domain
  reject_unauth_destination
  reject_unauth_pipelining
  reject_invalid_hostname
  reject_non_fqdn_hostname
  reject_unlisted_recipient
  permit_auth_destination
  permit
rbl_only =
  reject_rbl_client zen.spamhaus.org
  permit_auth_destination
  permit
grey_only =
  check_policy_service inet:127.0.0.1:10023
  permit_auth_destination
  permit
standards_grey =
  reject_non_fqdn_sender
  reject_non_fqdn_recipient
  reject_unknown_sender_domain
  reject_unknown_recipient_domain
  reject_unauth_destination
  reject_unauth_pipelining
  reject_invalid_hostname
  reject_non_fqdn_hostname
  reject_unlisted_recipient
  check_policy_service inet:127.0.0.1:10023
  permit_auth_destination
  permit
standards_rbl_grey =
  reject_non_fqdn_sender
  reject_non_fqdn_recipient
  reject_unknown_sender_domain
  reject_unknown_recipient_domain
  reject_unauth_destination
  reject_unauth_pipelining
  reject_invalid_hostname
  reject_non_fqdn_hostname
  reject_unlisted_recipient
  reject_rbl_client zen.spamhaus.org
  check_policy_service inet:127.0.0.1:10023
  permit_auth_destination
  permit
# Ubuntu 10.04 LTS:
#smtpd_recipient_restrictions =
#  permit_sasl_authenticated
#  permit_mynetworks
#  check_recipient_access hash:/etc/postfix/access
#  reject_non_fqdn_sender
#  reject_non_fqdn_recipient
#  reject_unknown_sender_domain
#  reject_unknown_recipient_domain
#  reject_unauth_destination
#  reject_unauth_pipelining
#  reject_invalid_hostname
#  reject_non_fqdn_hostname
#  reject_unlisted_recipient
#  reject_rbl_client zen.spamhaus.org
#  check_policy_service inet:127.0.0.1:10023
#  permit_auth_destination
#  permit
# Ubuntu 12.04 LTS:
#smtpd_recipient_restrictions =
#  reject_unknown_sender_domain
#  reject_unknown_recipient_domain
#  reject_unauth_pipelining
#  permit_mynetworks
#  permit_sasl_authenticated
#  reject_unauth_destination
#  check_policy_service inet:127.0.0.1:10023

# x3 original setting:
# smtpd_recipient_restrictions = permit_mynetworks   permit_sasl_authenticated   reject_unauth_destination check_policy_service inet:127.0.0.1:10023
smtpd_recipient_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  reject_unknown_sender_domain
  reject_unknown_recipient_domain
  reject_unauth_destination
  reject_unauth_pipelining
  reject_invalid_hostname
  reject_non_fqdn_hostname
  reject_non_fqdn_sender
  reject_non_fqdn_recipient
  reject_unlisted_recipient
  reject_rbl_client zen.spamhaus.org
  #check_recipient_access hash:/etc/postfix/access
  check_policy_service inet:127.0.0.1:10023
  permit_auth_destination
  permit

### Checks
#header_checks = regexp:/etc/postfix/header_checks
##mime_header_checks = regexp:/etc/postfix/mime_header_checks
##nested_header_checks = regexp:/etc/postfix/nested_header_checks
#body_checks = regexp:/etc/postfix/body_checks

### E-mail address
recipient_delimiter = +
allow_percent_hack = no

hostname -f x3.eec.de

/etc/mailname x3.eec.de

Submitted by andreychek on Thu, 04/28/2016 - 08:07

Okay, I have good news, and bad news.

We figured out a whole bunch of things that it is not.

But after sorting through several issues that aren't causing the problem, we've been unable to identify what's actually causing it.

Would it be possible for us to log into your system again for "Round 2"? :-)

Submitted by Vince42 on Mon, 05/02/2016 - 13:30 Pro Licensee

sure, no problem - when would be a good time? and for how long?

Submitted by andreychek on Mon, 05/02/2016 - 14:07

It's tough to say for how long; "until it's fixed" would be ideal, but if you could do three days again that would be a good start :-)

Jamie will be able to log in soon, so if you could enable it today that'd be great. Thanks!

Submitted by Vince42 on Mon, 05/02/2016 - 14:16 Pro Licensee

Just enabled the root login and did not enter a expiration date - have fun and good luck! I would highly appreciate if you could post some update now and then, so that I know what is going on ... ;)

Submitted by andreychek on Mon, 05/02/2016 - 17:21

Thanks for enabling that again! Jamie and I have been discussing your issue, and he's going to be logging in to review it himself in more detail.

Submitted by andreychek on Mon, 05/02/2016 - 23:12

Hmm, neither of us seem to be able to access your server via SSH.

Is it possible that root SSH logins have been disabled?

If so, could you temporarily enable those?

Submitted by Vince42 on Tue, 05/03/2016 - 01:23 Pro Licensee

dang, sorry, forgot to apply the changes - login should now be enabled.

Submitted by andreychek on Tue, 05/03/2016 - 09:05

Yup, that works great for me.

Jamie will be taking a look shortly... thanks!

Submitted by JamieCameron on Tue, 05/03/2016 - 22:49

Thanks - I am taking a look now.

Submitted by JamieCameron on Tue, 05/03/2016 - 22:59

Ok, I found the issue - in your /etc/postfix/main.cf file, the "myorigin" line had a space at the end, which was confusing Virtualmin's parser!

I fixed that on your system, and will handle it better in the next release.

Submitted by Vince42 on Wed, 05/04/2016 - 18:00 Pro Licensee

Funny ... sounds like golden rule "small cause, large effect" - thank you for finding the cause! And good luck with your efforts to fix this! I will now have a look into the other configuration issues virtualmin is moaning about ... ^^

Submitted by Vince42 on Wed, 05/04/2016 - 18:26 Pro Licensee

I don't know whether I should open another issue, as it is still Configuration Check related and we are currently already "setup": Now the configuration check gets stuck with The Procmail program needed for spam filtering does not appear to be installed on your system, or has not yet been set up properly in Webmin's Procmail Mail Filter module. If your system does not use spam filtering, it should be disabled in Virtualmin's module configuration page.. Procmail is properly set up, I checked the module configuration, changed the binary from procmail to /usr/bin/procmail (although I thing that it should not be necessary). Any ideas?

Submitted by andreychek on Wed, 05/04/2016 - 19:08

Jamie, it looks like the mailbox_command in Postfix has been changed to use a alternate program for email delivery... could that trigger the error he's seeing?

Submitted by JamieCameron on Wed, 05/04/2016 - 19:30

Yes, it could - the mailbox_command line should be set to :

mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME

Submitted by Vince42 on Thu, 05/12/2016 - 16:29 Pro Licensee

Both mailbox_command lines are commented out. As far as I remember this has been done due to using lmtp daemon for delivery. Changing those lines should not fix the problem and I don't dare to change them as they might interfere with lmtp setup. And even if considering this, I would rather enable the dovecot line, as I am using dovecot - not procmail. I am no Postfix expert though ... are you able to advise here?

Submitted by andreychek on Thu, 05/12/2016 - 16:36

Well, the problem you're seeing at the moment is that you do indeed have a working setup -- but it's much different than what Virtualmin initially sets up, or is expecting to see.

Virtualmin doesn't know anything about using Dovecot or LMTP for email delivery, it always uses procmail.

While it's possible to manually change that, and still have things appear to work -- Virtualmin won't know how to interact with your email system without breaking things. And items such as spam and virus scanning may not work at all (unless they're also setup manually).

So how can that all be fixed? Hmm, I'm not quite sure... you seem to have a setup there that Virtualmin isn't designed to handle.

I'll ask Jamie if there's perhaps a way to at least not have Virtualmin attempt to validate your email setup, but I'm not sure there is a way to do that at the moment.

Submitted by Vince42 on Thu, 05/12/2016 - 16:42 Pro Licensee

I am open for experiments ... maybe this deserves some deeper scrutiny. While my setup might be deviating from Virtualmin defaults, it is - as you said - working and not a weird special setup - in fact LMTP is recommended for high mail load instead of spawning several delivery processes.

I don't know what the best solution would be ... if virus scanning and spam handling rely on procmail, it should be tested within those module consistencies, right?

If you like, I could try to do a little research on whether LMTP and procmail could exist side by side in the config or not ... depending on those findings, we could discuss the next steps.

Submitted by andreychek on Fri, 05/13/2016 - 00:09

There are indeed a number of different ways of delivering email, each with their own advantages and disadvantages.

And I agree with you, LMTP is nice -- I've actually been reviewing whether a case could be made to switch Virtualmin over to using LMTP and Sieve for email delivery and filtering.

Unfortunately, the ability to do that is a long ways off in the future... Virtualmin is deeply tied to using procmail.

Now, is it possible to use some combination of the two? Possibly... but that's not a setup that we're at all familiar with, so I wouldn't be sure how to tell you to do that.

I'd offer that even if that were possible to use both side by side -- if you were to introduce procmail onto your server for Spam and Virus scanning, it would likely undo any performance benefits you were receiving by using purely lmtp. At which point it may be simpler to just use procmail.

How many emails are you receiving a day though, out of curiosity?

Submitted by Vince42 on Wed, 07/06/2016 - 16:59 Pro Licensee

Let's warm up this old issue ... :)

I think that Virtualmin should not enforce for example the procmail check in order to judge a mail server setup as valid. Valid options like LMTP and Sieve should be recognized as valid alternatives and the Configuration Check should continue. I understand that Virtualmin is "deeply tied" to using procmail, but a first good step would be to identify LMTP / Sieve in the configuration and to just give a kind of warning instead of letting the Configuration Check fail.

I will not investigate the possibility of having a procmail and an LMTP setup in parallel just to satisfy Virtualmin's expectation regarding the mail setup.

I will nevertheless try to setup SpamAssassin at some time in the future. And while I understand, that I will not gain performance benefits from using procmail there and LMTP with Postfix, I usually go the "state of the art" way in my configurations - and every article I read so far clearly recommended LMTP over procmail and I personally like Sieve very much without going into the discussion whether Sieve or procmail is the better choice.

My mail volume is not that high, it is like 1,000 to 2,000 mails a day.

So let's talk about some "workaround" ... would it be possible to disable just the Postfix configuration check somehow? Or would it be an option for the near future to make the Configuration Check somehow interactive? Like giving the user the option to say "I understand the warning but it is okay."?

Submitted by andreychek on Wed, 07/06/2016 - 17:36

I just wanted to verify -- I don't imagine that error goes away if you go into System Settings -> Features and Plugins, and you disable the Spam and Virus scanning features?

Submitted by Vince42 on Mon, 07/11/2016 - 14:44 Pro Licensee

I disabled the Spam and Virus feature and the Configuration Check message disappeared. Now I am a little bit irritated as the error usually popped up during the Postfix sanity check - why and how did this solve the problem? :)))

Submitted by andreychek on Mon, 07/11/2016 - 16:33

Great, glad to hear that's working!

Sorry for the confusion about the error. The error shows up under Postfix, as the issue is related to the Postfix configuration.

In most cases, a person would want to tweak the Postfix config in order to resolve the issue. Remember, what you're trying to do is generally something we recommend against :-)

Submitted by Vince42 on Mon, 07/11/2016 - 16:38 Pro Licensee

I know that you recommend against using LMTP and Sieve - but it is still a valid option. I would really have to have this issue to be turned into some kind of feature request for some future release of Webmin / Virtualmin. I would also like to sponsor the development for this feature. Which options do we have?

Submitted by andreychek on Mon, 07/11/2016 - 17:09

I'm just explaining why the error appears the way it does, that's all.

As for your feature request -- are you referring to using LMTP and Sieve in place of procmail?

Submitted by Vince42 on Mon, 07/11/2016 - 17:12 Pro Licensee

Yes, the feature request would be something like "accept other setups like LMTP and Sieve as valid options". Another feature request for the future would be a Sieve module, which I can offer to my customers.

Submitted by andreychek on Mon, 07/11/2016 - 18:00

I'd be happy to talk to Jamie about that. It's a pretty big project, as Virtualmin is tied to procmail.

But we'll look into whether that's something we could do, and if so, what sort of timeframe we're looking at.

So that I can do some testing of my own, would it be a simple process to explain how you setup LMTP for mail delivery?

I see that you set "mailbox_transport=lmtp:unix:private/dovecot-lmtp" in the Postfix config, is there additional setup you needed to perform?

Submitted by Vince42 on Mon, 07/11/2016 - 18:33 Pro Licensee

Yes, please talk to Jamie about it. I know that it's a big project, but I also think that it is a feature that should be implemented. Virtualmin can be tied to procmail, but it should be open to other configurations as well - I think it's worth the effort. Once you have an estimation of the timeframe, we can negotiate the details. When I set up my new server, I just followed the instructions on http://wiki2.dovecot.org/HowTo/PostfixDovecotLMTP - and that was all. ;)