Oops
Am 2013-06-10 08:43, schrieb Timo Röhling: Am 2013-06-10 07:13, schrieb j...@soe.se: I have written a small policy service. But I whish to not use it for those emails which are rejected. Only permited emails (permit_mynetworks and permit_sasl_authenticated) Any ideas? smtpd_recipient_restrictions = check_policy_service unix:private/policy, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject Restrictions are evaluated in order. Move the check_policy_service statement between reject_unauth_destination and reject. Disregard that. I missed a "not" in your question. :-)
RE: check_policy_service not for rejected?
>Any ideas? > >smtpd_recipient_restrictions = check_policy_service unix:private/policy, > permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_destination, > reject Move the policy check to the end of the list, just before the reject. D.
Re: check_policy_service not for rejected?
Am 2013-06-10 07:13, schrieb j...@soe.se: I have written a small policy service. But I whish to not use it for those emails which are rejected. Only permited emails (permit_mynetworks and permit_sasl_authenticated) Any ideas? smtpd_recipient_restrictions = check_policy_service unix:private/policy, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject Restrictions are evaluated in order. Move the check_policy_service statement between reject_unauth_destination and reject.
check_policy_service not for rejected?
Hello, I have written a small policy service. But I whish to not use it for those emails which are rejected. Only permited emails (permit_mynetworks and permit_sasl_authenticated) Any ideas? smtpd_recipient_restrictions = check_policy_service unix:private/policy, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject /Jonas
Re: 'reject_non_fqdn_helo_hostname' and 'reject_invalid_helo_hostname' neccessary?!
On 6/9/2013 12:00 PM, Viktor Dukhovni wrote: > On Mon, Jun 10, 2013 at 01:17:19AM +1000, Nikolas Kallis wrote: > >> Is using 'reject_non_fqdn_helo_hostname' and >> 'reject_invalid_helo_hostname' even neccessary when using >> 'reject_unknown_helo_hostname'? > > You seem to have decided that the client HELO name is a silver > bullet against spam and the evils of RFC non-conformance. This is > far from true. Don't waste your time on this. The last of these > three restrictions is almost neve used, it is neither safe to use > (too much legitimate email rejected) nor very effective. > > More fine-grained table lookups (regexp, or even exact matches) on > the actual HELO name sent are far more likely to be safe and be > somewhat useful (still not worth the effort in most cases IMHO). > Perhaps we can move on to another topic. I guess it depends on whose effort is expended. ;) Nikolas, you can stop much bot spam by querying the rDNS and HELO strings against this table of fully qualified residential/consumer looking rDNS patterns. Some spam bots do a reverse lookup and use the string in HELO, so it can be effective in HELO checks as well. There are people on this list using this table for one of both. http://www.hardwarefreak.com/fqrdns.pcre Instructions for the former are in the file. To use with HELO, simply add this directly after the rDNS restriction: check_helo_access pcre:/etc/postfix/fqrdns.pcre Give it a try. Replace REJECT with 'WARN_IF_REJECT' if you'd like to test it without actually rejecting any clients. If you like it, simply overwrite with the original file. -- Stan
Re: relay problem
Quoting wie...@porcupine.org: Per olof Ljungmark: Quoting wie...@porcupine.org: > Per olof Ljungmark: >> Hi all, >> >> Hopefully I can explain this good enough for someone to understand and >> perhaps even suggest a solution. >> >> Our email system is built from a LDAP directory that contains all the >> necessary information about our users. A box receives mail from the MX's >> and routes it according to the information in the directory. >> >> If the mail is for a user present in the directory it gets delivered to >> the mail server, if it is for an external address it is delivered to the >> outgoing box etc., everything dandy. >> >> Now we face a setup where we have users present in the same tree as our >> normal mail users, but with addresses external to us. They must have the >> "mail" attribute that we normally use for delivery to our mail server. >> We cannot separate them to a different tree because it is actually a mix >> of internal and external users for a different purpose than mail routing. > > Use a transport map. > > internalu...@example.com -> internal delivery agent or internal host > externalu...@example.com -> external host > > http://www.postfix.org/postconf.5.html#transport_maps > http://www.postfix.org/transport.5.html > >Wietse Yes, but the problem seems to be that the address is rewritten to uid@mail.server before the transport maps comes into play. If mail.server is the "wrong" server (i.e. the name of an internal server for users that deliver elsewhere) then that is the problem. The transport map solution is for the case that the address is not mutilated. Indeed. Will start tomorrow to sketch a rework of the system so that the rewrite is done where it should. Thank you both for your input. //per
Re: relay problem
Per olof Ljungmark: > Quoting wie...@porcupine.org: > > > Per olof Ljungmark: > >> Hi all, > >> > >> Hopefully I can explain this good enough for someone to understand and > >> perhaps even suggest a solution. > >> > >> Our email system is built from a LDAP directory that contains all the > >> necessary information about our users. A box receives mail from the MX's > >> and routes it according to the information in the directory. > >> > >> If the mail is for a user present in the directory it gets delivered to > >> the mail server, if it is for an external address it is delivered to the > >> outgoing box etc., everything dandy. > >> > >> Now we face a setup where we have users present in the same tree as our > >> normal mail users, but with addresses external to us. They must have the > >> "mail" attribute that we normally use for delivery to our mail server. > >> We cannot separate them to a different tree because it is actually a mix > >> of internal and external users for a different purpose than mail routing. > > > > Use a transport map. > > > > internalu...@example.com -> internal delivery agent or internal host > > externalu...@example.com -> external host > > > > http://www.postfix.org/postconf.5.html#transport_maps > > http://www.postfix.org/transport.5.html > > > > Wietse > > Yes, but the problem seems to be that the address is rewritten to > uid@mail.server before the transport maps comes into play. If mail.server is the "wrong" server (i.e. the name of an internal server for users that deliver elsewhere) then that is the problem. The transport map solution is for the case that the address is not mutilated. Wietse
SOLVED - Re: Server hard reset, everything seems ok except local list (mailman) mail
On 2013-06-09 11:39 AM, wie...@porcupine.org (Wietse Venema) wrote: Charles Marcus: Would verbose logs maybe shed more light on this? No, that would not explain why a connection fails with resource temporarily available, because THAT problem happens inside the KERNEL. What would help is increase the KERNEL system-wide (not: per process) limits on the number of file handles, network sockets, and so on. What would also help is running lsof and understanding what your sockets are tied up with. Wietse (and everyone else who tried to help) - thank you thank you thank you! Googling details for that last clue stick was enough to strike a chord in my memory... I was sure I was using the same kernel, but after some googling, I remembered something... I *had* built a new kernel a little while back (even labeled it NEW), and changed it to the default, but did this *without testing it*. Well, apparently I changed *something* in it that was causing this problem, as switching back to the original kernel solved the problem... Thanks again! -- Best regards, Charles
Thread Kill (reject_non_fqdn_helo_hostname etc.)
Wietse Venema: > This thread is terminated, as is the poster's membership. > > Wietse
Re: 'reject_non_fqdn_helo_hostname' and 'reject_invalid_helo_hostname' neccessary?!
This thread is terminated, as is the poster's membership. Wietse
Re: 'reject_non_fqdn_helo_hostname' and 'reject_invalid_helo_hostname' neccessary?!
Nikolas Kallis: > On 10/06/13 03:11, Viktor Dukhovni wrote: > > On Mon, Jun 10, 2013 at 03:07:59AM +1000, Nikolas Kallis wrote: > > > Is using 'reject_non_fqdn_helo_hostname' and > 'reject_invalid_helo_hostname' even neccessary when using > 'reject_unknown_helo_hostname'? > >>> > >>> You seem to have decided that the client HELO name is a silver > >>> bullet against spam and the evils of RFC non-conformance. > >> > >> You're wrong. > > > > Since you already know what you're doing, and don't need any advice, > > there is not much point in continuing this thread. Good luck. > > > LOL. You are a fuckin retard. We don't tolerate this language on this list. I hereby terminate your subscription and ask other moderators to terminate you should you decide to return. Wietse
Re: 'reject_non_fqdn_helo_hostname' and 'reject_invalid_helo_hostname' neccessary?!
On 10/06/13 03:11, Viktor Dukhovni wrote: On Mon, Jun 10, 2013 at 03:07:59AM +1000, Nikolas Kallis wrote: Is using 'reject_non_fqdn_helo_hostname' and 'reject_invalid_helo_hostname' even neccessary when using 'reject_unknown_helo_hostname'? You seem to have decided that the client HELO name is a silver bullet against spam and the evils of RFC non-conformance. You're wrong. Since you already know what you're doing, and don't need any advice, there is not much point in continuing this thread. Good luck. LOL. You are a fuckin retard.
Re: relay problem
Quoting Viktor Dukhovni : On Sun, Jun 09, 2013 at 07:00:54PM +0200, Per olof Ljungmark wrote: Quoting wie...@porcupine.org: >http://www.postfix.org/postconf.5.html#transport_maps >http://www.postfix.org/transport.5.html > >Wietse Yes, but the problem seems to be that the address is rewritten to uid@mail.server before the transport maps comes into play. Yes, you're shooting yourself in the foot. Don't do that. Instead of imposing a fixed mailbox address domain on all users retrieve the right value from LDAP or leave the user's original address alone. Your existing rewrite rule is the problem. I tend to agree with that. Please understand that it was implemented quite some time ago in the Postfix 1.x days and have worked ever since, this is the first serious issue I've seen since. But perhaps it is time for a complete rewrite... uggg. Thanks,
Re: 'reject_non_fqdn_helo_hostname' and 'reject_invalid_helo_hostname' neccessary?!
On Mon, Jun 10, 2013 at 03:07:59AM +1000, Nikolas Kallis wrote: > >>Is using 'reject_non_fqdn_helo_hostname' and > >>'reject_invalid_helo_hostname' even neccessary when using > >>'reject_unknown_helo_hostname'? > > > >You seem to have decided that the client HELO name is a silver > >bullet against spam and the evils of RFC non-conformance. > > You're wrong. Since you already know what you're doing, and don't need any advice, there is not much point in continuing this thread. Good luck. -- Viktor.
Re: 'reject_non_fqdn_helo_hostname' and 'reject_invalid_helo_hostname' neccessary?!
On 10/06/13 03:00, Viktor Dukhovni wrote: On Mon, Jun 10, 2013 at 01:17:19AM +1000, Nikolas Kallis wrote: Is using 'reject_non_fqdn_helo_hostname' and 'reject_invalid_helo_hostname' even neccessary when using 'reject_unknown_helo_hostname'? You seem to have decided that the client HELO name is a silver bullet against spam and the evils of RFC non-conformance. Your wrong. it is neither safe to use (too much legitimate email rejected) nor very effective. Of course it is safe. It will only reject host names that don't exist and or don't have a DNS A or MX record. RFC 2821 requires these things. If a client is not meeting these requirements, then their e-mail server is not configured correctly and I don't want to deal with it. Thanks for the advice anyhow.
Re: relay problem
On Sun, Jun 09, 2013 at 07:00:54PM +0200, Per olof Ljungmark wrote: > Quoting wie...@porcupine.org: > > >http://www.postfix.org/postconf.5.html#transport_maps > >http://www.postfix.org/transport.5.html > > > > Wietse > > Yes, but the problem seems to be that the address is rewritten to > uid@mail.server before the transport maps comes into play. Yes, you're shooting yourself in the foot. Don't do that. Instead of imposing a fixed mailbox address domain on all users retrieve the right value from LDAP or leave the user's original address alone. Your existing rewrite rule is the problem. -- Viktor.
Re: relay problem
Quoting wie...@porcupine.org: Per olof Ljungmark: Hi all, Hopefully I can explain this good enough for someone to understand and perhaps even suggest a solution. Our email system is built from a LDAP directory that contains all the necessary information about our users. A box receives mail from the MX's and routes it according to the information in the directory. If the mail is for a user present in the directory it gets delivered to the mail server, if it is for an external address it is delivered to the outgoing box etc., everything dandy. Now we face a setup where we have users present in the same tree as our normal mail users, but with addresses external to us. They must have the "mail" attribute that we normally use for delivery to our mail server. We cannot separate them to a different tree because it is actually a mix of internal and external users for a different purpose than mail routing. Use a transport map. internalu...@example.com -> internal delivery agent or internal host externalu...@example.com -> external host http://www.postfix.org/postconf.5.html#transport_maps http://www.postfix.org/transport.5.html Wietse Yes, but the problem seems to be that the address is rewritten to uid@mail.server before the transport maps comes into play. When em...@example.com is rewritten to userID@mail.server we would have to have one transport switch for each user that need the special treatment. However, there are several solutions I've been thinking of that I did not try yet, one would be to move the rewriting to the mail server, another is clever LDAP filters. //per
Re: 'reject_non_fqdn_helo_hostname' and 'reject_invalid_helo_hostname' neccessary?!
On Mon, Jun 10, 2013 at 01:17:19AM +1000, Nikolas Kallis wrote: > Is using 'reject_non_fqdn_helo_hostname' and > 'reject_invalid_helo_hostname' even neccessary when using > 'reject_unknown_helo_hostname'? You seem to have decided that the client HELO name is a silver bullet against spam and the evils of RFC non-conformance. This is far from true. Don't waste your time on this. The last of these three restrictions is almost neve used, it is neither safe to use (too much legitimate email rejected) nor very effective. More fine-grained table lookups (regexp, or even exact matches) on the actual HELO name sent are far more likely to be safe and be somewhat useful (still not worth the effort in most cases IMHO). Perhaps we can move on to another topic. -- Viktor.
Re: Server hard reset, everything seems ok except local list (mailman) mail
Charles Marcus: > Would verbose logs maybe shed more light on this? No, that would not explain why a connection fails with resource temporarily available, because THAT problem happens inside the KERNEL. What would help is increase the KERNEL system-wide (not: per process) limits on the number of file handles, network sockets, and so on. What would also help is running lsof and understanding what your sockets are tied up with. Wietse
Re: Server hard reset, everything seems ok except local list (mailman) mail
Would verbose logs maybe shed more light on this? On 2013-06-09 10:21 AM, Charles Marcus wrote: To recap the warnings I'm getting when the problem occurs... The postfix/master warning only shows up rarely - 11 times since I got the system back up, and within 5 or 10 minutes (but usually with 5 or 10 seconds) of postfix being restarted: postfix/master[6406]: warning: master_wakeup_timer_event: service tlsmgr(private/tlsmgr): Resource temporarily unavailable Then these (never accompanied by the postfix/master warning that I have seen) whenever I try to send to the lists-all list (easiest way to test): warning: connect to transport private/local: Resource temporarily unavailable warning: connect to transport private/retry: Resource temporarily unavailable
Re: Server hard reset, everything seems ok except local list (mailman) mail
On 2013-06-09 10:21 AM, Charles Marcus wrote: postfix/master[6406]: warning: master_wakeup_timer_event: service tlsmgr(private/tlsmgr): Resource temporarily unavailable with respect to this warning, I've found a reference to postfix needing a non-blocking random device... Could /dev/urandom be messed up somehow?
'reject_non_fqdn_helo_hostname' and 'reject_invalid_helo_hostname' neccessary?!
Is using 'reject_non_fqdn_helo_hostname' and 'reject_invalid_helo_hostname' even neccessary when using 'reject_unknown_helo_hostname'? The way I see it is if there is no FQDN and the host name is invalid, then 'reject_unknown_helo_hostname' won't be able to verify the DNS A and MX record anyway, and would reject the mail... Right?
Re: Show username for "SASL LOGIN authentication failed:"?
On 2013-06-09 10:34 AM, Zhang Huangbin wrote:
On Sunday, June 9, 2013 at 10:09 PM, Charles Marcus wrote:
Dovecot uses login_log_format_elements to determine what it logs for
login attempts... you'll find the variables it supports here:
http://wiki2.dovecot.org/Variables?highlight=%28login_log_format_elements%29
Mine (which logs the username) looks like:
login_log_format_elements = user=<%u> method=%m rip=%r lport=%{lport}
mpid=%e %c session=<%{session}>
This works for IMAP/POP3/Managesieve services provided by Dovecot, and
logged in Dovecot log file, but it won't appear in Postfix/Dovecot log files for
SMTP service.
Hmmm... well, I definitely see the usernames on my system (postfix+dovecot) for
both successful and unsuccessful logins...
successful login:
2013-06-09T10:50:38-04:00 myhost postfix-587/smtpd[5807]: E9482B73AF4:
client=client.example.com[192.168.1.110], sasl_method=PLAIN,
sasl_username=myu...@example.com
bad password:
2013-06-09T11:02:38-04:00 myhost postfix-587/smtpd[5903]: connect from
myclient.example.com[###.###.###.###]
2013-06-09T11:02:38-04:00 myhost dovecot: auth-worker(5904):
sql(validu...@example.com,###.###.###.###): Password mismatch
invalid username:
2013-06-09T11:01:45-04:00 myhost postfix-587/smtpd[5903]: connect from
myclient.example.com[###.###.###.###]
2013-06-09T11:01:50-04:00 myhost dovecot: auth-worker(5904):
sql(invalidu...@example.com,###.###.###.###): unknown user
So, it is possible...
Re: Show username for "SASL LOGIN authentication failed:"?
On Sun, 09 Jun 2013 16:44:13 +0300 Bogdan Enache articulated: > Unfortunately if I try lowering it from 10 to 3 I will receive like 20 > phone calls a day about users that don't know how to check when CAPS > LOCK is on or off. 20 calls from 20,000 users would be insignificant. From 100 users, a troubling amount. Install an automated answering system to handle routine calls like that. As far as determining if the CAPS LOCK is set, there is one thing I have learned in life, "You cannot fix stupid." You are always going to have a percentage of users who cannot chew gum and walk at the same time. -- Jerry ✌ postfix-u...@seibercom.net _ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
Re: Show username for "SASL LOGIN authentication failed:"?
On Sunday, June 9, 2013 at 10:09 PM, Charles Marcus wrote:
>
> Dovecot uses login_log_format_elements to determine what it logs for
> login attempts... you'll find the variables it supports here:
>
> http://wiki2.dovecot.org/Variables?highlight=%28login_log_format_elements%29
>
> Mine (which logs the username) looks like:
>
> login_log_format_elements = user=<%u> method=%m rip=%r lport=%{lport}
> mpid=%e %c session=<%{session}>
>
This works for IMAP/POP3/Managesieve services provided by Dovecot, and
logged in Dovecot log file, but it won't appear in Postfix/Dovecot log files for
SMTP service.
Zhang Huangbin
iRedMail: free, open source mail server solution for Red Hat
Enterprise Linux, CentOS, Scientific Linux, Debian, Ubuntu,
openSUSE, FreeBSD, OpenBSD. http://www.iredmail.org/
Re: Server hard reset, everything seems ok except local list (mailman) mail
Thanks very much Victor for your time, it is much appreciated. Before my responses to your questions, I believe I've narrowed this down (with the help of Mark Sapiro on the mailman list). It only happens when multiple messages are simultaneously sent invoking postfix/local - which according to Mark is what happens when a message is sent to a mailman list that has multiple members that are lists. Real email addresses are delivered by virtual, but the list addresses generate a new message using local. I've confirmed that individual messages invoking postfix/local also work fine, (ie, individual emails from cron jobs (8 from last night and this morning), etc): 2013-06-09T03:13:30-04:00 moria postfix/local[9769]: 42C22AB25C7: to=, orig_to=, relay=local, delay=0.18, delays=0.07/0/0/0.11, dsn=2.0.0, status=sent (forwarded as 51836AB1A82) To recap the warnings I'm getting when the problem occurs... The postfix/master warning only shows up rarely - 11 times since I got the system back up, and within 5 or 10 minutes (but usually with 5 or 10 seconds) of postfix being restarted: postfix/master[6406]: warning: master_wakeup_timer_event: service tlsmgr(private/tlsmgr): Resource temporarily unavailable Then these (never accompanied by the postfix/master warning that I have seen) whenever I try to send to the lists-all list (easiest way to test): warning: connect to transport private/local: Resource temporarily unavailable warning: connect to transport private/retry: Resource temporarily unavailable Ok, now to your questions... On 2013-06-08 6:13 PM, Viktor Dukhovni wrote: Make sure all databases (built via postalias, ...) are in good working order. Rebuild them all from the plaintext source files. I ran newaliases (I've never used the postalias command directly), and checked /etc/mail/aliases and everything looks normal there, restarted postfix, but the problem persists. My primary userdb is in mysql, but haven't had any issues with it - and then of course the mailman aliases. So, I may be wrong but I don't think I have any databases built by postalias - unless there are some internal/default ones that are created/used by postfix at install time? Also, to confirm - you are saying that userdb problems/corruption can cause these warnings? That will be good info to know for future reference. Use netstat/lsof to find processes listening on or connected to various sockets in /var/spool/postfix/private, which sockets have the most processes? Hmmm... maybe significant? netstat lsof | grep /var only shows one (at least when I ran the command): unix 3 [ ] STREAM CONNECTED 148439 /var/run/mysqld/mysqld.sock unix 3 [ ] STREAM CONNECTED 148408 /var/run/mysqld/mysqld.sock unix 3 [ ] STREAM CONNECTED 148407 /var/run/mysqld/mysqld.sock unix 3 [ ] STREAM CONNECTED 149106 /var/spool/postfix/private/auth unix 3 [ ] STREAM CONNECTED 148344 /var/run/mysqld/mysqld.sock unix 3 [ ] STREAM CONNECTED 148345 /var/run/dovecot/auth-worker unix 3 [ ] STREAM CONNECTED 149040 /var/run/dovecot/login/login unix 3 [ ] STREAM CONNECTED 148583 /var/run/dovecot/anvil-auth-penalty unix 3 [ ] STREAM CONNECTED 33348 /var/run/dovecot/anvil unix 3 [ ] STREAM CONNECTED 33797 /var/run/dovecot/config Running the command with one of the messages stuck in the queue shows the same output. Relevant things to check: - Kernel resource limits, perhaps you need to run fewer processes. First, remember, this system had been running fine for years with the current settings and kernel. But I did try changing the default_process_limit to 10 with no help. - Which program appears the largest number of times in "ps" output. root, then postfix (but dovecot runs as postfix user, and most of the 'postfix' processes are dovecot/imap): # ps aux|grep postfix postfix 3619 0.0 0.1 25228 2876 ?S05:43 0:00 dovecot/imap postfix 4074 0.0 0.1 25220 2692 ?S07:13 0:00 dovecot/imap postfix 4177 0.0 0.1 26324 3940 ?S07:26 0:00 dovecot/imap postfix 4227 0.0 0.1 25600 3244 ?S07:29 0:00 dovecot/imap postfix 4291 0.0 0.2 26616 4128 ?S07:37 0:00 dovecot/imap root 4562 0.0 0.0 20588 1144 ?Ss 07:57 0:00 /usr/libexec/postfix/master -w postfix 4563 0.0 0.1 38236 2088 ?S07:57 0:00 pickup -l -t unix -u postfix 4564 0.0 0.1 38424 2404 ?S07:57 0:00 qmgr -l -t unix -u postfix 4610 0.0 0.1 38244 2180 ?S08:00 0:00 tlsmgr -l -t unix -u postfix 4814 0.0 0.2 27940 5604 ?S08:32 0:01 dovecot/imap postfix 4825 0.0 0.3 31768 7428 ?S08:32 0:00 dovecot/imap postfix 4932 0.0 0.
Re: Show username for "SASL LOGIN authentication failed:"?
On 2013-06-08 6:09 AM, Bogdan Enache wrote:
But how can I also show the username that was tried in the logs? I want
to see:
1. Which user keeps entering the wrong password.
2. What user is someone else trying to hijack.
Since you left out the critical fact that you are using dovecot sasl, I
didn't respond to this.
Dovecot uses login_log_format_elements to determine what it logs for
login attempts... you'll find the variables it supports here:
http://wiki2.dovecot.org/Variables?highlight=%28login_log_format_elements%29
Mine (which logs the username) looks like:
login_log_format_elements = user=<%u> method=%m rip=%r lport=%{lport}
mpid=%e %c session=<%{session}>
Hope this helps...
Charles
Re: Show username for "SASL LOGIN authentication failed:"?
Hi list. On 09.06.2013 03:35, LuKreme wrote: > On 08 Jun 2013, at 04:09 , Bogdan Enache wrote: > >> But how can I also show the username that was tried in the logs? I want >> to see: >> 1. Which user keeps entering the wrong password. >> 2. What user is someone else trying to hijack. > Are you using courier authlib? > > It has a DEBUG_LOGIN setting which will put the login AND password in the > logs. I believe it will log incorrect password attempts as well. No, I'm using Dovecot SASL login. > >> I have fail2ban installed and working (banning IPs for 1 hour after 10 >> incorrect passwords) > 10? That seems overly generous. > > My fail2ban was set at 1 hour for 3 failed attempts and a day for 10. > Unfortunately if I try lowering it from 10 to 3 I will receive like 20 phone calls a day about users that don't know how to check when CAPS LOCK is on or off. So I guess it's not easily doable using Dovecot SALS, right? Thanks!
Re: Show username for "SASL LOGIN authentication failed:"?
Benny Pedersen: > Bogdan Enache skrev den 2013-06-08 12:09: > > > mx1 postfix/smtpd[1069]: warning: unknown[89.xx.xx.xx]: SASL LOGIN > > authentication failed: UGFzc3dvcmQ6 > > Which is perfectly normal. > > normal in what way ? > > i have seen this here aswell with that user > > > But how can I also show the username that was tried in the logs? I > > want > > to see: > > 1. Which user keeps entering the wrong password. > > UGFzc3dvcmQ6 is a user that uses somekind of tor networking where port > 25 is not gething direct, so we all see him using more then one ip in > postfix In this universe, the string 'UGFzc3dvcmQ6' is the base64-encoded value of the string 'Password:'. Wietse
