Re: How to temporarily make all mailboxes read-only for backup purposes?
On 26/11/23 08:02, Steve Litt wrote: Is the remote vendor going to take the same care in preserving your data as you would? You could buy two 2TB spinning rust external hard drives for seventy bucks each, so if one gets borked you have the other. If you desire offsite, keep one in a bank safe deposit box high off the ground to prevent water damage. As a matter of habit I've kept every hard disk I've ever used since the 1990s. Going back to one after it has been in storage for 5 years has a high probability it won't work. They either won't fire up at all or there will be major problems with the data. As a matter of policy I suggest that you keep moving and aggregating the contents of old drives to the obviously much larger new drives every couple of years. Incidentally, to save me the bother of writing it, is there a program that can scan drives and extract and classify unique copies of 'useful' files such as photos and emails - probably keeping their MD5 and metatdata and in a SQL database - maybe even the binary file blob as well. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Minimum configuration for Dovecot SASL only?
On 6/11/23 04:36, jeremy ardley via dovecot wrote: You should be able to use ssh with port forwarding to establish a TLS connection between devices. Postfix would see a remote SASL service as a local service. An alternative and possibly more reliable and easily configured mechanism would be using openVPN to allow postfix to connect to a remote SASL provider through a TLS protected connection. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Minimum configuration for Dovecot SASL only?
On 6/11/23 03:25, Nick Lockheart wrote: I can't use the real Dovecot IMAP server for auth, because it runs on a separate server, and Postfix does not support TLS connections for SASL. -- You should be able to use ssh with port forwarding to establish a TLS connection between devices. Postfix would see a remote SASL service as a local service. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Roundcube
On 8/9/23 16:24, Marc wrote: Since when does a hacked website gain root? A web search on 'linux web server exploits that gain root' will give many examples. Security design by first principle assumes that an attacker will gain root access. Best practise is to limit the damage that can cause. The usual way to limit it is put all public facing systems in a DMZ and have a very carefully controlled access from them to an internal priavte network. The access control is performed by systems that cannot be controlled by a breached public facing server. e.g. router firewalls,. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Roundcube
On 8/9/23 07:38, dovecot--- via dovecot wrote: Roundcube does not have direct file access to the emails even on the same server. Roundcube opens a connection to dovecot, supplies the user/pass/login credentials to dovecot, and dovecot fetches the email stores and serves it to roundcube. There is nothing a hacker can gain access to by exploiting roundcube that they also couldn't get in the same scenario if roundcube and dovecot were on two different machines. -- The scenario you describe does not consider a breach of the web mail service that allows root access to the file system. If the web service is compromised to that extent then the mail file store is also compromised. If the mail file store is on a different device then an exploit has to not only breach the web service on the interface device, it then has to breach the remote store. This will be extremely difficult compared to simply breaching a web server and locally exploiting it. When the dovecot server is on a remote system and correct firewalls are in place, then the attacker has to breach the imap protocols as well This article describes the concept https://www.fortinet.com/resources/cyberglossary/what-is-dmz ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Roundcube
On 8/9/23 05:00, joe a wrote: Any known issues with installing/running roundcube and dovecot on the same server? There is a generic issue with doing this. That is if you have roundcube (or any other web mail interface) on the same server as dovecot, a breach of the web interface could be quite serious and allow access to the complete mail store. A better configuration is to run the web mail interface on an isolated server and get it to communicate using TLS imap with a remote dovecot service. For economy, you could do this on the same machine using a small virtual server to run roundcube ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: [SOLVED] Dovecot with Postfix "no SASL authentication mechanisms"
On 5/9/23 14:31, Michel Verdier wrote:
dovecot with PAM needs plaintext method. So if postfix disable it they
can't share a method.
You have to be careful to require any plaintext client password to
travel over a TLS secured connection
smtpd_tls_auth_only = yes
More generally, it's good practice to use preferred ciphers and
protocols. This is part of my postfix configuration:
# TLS parameters
tls_random_source = dev:/dev/urandom
smtpd_use_tls = yes
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_security_level = may
smtpd_tls_ask_ccert = yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_dh1024_param_file = /etc/pki/tls/private/postfix.dh.param
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtp_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtp_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# From Redhat
# Alternat Protocols TLSv1.2 only
smtpd_tls_mandatory_protocols = !SSLv2
smtpd_tls_protocols = !SSLv2
smtp_tls_mandatory_protocols = !SSLv2
smtp_tls_protocols = !SSLv2
# Ciphers
# Currently recommended ciphers, excluding DES-based ciphers to avoid
SWEET32 attack
# and remove SHA1-based ciphers, leaves SHA256 & SHA256 variations
smtp_tls_exclude_ciphers = EXP, MEDIUM, LOW, DES, 3DES, SSLv2
smtpd_tls_exclude_ciphers = EXP, MEDIUM, LOW, DES, 3DES, SSLv2
tls_high_cipherlist =
kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES:!SHA
smtp_tls_ciphers = high
smtpd_tls_ciphers = high
# End from Redhat
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Dovecot with Postfix "no SASL authentication mechanisms"
On 4/9/23 14:03, Willy Manga wrote: "fatal: no SASL authentication mechanisms" -- try setting in dovecot auth_debug = yes auth_verbose = yes and then restart both services and check logs when the problem occurs. Also, be aware that dovecot usually 'subcontracts' the auth process to pam, so checking the contents of /etc/pam.d/dovecot could be helpful ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Fwd: dovecot and postfix, authentication issue
On 6/7/23 20:49, joe a wrote:
On 7/6/2023 8:12 AM, jeremy ardley via dovecot wrote:
On 6/7/23 19:15, joe a wrote:
If your example was meant to show the correct way, I cannot see any
difference between that and what my posted config shows other than
the sequential (contiguous?) in your example.
Perhaps try the different configuration out? Or even better, stick to
one auithentication method only.
Jeremy
Sorry, not to appear dense or argumentative, but I did not see any
difference in your example, vs what exists, other than that in your
example they are grouped together.
Is that what you suggest I try, or are my aging eyes and brain missing
something there?
How about just using PAM?
In dovecot.conf :
auth_mechanisms = plain login
passdb {
driver = pam
}
userdb {
driver = passwd
}
This will then call pam whose config is mainly determined by
cat /etc/pam.d/dovecot
#%PAM-1.0
#auth required pam_faillock.so preauth silent audit
#auth [default=die] pam_faillock.so authfail audit
@include common-auth
@include common-account
@include common-session
Assuming the pam config is defaults then you will get pam authenticating
local users against the local (unix) passwd file. In turn this will
authenticate dovecot users and then postfix users
This may sound complex but it's pretty standard to have postfix -->
dovecot --> pam --> unix_local
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot and postfix, authentication issue
On 6/7/23 19:15, joe a wrote: If your example was meant to show the correct way, I cannot see any difference between that and what my posted config shows other than the sequential (contiguous?) in your example. Perhaps try the different configuration out? Or even better, stick to one auithentication method only. Jeremy -- ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot and postfix, authentication issue
On 6/7/23 10:17, joe a wrote:
Greetings from a new dovecot user.
Have setup dovecot on openSuse 15.4 with postfix as the MTA. Both are
the latest version in that distribution.
Simple virtual user setup using /etc/dovecot/passwd
Dovecot seems to be working and all the defined users are
authenticating well enough for imapsync to migrate files to the
mailboxes.
However, when attempting to send test mail via postfix, only some
users are authenticated and have mail delivered. Using swaks (smtp
toolkit) the failures are: 550 5.1.1 :
Recipient address rejected: User unknown in local recipient table
I'm puzzled, probably some simple thing overlooked. To avoid clutter,
I won't include postfix items unless asked.
dovecot --version 2.3.20 (80a5ac675d)
dovecot -n
# 2.3.20 (80a5ac675d): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.20 (149edcf2)
# OS: Linux 5.14.21-150400.24.66-default x86_64
# Hostname: flitch
auth_verbose = ob-fuskate
disable_plaintext_auth = no
first_valid_uid = 100
info_log_path = /var/log/dovecot-info.log
log_path = /var/log/dovecot.log
mail_location = maildir:~/Maildir
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date index ihave duplicate mime foreverypart
extracttext
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
passdb {
args = /etc/dovecot/passwd
driver = passwd-file
}
plugin {
sieve = file:~/sieve;active=~/.dovecot.sieve
}
protocols = imap lmtp
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
}
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0600
user = postfix
}
}
ssl = no
ssl_cipher_list =
ALL:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH
ssl_options = no_compression
ssl_prefer_server_ciphers = yes
userdb {
driver = passwd
}
userdb {
args = uid=vmail gid=vmail home=/home/vmail/%u
driver = static
}
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
The issue you're experiencing might be due to the fact that you have two
passdb and userdb blocks in your configuration. Dovecot will use the
first passdb and userdb that successfully authenticate a user, and
ignore the rest.
In your configuration, the first passdb block uses PAM for
authentication, and the first userdb block uses the system's passwd
file. The second passdb and userdb blocks, which use a Dovecot-specific
passwd file and static userdb, will only be used if PAM authentication
fails.
If some of your users are defined in the Dovecot passwd file and not in
the system's passwd file, they will not be able to authenticate because
Dovecot will stop at the first passdb and userdb blocks.
To fix this, you could merge your passdb and userdb blocks into single
blocks that use both PAM and passwd-file/static methods. Here's an example:
passdb {
driver = pam
}
passdb {
args = /etc/dovecot/passwd
driver = passwd-file
}
userdb {
driver = passwd
}
userdb {
args = uid=vmail gid=vmail home=/home/vmail/%u
driver = static
}
--
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
On 9/6/23 09:17, Richard Troy wrote: However if your dovecot SASL is broken, say always permitting access with or without correct password, then there will be a problem I DID find a discrepancy: smtpd_helo_restrictions did NOT have permit_sasl_authenticated. I made the change, of course and with that done, am now going to open the ports and renew my vigil for relays! Fingers crossed! Thanks, Jeremy - even if it doesn't work, it's a good clean shot at a fix! And, if that was it, it's easy to see how that could be overlooked. . . Richard smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination Is most useful to you. The defer means reject after a delay - tarpitting This leaves you to verify if the sasl authentication is working correctly. That is a real exercise as it has multiple config elements in dovecot and then PAM /etc/pam.d/dovecot then calls multiple configs in /etc/pam.d and specifically /etc/pam.d/common-auth in my case I am using only the local user database for dovecot grep -v '^#' common-auth auth [success=1 default=ignore] pam_unix.so nullok auth requisite pam_deny.so auth required pam_permit.so It is quite possible to use remote servers such as ldap and kerberos rather than your local user table ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
On 9/6/23 07:25, Richard Troy wrote:
The relaying only started and stopped when Dovecot was turned on or off.
Isn't it true that Dovecot performs an authentication function for
inbound connect requests, the successful of which then may use the
submission mechanism from what Postfix takes to be an internal
connection to send emails? Is this mistaken?
However, I get your point and I've spent a lot of work on that area.
And, you may well be right that that's where I need to turn - that is,
to Postfix. Thanks for the link.
The problem will likely be postfix.
However if your dovecot SASL is broken, say always permitting access
with or without correct password, then there will be a problem
This is part of my postfix configuration aand my system doesn't relay.
The key lines are all those with
permit_sasl_authenticated
---
relay_domains = $mydestination
unknown_local_recipient_reject_code = 550
unknown_client_reject_code = 550
#home_mailbox = Maildir/
mailbox_transport = lmtp:unix:private/dovecot-lmtp
#transport_maps = hash:/etc/postfix/transport
# Junk controls
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
# reject_rbl_client dnsbl-1.uceprotect.net
# reject_rbl_client cbl.abuseat.org
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_pipelining
reject_non_fqdn_recipient
reject_unknown_recipient_domain
reject_unauth_destination
permit
# reject_rbl_client zen.spamhaus.org
# reject_rbl_client bl.spamcop.net
smtpd_sender_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unknown_sender_domain
reject_unknown_reverse_client_hostname
reject_unknown_client_hostname
smtpd_data_restrictions =
reject_unauth_pipelining,
permit
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
# Redirect mail
smtp_header_checks = regexp:/etc/postfix/smtp_header_checks
# Reduce the time Postfix will sit idle after a client issues STARTTLS.
smtpd_starttls_timeout = 60s
# Renegotiate TLS sessions every hour.
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
# Enable SMTP AUTH.
# This requires TLS on port 25
smtpd_sasl_auth_enable = yes
# Don't allow anonymous logins. DO NOT add noplaintext here, or
# authentication with saslauthd will become impossible.
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
# Some clients send malformed AUTH commands.
broken_sasl_auth_clients = yes
# Only allow AUTH when a TLS session is active, to reduce the
# possibility for password and message body snooping.
smtpd_tls_auth_only = yes
# Tarpitting
smtpd_error_sleep_time = 50
smtpd_hard_error_limit = 2
smtpd_soft_error_limit = 1
smtpd_junk_command_limit = 10
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mailbox_size_limit = 0
recipient_delimiter = +
inet_protocols = all
compatibility_level = 3.6
policy-spf_time_limit = 3600s
html_directory = /usr/share/doc/postfix/html
# Milter configuration
milter_default_action = accept
milter_protocol = 6
smtpd_milters = local:opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters
smtputf8_enable = no
postscreen_access_list = permit_mynetworks
postscreen_blacklist_action = enforce
postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = swl.spamhaus.org*-4
list.dnswl.org=127.0.[0..255].[1..3]*-5
zen.spamhaus.org=127.0.[1..2].[0..255]*3
b.barracudacentral.org*2
bl.spameatingmonkey.net
bl.spamcop.net
postscreen_dnsbl_threshold = 2
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
--
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Possible hack via doveadm
On 14/5/23 23:29, Daniel Miller via dovecot wrote:
I only allow explicit service traffic through. IMAPS, SMTPS, etc. If
doveadm is communicating via the IMAP(S) ports then all I can do via
firewall is block countries. Which of course I can but I'm asking
about any additional hardening for Dovecot itself.
You can set up a doveadm service that requires client certificates
service doveadm {
inet_listener {
port = 12345
}
ssl = yes
ssl_cert = ___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Possible hack via doveadm
On 14/5/23 09:14, Daniel L. Miller via dovecot wrote: May 12 15:45:58 cloud1 dovecot: doveadm(194.165.16.78): Error: doveadm client not compatible with this server (mixed old and new binaries?) May 13 03:44:31 cloud1 dovecot: doveadm(45.227.254.48): Error: doveadm client not compatible with this server (mixed old and new binaries?) Since I don't recognize those IPs, the first is out of Panama and the other is Belize, I assume these are hostile attackers trying to exploit something. How can I defend against this? Set up a firewall rule that only allows access from an IP range you control. For any other source, simply drop the connection. You can get really fancy and use port forwarding using ssh to connect from remote but appear as localhost to the server. This access can be configured in dovecot as well as firewall Jeremy ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
