Re: Throttling pop3-login connections
Am 08.08.2014 um 20:11 schrieb Alex: Hi, I have a fedora20 system with dovecot-2.2.13 running various services, including pop3. I'm noticing some users are frequently hamming pop3, and wondered if this was normal, or something I should be investigating? Aug 8 14:05:20 email dovecot: pop3-login: Login: user=user1, method=PLAIN, rip=97.77.115.121, lip=192.168.1.1, mpid=30509, session=DnRtDCIAUQBhTXN5 Aug 8 14:05:21 email dovecot: pop3(user1): Disconnected: Logged out top=0/0, retr=0/0, del=0/15, size=5693601 So it is immediately followed by a logout, but when there are 50 of them successively in a five minute period, I wondered if it is creating unnecessary overhead on the system? I suppose this most likely is how they have their email client configured, but wondered if some throttling would be necessary? Any advice would be most appreciated. Thanks, Alex depends if this are your users, or if its brute force pop3 has not much overhead, to fight brute force use fail2ban or you may have a look here https://sys4.de/de/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/ but be aware with NAT by blocking ips Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
postfix-dovecot Auth USER lookup failed
I'm running postfix + dovecot on my CentOS-7 home server. When I send myself a message I get this error message in /var/log/maillog: Aug 9 12:59:57 alfred postfix/lmtp[31336]: B0D02220748: to=t...@localhost.gayleard.eu, orig_to=tim@localhost, relay=alfred.gayleard.eu[private/dovecot-lmtp], delay=475, delays=474/0.03/0.02/0.09, dsn=4.3.0, status=deferred (host alfred.gayleard.eu[private/dovecot-lmtp] said: 451 4.3.0 t...@localhost.gayleard.eu Internal error occurred. Refer to server log for more information. (in reply to RCPT TO command)) and in /var/log/dovecot I read Aug 09 13:13:03 auth-worker(31472): Error: passwd(t...@localhost.gayleard.eu): getpwnam() failed: Address family not supported by protocol Aug 09 13:13:03 lmtp(31470): Error: user t...@localhost.gayleard.eu: Auth USER lookup failed It seems that USER is set to t...@localhost.gayleard.eu rather than tim . I am including the line mailbox_transport = lmtp:unix:private/dovecot-lmtp in /etc/postfix/main.cf . If I omit this line so that postfix sends email directly to ~/Maildir I have no problem - except that spam is not being filtered. I give the output of postconf -n below. Any advice or enlightenment gratefully received. Output of postconf -n -- [tim@alfred ~]$ cat /tmp/postconf alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id sleep 5 home_mailbox = Maildir/ html_directory = no inet_interfaces = all inet_protocols = all mail_owner = postfix mailbox_transport = lmtp:unix:private/dovecot-lmtp mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain mydomain = gayleard.eu myhostname = alfred.gayleard.eu mynetworks = 192.168.0.0/24, 127.0.0.0/8 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES relay_domains = relayhost = out.alice.it sample_directory = /usr/share/doc/postfix-2.6.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/password smtp_sasl_security_options = smtpd_milters = unix:/var/run/spamass-milter/postfix/sock unknown_local_recipient_reject_code = 550 -- -- Timothy Murphy e-mail: gayleard /at/ eircom.net School of Mathematics, Trinity College, Dublin 2, Ireland
Re: postfix-dovecot Auth USER lookup failed
On 08/09/2014 11:30 AM, Timothy Murphy wrote: I'm running postfix + dovecot on my CentOS-7 home server. When I send myself a message I get this error message in /var/log/maillog: Aug 9 12:59:57 alfred postfix/lmtp[31336]: B0D02220748: to=t...@localhost.gayleard.eu, orig_to=tim@localhost, relay=alfred.gayleard.eu[private/dovecot-lmtp], delay=475, delays=474/0.03/0.02/0.09, dsn=4.3.0, status=deferred (host alfred.gayleard.eu[private/dovecot-lmtp] said: 451 4.3.0 t...@localhost.gayleard.eu Internal error occurred. Refer to server log for more information. (in reply to RCPT TO command)) and in /var/log/dovecot I read Aug 09 13:13:03 auth-worker(31472): Error: passwd(t...@localhost.gayleard.eu): getpwnam() failed: Address family not supported by protocol Aug 09 13:13:03 lmtp(31470): Error: user t...@localhost.gayleard.eu: Auth USER lookup failed It seems that USER is set to t...@localhost.gayleard.eu rather than tim . I am including the line mailbox_transport = lmtp:unix:private/dovecot-lmtp in /etc/postfix/main.cf . your (missing) `doveconf -n` doesn't contain auth_username_format = %Ln. So, edit your conf.d/10-auth.conf and set auth_username_format to %Ln. Regards, Pascal -- The trapper recommends today: cafefeed.1422...@localdomain.org
Re: Throttling pop3-login connections
Hi, I have a fedora20 system with dovecot-2.2.13 running various services, including pop3. I'm noticing some users are frequently hamming pop3, and wondered if this was normal, or something I should be investigating? Aug 8 14:05:20 email dovecot: pop3-login: Login: user=user1, method=PLAIN, rip=97.77.115.121, lip=192.168.1.1, mpid=30509, session=DnRtDCIAUQBhTXN5 Aug 8 14:05:21 email dovecot: pop3(user1): Disconnected: Logged out top=0/0, retr=0/0, del=0/15, size=5693601 So it is immediately followed by a logout, but when there are 50 of them successively in a five minute period, I wondered if it is creating unnecessary overhead on the system? I suppose this most likely is how they have their email client configured, but wondered if some throttling would be necessary? Any advice would be most appreciated. Thanks, Alex depends if this are your users, or if its brute force pop3 has not much overhead, to fight brute force use fail2ban Yes, I've implemented fail2ban, and it's working pretty well. It does now look like brute force. When/if they complain to the helpdesk, we'll deal with it then. https://sys4.de/de/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/ This is also helpful, thanks. Thanks, Alex
Converting maildir files from quoted-printable to 8bit
How to easily convert maildir files from (single part) quoted-printable to 8bit encoding? [I would like to ease access to sent/posted archives.]
Dovecot v2.2 FTS is not indexing text/html emails...
Hi, I am not sure its intended or a fault in the newest Dovecot versions. I have been using Dovecot v1.2.15 on Debian squeeze and FTS is working as expected. When I search a quoted string very good, I get 107 results including plain and HTML emails which have this phrase. In order to compare the benefits of lucene over squat, I recently started testing dovecot v2.2.13 on Debian Sid with the same maildir content. But now the same search very good yielded just 8 results. I thought it could be some problem with lucene so I tried switching to squat and got 107 results again. After this I deleted the old squat search index files created by v1.2.15 and re-indexed the mail-box by using doveadm index command. Now the same squat search is giving 8 results just as lucene. So I have realized that its not a problem with just lucene but FTS in newer dovecot isn't indexing those emails which have Content-type as text/html. Thus if a mail is like this: Content-Type: text/html bHe is very good./b It isn't shown in search by the squat indexes created using dovecot v2.2.13. I have done further testing on some sample emails which confirmed this behavior. Why is this so? -Regards, Akash
Re: Defer email via LMTP when there is 'no space left on device' instead of rejecting it
On 05 Aug 2014, at 14:45, Christian Rohmann crohm...@netcologne.de wrote: may I PING this subject once again to maybe get Timo's opinion. On 23.07.2014 11:26, Christian Rohmann wrote: Bounced / rejected messages for something that will be usually be resolved very quickly and the messages can then be delivered after all is just not very nice for users. The admin made a mistake and the users have to deal with the problems is just not my approach. But in the end I don't even want to argue that rejecting the messages might not be a valid behavior for some. That's why I suggested to make this configurable, just like the quota behavior. I'd really like to hear Timo's view on having lmtp do a (configurable) DEFER when the disk is full which is, most likely, a temporary error. My opinion: It shouldn't be configurable - it should always cause temporary error. The only thing I'm slightly worried about is if write failures because of user's filesystem quota full will always return EDQUOT error for write() instead of ENOSPC, but I suppose they will in any modern OS. And it would require changing MAIL_ERROR_NOSPACE definition a bit inside Dovecot, but that's less of an issue. I'll change this once I have some timeenergy. Patches welcome also.
Re: Defer email via LMTP when there is 'no space left on device' instead of rejecting it
On 10 Aug 2014, at 01:19, Timo Sirainen t...@iki.fi wrote: I'd really like to hear Timo's view on having lmtp do a (configurable) DEFER when the disk is full which is, most likely, a temporary error. My opinion: It shouldn't be configurable - it should always cause temporary error. The only thing I'm slightly worried about is if write failures because of user's filesystem quota full will always return EDQUOT error for write() instead of ENOSPC, but I suppose they will in any modern OS. And it would require changing MAIL_ERROR_NOSPACE definition a bit inside Dovecot, but that's less of an issue. And a bit more generic statement about anything related to errors in Dovecot: Problems that admins can solve are temporary errors for users and the'll need an error logged. Problems that are caused by users themselves (like over quota) are usually not temporary errors and they shouldn't have errors logged (since admin can't usually do anything about them anyway).
Re: Defer email via LMTP when there is 'no space left on device' instead of rejecting it
On Sun, Aug 10, 2014 at 01:31:47AM +0300, Timo Sirainen wrote: Problems that admins can solve are temporary errors for users and the'll need an error logged. Problems that are caused by users themselves (like over quota) are usually not temporary errors and they shouldn't have errors logged (since admin can't usually do anything about them anyway). Depends on the environment; in many cases, the admin could, or may even be expected to, raise the quota. Also, you're assuming that users will be able to interpret an error message, even a clear one, correctly, and that the MUA will always convey the error to the user. I am not sure either of these assumptions are always true. Logging is important so when the user calls in with I can't do X, the admin can see why quickly. w
