too many errors after AUTH
Hi, During the night, for many hours, we logged several thousand of such entries(always the same server): Nov 7 04:04:52 vmail postfix/smtpd[3100]: connect from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:52 vmail postfix/smtpd[3197]: connect from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:53 vmail postfix/smtpd[3321]: connect from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:54 vmail postfix/smtpd[3184]: too many errors after AUTH from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:54 vmail postfix/smtpd[3184]: disconnect from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:54 vmail postfix/smtpd[3176]: too many errors after AUTH from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:54 vmail postfix/smtpd[3176]: disconnect from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:55 vmail postfix/smtpd[3184]: connect from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:55 vmail postfix/smtpd[3176]: connect from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:55 vmail postfix/smtpd[3100]: too many errors after AUTH from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:55 vmail postfix/smtpd[3100]: disconnect from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:55 vmail postfix/smtpd[3197]: too many errors after AUTH from mail.videco.com.ar[190.220.14.235] Nov 7 04:04:55 vmail postfix/smtpd[3197]: disconnect from mail.videco.com.ar[190.220.14.235] Since this server does not accept unauthenticated smtp connectionsexcept only from our gateway serverand requires AUTHfor all others,do the above log entries depictfailed login (SASL-Auth) attempts, i.e. brute-force attempts? If so, can we configure Postfix to restrict the number of such connections, or it is advised to use a policy server (e.g. like postfwd)? Please advise. Thanks, Nick
Re: too many errors after AUTH
On 7/11/2012 3:46 μμ, Nikolaos Milas wrote: connectionsexcept only from our gateway serverand requires AUTHfor all others,do the above log entries depictfailed login As a side note: sorry for the word jamming in the message; it is due to a relatively recent Thunderbird bug (those interested may see: https://bugzilla.mozilla.org/show_bug.cgi?id=778547), which -like other editor-related bugs- doesn't seem very easy to fix. Nick
Re: too many errors after AUTH
On 7/11/2012 3:46 μμ, Nikolaos Milas wrote: Since this server does not accept unauthenticated smtp connections except only from our gateway server and requires AUTH for all others Server config: [root@vmail etc]# postconf -n alias_database = hash:/etc/postfix/aliases, hash:/etc/postfix/aliases.d/virtual_aliases alias_maps = hash:/etc/aliases allowed_gein = check_client_access cidr:/etc/postfix/gein_admin_ips.cidr,reject allowed_iaasars = check_client_access cidr:/etc/postfix/iaasars_admin_ips.cidr,reject allowed_list1 = check_client_access cidr:/etc/postfix/client2.cidr,reject allowed_list2 = permit_mynetworks,reject allowed_meteo = check_client_access cidr:/etc/postfix/meteo_admin_ips.cidr,reject broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix controlled_senders = check_sender_access hash:/etc/postfix/blocked_senders 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 xxgdb $daemon_directory/$process_name $process_id & sleep 5 default_process_limit = 25 delay_logging_resolution_limit = 3 deliver_lock_attempts = 40 dovecot_destination_recipient_limit = 1 home_mailbox = Maildir/ html_directory = no inet_interfaces = all inet_protocols = ipv4, ipv6 local_header_rewrite_clients = static:all mail_owner = postfix mailbox_command = /usr/lib/dovecot/deliver mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 41943040 milter_default_action = accept mydestination = $myhostname, localhost.$mydomain, localhost mydomain = noa.gr myhostname = vmail.noa.gr mynetworks = 195.251.204.0/24, 195.251.202.0/24, 195.251.203.0/24, 194.177.194.0/24, 194.177.195.0/24, 127.0.0.0/8, 195.251.5.0/24, [2001:648:2011::]/48, 83.212.5.24/29, [2001:648:2ffc:1115::]/64 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = $smtpd_milters parent_domain_matches_subdomains = queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES recipient_canonical_maps = hash:/etc/postfix/domainrecipientmap relay_domains = $mydestination sample_directory = /usr/share/doc/postfix-2.3.3/samples sender_canonical_maps = hash:/etc/postfix/domainsendermap sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject smtpd_delay_reject = yes smtpd_milters = inet:127.0.0.1:8891 smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/protected_destinations, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10040, reject_unknown_recipient_domain, reject_unverified_recipient smtpd_restriction_classes = controlled_senders,allowed_list1,allowed_list2,allowed_iaasars,allowed_meteo,allowed_gein smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_CAfile = /etc/pki/tls/certs/chain-180.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/pki/tls/certs/cert-180.pem smtpd_tls_exclude_ciphers = DES,3DES,MD5,aNULL,AES128,CAMELLIA128 smtpd_tls_key_file = /etc/pki/tls/private/key.pem smtpd_tls_loglevel = 1 smtpd_tls_mandatory_ciphers = high smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tls_preempt_cipherlist = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 unverified_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/aliases, hash:/etc/postfix/aliases.d/virtual_aliases, proxy:ldap:/etc/postfix/ldap-alias-vacation.cf, proxy:ldap:/etc/postfix/ldap-aliases.cf virtual_gid_maps = static:500 virtual_mailbox_base = /home/vmail/ virtual_mailbox_domains = $mydomain, space.$mydomain, admin.$mydomain, nestor.$mydomain, gein.$mydomain, meteo.$mydomain, technet.$mydomain, astro.$mydomain virtual_mailbox_limit = 0 virtual_mailbox_maps = proxy:ldap:/etc/postfix/ldap-users.cf virtual_transport = dovecot virtual_uid_maps = static:500
Re: too many errors after AUTH
On Wed, Nov 07, 2012 at 03:46:38PM +0200, Nikolaos Milas wrote: > During the night, for many hours, we logged several thousand of such > entries(always the same server): > > Nov 7 04:04:52 vmail postfix/smtpd[3100]: connect from > mail.videco.com.ar[190.220.14.235] > Nov 7 04:04:55 vmail postfix/smtpd[3100]: too many errors after > AUTH from mail.videco.com.ar[190.220.14.235] > Nov 7 04:04:55 vmail postfix/smtpd[3100]: disconnect from > mail.videco.com.ar[190.220.14.235] Is this a submission port (587) or smtp (25)? You should use "-o syslog_name=postfix/submission" for submission in master.cf, to distinguish logging of smtp vs. submission. ISTM that if submission, and if Linux, some relatively simple iptables -m recent rules might provide some protection by rate limiting the number of new connections from one host. (That's my new idea for the day. I might not be awake enough yet. :) ) > Since this server does not accept unauthenticated smtp > connections except only from our gateway server and requires > AUTH for all others,do the above log entries depict failed > login (SASL-Auth) attempts, i.e. brute-force attempts? Broken software of some kind, most likely malicious, I think. > If so, can we configure Postfix to restrict the number of such > connections, or it is advised to use a policy server (e.g. like > postfwd)? I'm not sure if anvil(8) could do much here, but postfwd would be a good option, indeed. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: mail alias
Hi Nick Thank you very much. it worked, i'm able to restrict. -Ramesh From: Nikolaos Milas To: Ramesh Cc: Postfix users Sent: Wednesday, 7 November 2012 12:55 PM Subject: Re: mail alias On 7/11/2012 8:07 πμ, Ramesh wrote: > to block mail to alias from external n Hi, See: http://www.postfix.org/RESTRICTION_CLASS_README.html Regards, Nick
Re: too many errors after AUTH
On 7/11/2012 6:10 μμ, /dev/rob0 wrote: Is this a submission port (587) or smtp (25)? You should use "-o syslog_name=postfix/submission" for submission in master.cf, to distinguish logging of smtp vs. submission. Thanks for the reply. I do; this is smtp, not submission. ISTM that if submission, and if Linux, some relatively simple iptables -m recent rules might provide some protection by rate limiting the number of new connections from one host. (That's my new idea for the day. I might not be awake enough yet. :) ) I decided to expand my fail2ban filtering as follows: failregex = reject: RCPT from (.*)\[\]: 550 reject: RCPT from (.*)\[\]: 554 reject: RCPT from (.*)\[\]: 450 too many errors after AUTH from (.*)\[\] This works, but I am not sure if I should do it or not. Any other feedback regarding this situation will be useful. Regards, Nick
Re: too many errors after AUTH
On 11/7/2012 10:50 AM, Nikolaos Milas wrote: > On 7/11/2012 6:10 μμ, /dev/rob0 wrote: > >> Is this a submission port (587) or smtp (25)? You should use "-o >> syslog_name=postfix/submission" for submission in master.cf, to >> distinguish logging of smtp vs. submission. > > Thanks for the reply. > > I do; this is smtp, not submission. > >> ISTM that if submission, and if Linux, some relatively simple >> iptables -m recent rules might provide some protection by rate >> limiting the number of new connections from one host. (That's my new >> idea for the day. I might not be awake enough yet. :) ) >> > > I decided to expand my fail2ban filtering as follows: > > failregex = reject: RCPT from (.*)\[\]: 550 > reject: RCPT from (.*)\[\]: 554 > reject: RCPT from (.*)\[\]: 450 > too many errors after AUTH from (.*)\[\] > > This works, but I am not sure if I should do it or not. > > Any other feedback regarding this situation will be useful. > > Regards, > Nick The "too many errors after AUTH" implies an AUTH command was sent (info earlier in the log if it was successful or not), THEN the client sent enough junk to exceed either $smtpd_junk_command_limit or $smtpd_hard_error_limit. Seems to me that this is some sort of broken client, not necessarily a break-in attempt. Of course, broken client usually means a spambot. You can check your log for things like "authentication failed" for a failed AUTH, or "sasl_username=" when successful.My fail2ban filter contains: warning: .*\[\](?::\d+)?: SASL \S+ authentication failed: As for blocking "too many errors after AUTH" hosts, that probably won't break anything, but not sure I'd bother unless they get really annoying. -- Noel Jones
Re: Technical question to Postfix
On 4/11/2012 8:17 μμ, Wietse Venema wrote: Or use "reject_unverified_recipient", which uses a cache of previous decisions so it won't hammer the mailbox server. A clarification: Does the cache of "reject_unverified_recipient" decisions include the result of "relay_recipient_maps" lookups? This might be esp. useful in case the "relay_recipient_maps" setting is blank, in which case the final destination server(s) is (are) queried for the recipient (and should reply with a 550 if the recipient does not exist). Thanks, Nick
Re: too many errors after AUTH
On 7/11/2012 7:47 μμ, Noel Jones wrote:
You can check your log for things like "authentication failed" for a
failed AUTH, or "sasl_username=" when successful.My fail2ban filter
contains:
warning: .*\[\](?::\d+)?: SASL \S+ authentication failed:
Thanks Noel,
I am using:
failregex = (?i): warning: [-._\w]+\[\]: SASL
(?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(:
[A-Za-z0-9+/]*={0,2})?$
I found it some time, and it works fine.
It is configured as:
[sasl-iptables]
enabled = true
filter = sasl
backend = polling
action = iptables-multiport[name=SASLAuth, port="smtp,submission",
protocol=tcp]
logpath = /var/log/maillog
maxretry = 10
findtime = 600
bantime = 1800
(Actually it was:
action = iptables[name=sasl, port=smtp, protocol=tcp]
and I changed it to multiport now.)
Nick
Re: Technical question to Postfix
>> Or use "reject_unverified_recipient", which uses a cache >> of previous decisions so it won't hammer the mailbox server. > > A clarification: Does the cache of "reject_unverified_recipient" decisions > include the result of "relay_recipient_maps" lookups? > > This might be esp. useful in case the "relay_recipient_maps" setting is > blank, in which case the final destination server(s) is (are) queried for the > recipient (and should reply with a 550 if the recipient does not exist). I did some tests yesterday. Removing relay_reciepient_maps and virtual_alias_maps completely. It works, but I have the feeling it takes a little bit longer than asking LDAP over proxymap. Furthermore I want the possibility of email forwarding, so I re-added both options. But in general that works. -Christian Rößner -- [*] 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, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Playing nice with Yahoo.com
Our non-profit organization has been sending out both occasional and mass-emails for several years without any trouble to our patrons. (These are opt-in and not spam). We use SPF text records but do not use DKIM. Starting last week, the queue started piling up with messages to yahoo.com. We're getting: "delivery temorarily suspended: lost connection with mta5.am0.yahoodns.net[98.136.216.26] while sending end of data -- message may be sent more than once". But the message stays in the queue and never gets delivered. I suspect that yahoo has internally blacklisted us, but only from that one email server on our end. Here's why I think that: 1. Emails from another MS Exchange server go through fine. 2. Emails from a newer postfix server with a different IP address but the same HELO name are rejected. 3. Changing myhostname and smtp_helo_name to a new name on that new server causes the emails to start going through. I could just change the name and be done with it, but I'm worried yahoo will do it to us again and I want to play nice with them. What can I do to limit the rate at which emails are delivered to them? We're on postfix 2.2.10.
Re: Technical question to Postfix
Nikolaos Milas: > On 4/11/2012 8:17 ??, Wietse Venema wrote: > > > Or use "reject_unverified_recipient", which uses a cache > > of previous decisions so it won't hammer the mailbox server. > > A clarification: Does the cache of "reject_unverified_recipient" > decisions include the result of "relay_recipient_maps" lookups? As documented, reject_unverified_recipient caches whether or not recipient address verification was successful. It caches the RESULT. It DOES NOT cache HOW Postfix came to that conclusion. It is as fast or faster then LDAP, once the result is in cache. Wietse
Re: Playing nice with Yahoo.com
Peter Pauly: > I suspect that yahoo has internally blacklisted us, but only from that > one email server on our end. Here's why I think that: Instead of speculating, why not read the Yahoo postmaster guideline. http://www.google.com/?q=yahoo+postmaster Wietse
Mail queue not being cleared per setting
Folks, We had to restore a mailing list (mailman) from an old backup. This means it included hundreds of now-invalid email addresses. As such, I set up mailmain to remove addresses on the first b0unce, and set up postfix to b0unce outgoing messages on the first refusal (I thought). The way I did this was to set: b0unce_queue_lifetime=0. I checked postconf -n, and the variable is set to 0. However, I'm noticing that postfix seems to be completely ignoring this setting. B0unces stay in the mailqueue for days, and that in turn bloats the processes postfix needs to run. How do I get postfix to b0unce all nondeliverable emails *immediately*? (please excuse the "b0unce", but I had to make it past the list filters, which consider the regular word to be an admin command) -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Re: Mail queue not being cleared per setting
On 11/7/2012 2:47 PM, Josh Berkus wrote: > Folks, > > We had to restore a mailing list (mailman) from an old backup. This > means it included hundreds of now-invalid email addresses. > > As such, I set up mailmain to remove addresses on the first b0unce, and > set up postfix to b0unce outgoing messages on the first refusal (I thought). > > The way I did this was to set: b0unce_queue_lifetime=0. I checked > postconf -n, and the variable is set to 0. This controls how long an undeliverable NDR stays in the queue. It has no effect on when the NDR is generated. > > However, I'm noticing that postfix seems to be completely ignoring this > setting. B0unces stay in the mailqueue for days, and that in turn > bloats the processes postfix needs to run. > > How do I get postfix to b0unce all nondeliverable emails *immediately*? Non-deliverable mail is returned to sender when either the remote server gives a 5xx "undeliverable" response, or $max_queue_lifetime expires. Undelivered mail will hang around in the queue if the remote server gives a 4xx "retry" response, or the remote server exists but is unreachable, or if you've set soft_bounce=yes. So which is it? -- Noel Jones
Re: Mail queue not being cleared per setting
> Non-deliverable mail is returned to sender when either the remote > server gives a 5xx "undeliverable" response, or $max_queue_lifetime > expires. > > Undelivered mail will hang around in the queue if the remote server > gives a 4xx "retry" response, or the remote server exists but is > unreachable, or if you've set soft_bounce=yes. So which is it? Oh, thanks! So if I set $max_queue_lifetime lower, then it should clear out those 4xx bounces? What about unreachable target servers? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Re: Mail queue not being cleared per setting
On 11/07/2012 10:03 PM, Josh Berkus wrote: Non-deliverable mail is returned to sender when either the remote server gives a 5xx "undeliverable" response, or $max_queue_lifetime expires. Undelivered mail will hang around in the queue if the remote server gives a 4xx "retry" response, or the remote server exists but is unreachable, or if you've set soft_bounce=yes. So which is it? Oh, thanks! So if I set $max_queue_lifetime lower, then it should clear out those 4xx bounces? What about unreachable target servers? Noel asked you which of the possible reasons he listed causes your queue to fill up. 4xx are not bounces - they are deferrals, which are then queued. Inspect your logs closely to find out why. -- J.
Re: Mail queue not being cleared per setting
On 11/7/12 6:37 PM, Jeroen Geilman wrote: > On 11/07/2012 10:03 PM, Josh Berkus wrote: >>> Non-deliverable mail is returned to sender when either the remote >>> server gives a 5xx "undeliverable" response, or $max_queue_lifetime >>> expires. >>> >>> Undelivered mail will hang around in the queue if the remote server >>> gives a 4xx "retry" response, or the remote server exists but is >>> unreachable, or if you've set soft_bounce=yes. So which is it? >> Oh, thanks! So if I set $max_queue_lifetime lower, then it should clear >> out those 4xx bounces? What about unreachable target servers? >> > > Noel asked you which of the possible reasons he listed causes your queue > to fill up. > 4xx are not bounces - they are deferrals, which are then queued. Well, it's actually both. I have both deferrals and unreachable servers. It's not soft_bounce, though. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Re: Mail queue not being cleared per setting
On 11/7/2012 8:47 PM, Josh Berkus wrote: > On 11/7/12 6:37 PM, Jeroen Geilman wrote: >> On 11/07/2012 10:03 PM, Josh Berkus wrote: Non-deliverable mail is returned to sender when either the remote server gives a 5xx "undeliverable" response, or $max_queue_lifetime expires. Undelivered mail will hang around in the queue if the remote server gives a 4xx "retry" response, or the remote server exists but is unreachable, or if you've set soft_bounce=yes. So which is it? >>> Oh, thanks! So if I set $max_queue_lifetime lower, then it should clear >>> out those 4xx bounces? What about unreachable target servers? >>> >> >> Noel asked you which of the possible reasons he listed causes your queue >> to fill up. >> 4xx are not bounces - they are deferrals, which are then queued. > > Well, it's actually both. I have both deferrals and unreachable > servers. It's not soft_bounce, though. > max_queue_lifetime will reduce the amount of time undeliverable mail hangs around in the queue, regardless of the reason. You can set it lower, but with caution -- postfix can't tell the difference between a domain that will never work and some legit domain that happens to be down for maintenance/power/whatever temporary reason. The default is 5 days, with good reason. for domain "squatters" that register a misspelled popular domain with an A record but no mail service, handle them by adding a transport entry pointing to the error: service. This will cause problems if the domain in question ever goes legit... you can decide how likely that is yourself. Some popular ones with my users; I expect others have different local favorites. # transport comcoast.net error:5.1.2 maybe you mean comcast.net hotmani.com error:5.1.2 maybe you mean hotmail.com kincle.com error:5.1.2 maybe you mean kindle.com htomail.com error:5.1.2 hotmail.com not htomail.com hotemail.com error:5.1.2 hotmail.com not hotemail.com vzwpics.com error:5.1.2 maybe you meant "vzwpix.com" vzxpix.com error:5.1.2 maybe you meant "vzwpix.com" guno.com error:5.1.2 maybe you meant "juno.com" xomcast.net error:5.1.2 try "comcast.net" instead c0mcast.net error:5.1.2 try "comcast.net" instead cdomcast.neterror:5.1.2 try "comcast.net" instead cherter.net error:5.1.2 try "charter.net" instead charther.neterror:5.1.2 try "charter.net" instead vahoo.com error:5.1.2 did you mean yahoo.com? at.net error:5.1.2 try "att.net" instead -- Noel Jones
