Re: 'reject_non_fqdn_helo_hostname' not working?!
Nikolas, please do not reply off-list. Always reply to the list unless there is a good reason not to (such as a shouting argument with another user, a thread drifts wildly off topic, you are asked to, etc). On 6/7/2013 11:20 PM, Nikolas Kallis wrote: > On 08/06/13 14:09, Stan Hoeppner wrote: >> On 6/7/2013 10:50 PM, Nikolas Kallis wrote: >> >>> Also, thanks for the information about >>> 'reject_unknown_reverse_client_hostname'. I can't tolerate accidently >>> rejecting spam. I have recently learn't that a PTR record is not a DNS >>> requirement, and as so, will receive mail from clients that do not have >>> a PTR record setup for their host. >> >> This is a mistake. RFC may not, but SMTP BCP requires rDNS. You'll see >> why before too long. >> > No, its not a mistake. Read RFC 2821 and you'll see it makes no > reference for a host needing a valid PTR record. RFC 1035 (domain name > system) doesn't either. As you gain experience running a mail server, and gain knowledge from this list, you will realize that while RFCs guide the development of the internet and set standards, they are not the only standards, and/or sometimes they fall short of what is needed in the real world. You will find that there are things widely implemented due to Best Current Practices that are not mentioned as SHOULD or MUST in RFCs. -- Stan
Re: relay problem
On 2013-06-08 05:24, Nikolas Kallis wrote: > On 08/06/13 03:48, Per olof Ljungmark wrote: >> 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. >> >> So far we have not been able to (at least not a Friday afternoon) figure >> out how to make the mail router understand that mail for a specific >> address/domain should *not* be delivered as usual but relayed directly >> to outgoing even if this email address is present in the directory. >> >> The LDAP query is very simple: >> >> query_filter = >> (&(accountStatus=Active)(|(mail=%s)(mailalternateaddress=%s))) >> result_filter = %u@mail.server >> result_attribute = uid >> scope = sub >> >> This together with a transport map that directs * to outgoing is all >> there is. >> >> I was hoping for a relatively simple way to fix this, so far I only >> dreamed up rather complicated scenarios... >> >> Thanks for reading, >> >> //per >> >> PS. I had some trouble posting: >> >> "BOUNCE postfix-users@postfix.org: Admin request: /^subject:\s*help\b/i" >> >> The word 'help' is not allowed? >> DS. >> >> > I am not an expert with complex MTA routing and quite noob with what > your doing, but from the sounds of it and my visualisation, you will > need to use a separate MTA system to handle the 'external' e-mail (what > ever that is), as there is no way to differentiate between internal and > external as they both qualify for delivery. Yes, I realsize that it might be impossible. "external" means addresses that are in the directory but does not have a mailbox. Actually, both should qualify but must be routed differently, internal to mailbox and external to outgoing.
Re: 'reject_non_fqdn_helo_hostname' not working?!
On 08/06/13 17:49, Stan Hoeppner wrote: Nikolas, please do not reply off-list. Always reply to the list unless there is a good reason not to (such as a shouting argument with another user, a thread drifts wildly off topic, you are asked to, etc). On 6/7/2013 11:20 PM, Nikolas Kallis wrote: On 08/06/13 14:09, Stan Hoeppner wrote: On 6/7/2013 10:50 PM, Nikolas Kallis wrote: Also, thanks for the information about 'reject_unknown_reverse_client_hostname'. I can't tolerate accidently rejecting spam. I have recently learn't that a PTR record is not a DNS requirement, and as so, will receive mail from clients that do not have a PTR record setup for their host. This is a mistake. RFC may not, but SMTP BCP requires rDNS. You'll see why before too long. No, its not a mistake. Read RFC 2821 and you'll see it makes no reference for a host needing a valid PTR record. RFC 1035 (domain name system) doesn't either. As you gain experience running a mail server, and gain knowledge from this list, you will realize that while RFCs guide the development of the internet and set standards, they are not the only standards, and/or sometimes they fall short of what is needed in the real world. You will find that there are things widely implemented due to Best Current Practices that are not mentioned as SHOULD or MUST in RFCs. I have been replying e-mail addresses I in the reply-to only. I think Postfix's Majordomo has an issue. I noticed it was acting a bit funny in regards to this myself yesterday, but haven't had time to getting around brining it up. Following the RFC is the only way in maintaining standards. I am aware RFC 2821 is out of date in modern times, but its no excuse for lapsing on professionalism and going off doing your own thing - I mean, you can, but it just creates problems.
RE: Postfix master dead but pid file exists
Please tell me how to find out that some other component has locked the pid files. I have done the following things to find out :- [root@drmail1 ~]# /etc/init.d/postfix status master dead but pid file exists [root@drmail1 ~]# ps -ef | grep postfix root 1412 1 0 Jun07 ?00:00:00 /usr/libexec/postfix/master postfix 1415 1412 0 Jun07 ?00:00:00 qmgr -l -t fifo -u postfix 16286 1412 0 13:37 ?00:00:00 pickup -l -t fifo -u root 16452 16416 0 13:52 pts/000:00:00 grep postfix [root@drmail1 ~]# Regards, Jayanta -Original Message- From: Nikolas Kallis [mailto:n...@nikolaskallis.com] Sent: Saturday, June 08, 2013 9:47 AM To: jayanta.gh...@cesc.co.in Subject: Re: Postfix master dead but pid file exists On 08/06/13 14:05, jayanta.gh...@cesc.co.in wrote: > Dear List, > > We have a mail server running on RHEL 6.2 with the following components :- > 1.Postfix > 2.Openldap > 3.Courier-authlib > 4.Courier-imap > 5.SASL > 6.Maildrop > > The problem is the postfix status is showing master dead but pid file > exists after sometime. The main.cf file and the output of postconf d > is attached herein. I have also gone through the log files but could > not find any errors. > > Please help me resolve this issue. > > > > Thanks & Regards, > Jayanta Ghosh > It may be that one of the following components has read and locked the pid file.
Show username for "SASL LOGIN authentication failed:"?
Hi. When an user inputs an incorrect password, I have the following message in the logs: mx1 postfix/smtpd[1069]: warning: unknown[89.xx.xx.xx]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Which is perfectly normal. 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. I need this because a user of mine was hijacked a few days ago. I have fail2ban installed and working (banning IPs for 1 hour after 10 incorrect passwords), but looking through the logs in the last month I realized this might have been a distributed attack actually. Running postfix 2.5.9. Thanks!
Re: Postfix master dead but pid file exists
jayanta.gh...@cesc.co.in: > Please tell me how to find out that some other component has locked the > pid files. I have done the following things to find out :- > > [root@drmail1 ~]# /etc/init.d/postfix status > master dead but pid file exists Please file a bug report with REDHAT. They have broken Postfix status reports. I am not responsible for bugs that other people add. With Postfix as released by me: # postfix status postfix/postfix-script: the Postfix mail system is running: PID: 1205 # ps ax | grep master | grep -v grep 1205 ?? Ss 0:14.23 /usr/libexec/postfix/master -w And on a system running multiple Postfix instances: # postfix status postfix/postfix-script: the Postfix mail system is running: PID: 1366 postfix-m1/postfix-script: the Postfix mail system is running: PID: 1601 # ps ax | grep master | grep -v grep 1366 ?? Is 0:14.40 /usr/libexec/postfix/master -w 1601 ?? Is 0:31.61 /usr/libexec/postfix/master -w Wietse
Server hard reset, everything seems ok except local list (mailman) mail
Hello everyone, Need some assistance... Had a power problem that resulted in a hard reset of our mail server. Everything seems to be back up and running, postfix is delivering all of our mail, and successfully sending outbound mail (all using virtual transport), with one exception - mailman list traffic... I've asked on the mailman list, but since the problem appears to be related to these postfix errors, I'm asking here too. First - I saw this error one time when I was restarting postfix, but I don't see it every time: postfix/master[29913]: warning: master_wakeup_timer_event: service tlsmgr(private/tlsmgr): Resource temporarily unavailable And when I try to send an email to one of our mailman lists, here's what I see every time: 2013-06-08T06:49:34-04:00 myhost postfix/pickup[29914]: 2C8D7B7D633: uid=207 from= orig_id=D55D7B7D175 2013-06-08T06:49:34-04:00 myhost postfix/cleanup[30010]: 2C8D7B7D633: message-id=<51b30786.7020...@media-brokers.com> 2013-06-08T06:49:34-04:00 myhost postfix/qmgr[29915]: 2C8D7B7D633: from=, size=4185, nrcpt=6 (queue active) 2013-06-08T06:49:34-04:00 myhost postfix/qmgr[29915]: warning: connect to transport private/local: Resource temporarily unavailable 2013-06-08T06:49:34-04:00 myhost postfix/qmgr[29915]: warning: connect to transport private/retry: Resource temporarily unavailable 2013-06-08T06:49:34-04:00 myhost postfix/qmgr[29915]: 2C8D7B7D633: to=, orig_to=, relay=none, delay=1205, delays=1205/0.07/0/0, dsn=4.3.0, status=deferred (mail transport unavailable) When the system first came back up, I was getting similar errors for virtual mail delivery as well, but running check-permissions fixed that: Successful inbound virtual delivery: 2013-06-08T07:01:09-04:00 myhost postfix-25/smtpd[30409]: 923B1B83222: client=relay-eu1.maildistiller.com[5.135.34.120] 2013-06-08T07:01:09-04:00 myhost postfix/cleanup[30414]: 923B1B83222: message-id=<20130608110105.7566c1...@interface1.dco.mdlocal> 2013-06-08T07:01:09-04:00 myhost postfix/qmgr[30157]: 923B1B83222: from=, size=9443, nrcpt=1 (queue active) 2013-06-08T07:01:09-04:00 myhost postfix/virtual[30415]: 923B1B83222: to=, relay=virtual, delay=0.31, delays=0.27/0/0/0.05, dsn=2.0.0, status=sent (delivered to maildir) 2013-06-08T07:01:09-04:00 myhost postfix/qmgr[30157]: 923B1B83222: removed Successful outbound delivery: 2013-06-08T07:21:26-04:00 myhost postfix-587/smtpd[30546]: connect from myclient.atl.media-brokers.com[192.168.1.110] 2013-06-08T07:21:26-04:00 myhost dovecot: auth-worker(30550): mysql(localhost): Connected to database pfa_234_new 2013-06-08T07:21:26-04:00 myhost postfix-587/smtpd[30546]: BCD0CB83232: client=myclient.atl.media-brokers.com[192.168.1.110], sasl_method=PLAIN, sasl_username=valid-u...@media-brokers.com 2013-06-08T07:21:26-04:00 myhost postfix/cleanup[30555]: BCD0CB83232: message-id=<51b313b6.2050...@media-brokers.com> 2013-06-08T07:21:26-04:00 myhost postfix/qmgr[30157]: BCD0CB83232: from=, size=722, nrcpt=1 (queue active) 2013-06-08T07:21:28-04:00 myhost postfix-587/smtpd[30546]: disconnect from myclient.atl.media-brokers.com[192.168.1.110] 2013-06-08T07:21:28-04:00 myhost postfix/qmgr[30157]: BCD0CB83232: removed 2013-06-08T07:21:28-04:00 myhost postfix/smtp[30556]: BCD0CB83232: to=, relay=filtered.maildistiller.com[176.31.241.80]:25, delay=1.5, delays=0.11/0.01/0.93/0.49, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 212F3FC) 2013-06-08T07:21:29-04:00 myhost dovecot: imap(cmar...@media-brokers.com): Disconnected: Disconnected in IDLE in=1381 out=362685 I've run postfix set-permissions again since and the only thing that is displayed is (same as the first time): myhost : Sat Jun 08, 06:54:54 : ~ # postfix set-permissions chown: cannot access '/etc/postfix/LICENSE': No such file or directory myhost : Sat Jun 08, 06:58:44 : ~ Would really appreciate some suggestions on where to look (googling as we speak)... Thanks, -- Best regards, Charles
Re: Show username for "SASL LOGIN authentication failed:"?
Bogdan Enache: > Hi. > When an user inputs an incorrect password, I have the following message > in the logs: > mx1 postfix/smtpd[1069]: warning: unknown[89.xx.xx.xx]: SASL LOGIN > authentication failed: UGFzc3dvcmQ6 > Which is perfectly normal. 'UGFzc3dvcmQ6' decodes into 'Password:'. That's part of the SASL LOGIN protocol. There are a dozen different protocols, and those protocols are implemented by the Cyrus SASL library or Dovecot authentication server. Postfix normally retrieves the username from the Cyrus SASL library AFTER successful authentication. The libsasl "documentation" does not promise that such information is available after login failure. > 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. This requires adding code that looks up the username after authentication failure, and finding out whether that information is available at all. Another approach would be to rate-limit AUTH commands (by duplicating the code for rate-limiting the STARTTLS command). That would stop a dictionary attack from one bad client, but not from a botnet. Or, one could run a network sniffer and rip the information from the TCP packets. Wietse
Re: Server hard reset, everything seems ok except local list (mailman) mail
Charles Marcus: > 2013-06-08T06:49:34-04:00 myhost postfix/cleanup[30010]: 2C8D7B7D633: > message-id=<51b30786.7020...@media-brokers.com> > 2013-06-08T06:49:34-04:00 myhost postfix/qmgr[29915]: 2C8D7B7D633: > from=, size=4185, nrcpt=6 (queue active) > 2013-06-08T06:49:34-04:00 myhost postfix/qmgr[29915]: warning: connect > to transport private/local: Resource temporarily unavailable > 2013-06-08T06:49:34-04:00 myhost postfix/qmgr[29915]: warning: connect > to transport private/retry: Resource temporarily unavailable [the same error on the virtual socket disappeared after a while] The Postfix warranty does not cover file system corruption, so I can only provide generic system repair suggestions. If Solaris or *BSD, boot single-user mode and fsck the file system. If Linux, do whatever your distro requires to force a full fsck. If fsck does not resolve the issue, then the file system repair program messed up the UNIX-domain sockets. Stop Postfix, remove the 'private' and 'public' queue directories, and restart Postfix. If that doesn't help look for a spare computer system. Wietse
Re: relay problem
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
Re: Investigating iPhone Compatibility
On 6/7/2013 4:26 PM, DTNX Postmaster wrote: On Jun 8, 2013, at 00:47, Noel Jones wrote: On 6/7/2013 3:28 PM, Asai wrote: Greetings, We're starting to incorporate iPhone users into our email system. Sometimes we seem to be having trouble with mail being delayed for a long time before the phone will connect to the server and send the mail. I don't really have any idea what this is. I've looked through the logs, but I'm not seeing anything really telling. I have recently turned on TLS debugging and hope to glean something useful from that. We have SSL turned on on the iPhone, but do not have the so-called wrapper mode turned on, and it seems to be working fine in most cases. Does anyone have any experience with managing iPhones and Postfix who can share with me something of value? Thank you. I only have a dozen or so iPhone users and don't use one myself, so don't consider me an expert on this. It's also possible my users have these problems and just haven't said anything. Anyway, here's some random thoughts... - don't use tls debug higher than level 1 unless you are willing to dig into openssl source code. - make sure your master.cf submission entry has -o syslog_name=postfix/submission so you can tell what port they're connecting to. - if they're connecting to port 25, postscreen will interfere, causing significant delays or preventing it from working at all. - enable the wrappermode/smtps port if you haven't already. Seems some of my iPhone users connect on that port despite instructions that make no mention of it. I don't know why, and don't really care; there is no difference in security/speed/whatever. I always enable smtps because it reduces end-user frustration. The only downside is "it's not a standard". Use the same settings as submission except for the addition of -o smtpd_tls_wrappermode=yes -o syslog_name=postfix/smtps HTH, and have a good weekend. The Mail.app applications on iOS (iPhones or iPads) or OS X will attempt to autodetect the port to connect to; 25, 465, and 587. It works just fine over the submission port (587) without enabling the SMTPS port (465), and the autodetection can be overridden in the settings if needs be; Settings > Mail, Contacts, Calendars > [accountname] > Account > Outgoing Mail Server (SMTP) > Primary Server > Server Port That's the case on iOS 6; earlier versions might differ slightly in option names, but offer a similar override. Make sure your own SMTP server is in fact the primary server, by the way, and not one of the 'Other SMTP Servers'. This is what the submission service definition on one of our servers looks like; == # Submission service for use by our clients submission inetn - n - 128 smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_data_restrictions=permit_sasl_authenticated,reject -o smtpd_proxy_filter=127.0.0.1:10025 == It is important to note that we have seperate relay servers; the mailbox servers clients connect to never open anything but the submission port (587), and there is therefore never a problem with clients trying to connect to postscreen on port 25. A similar setup can be achieved by moving the submission service to a seperate IP address, if possible. Do however make sure that it is in fact your Postfix configuration, and not a DNS issue of some sort. Test with an iPhone or iPad that has the server port set manually, and see if the problem disappears. If it does not, the problem might be elsewhere. Other than that, there should not really be any compatibility issues with iOS devices talking to Postfix, as long as your DNS and such is in order. HTH, Jona Thank you for your generous responses. I do have the client's iPhone set to port 587, however, I'm still wondering if the iPhone is trying to connect via SMTPS or port 25 (which is not available). I would like to try setting up SMTP wrapper mode, but does that in any way disable or interfere with the submission port and TLS? From reading the Postfix docs I was not sure whether it would override of TLS or not. Also, I will check in to the DNS situation. --Asai
Re: Investigating iPhone Compatibility
On Jun 8, 2013, at 17:16, Asai wrote: > On 6/7/2013 4:26 PM, DTNX Postmaster wrote: >> The Mail.app applications on iOS (iPhones or iPads) or OS X will >> attempt to autodetect the port to connect to; 25, 465, and 587. It >> works just fine over the submission port (587) without enabling the >> SMTPS port (465), and the autodetection can be overridden in the >> settings if needs be; >> >> Settings > Mail, Contacts, Calendars > [accountname] > Account > >> Outgoing Mail Server (SMTP) > Primary Server > Server Port >> >> That's the case on iOS 6; earlier versions might differ slightly in >> option names, but offer a similar override. Make sure your own SMTP >> server is in fact the primary server, by the way, and not one of the >> 'Other SMTP Servers'. >> >> This is what the submission service definition on one of our servers >> looks like; >> >> == >> # Submission service for use by our clients >> submission inetn - n - 128 smtpd >> -o smtpd_tls_security_level=encrypt >> -o smtpd_sasl_auth_enable=yes >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject >> -o smtpd_data_restrictions=permit_sasl_authenticated,reject >> -o smtpd_proxy_filter=127.0.0.1:10025 >> == >> >> It is important to note that we have seperate relay servers; the >> mailbox servers clients connect to never open anything but the >> submission port (587), and there is therefore never a problem with >> clients trying to connect to postscreen on port 25. A similar setup can >> be achieved by moving the submission service to a seperate IP address, >> if possible. >> >> Do however make sure that it is in fact your Postfix configuration, and >> not a DNS issue of some sort. Test with an iPhone or iPad that has the >> server port set manually, and see if the problem disappears. If it does >> not, the problem might be elsewhere. >> >> Other than that, there should not really be any compatibility issues >> with iOS devices talking to Postfix, as long as your DNS and such is in >> order. >> >> HTH, >> Jona >> > Thank you for your generous responses. > > I do have the client's iPhone set to port 587, however, I'm still wondering > if the iPhone is trying to connect via SMTPS or port 25 (which is not > available). I would like to try setting up SMTP wrapper mode, but does that > in any way disable or interfere with the submission port and TLS? From > reading the Postfix docs I was not sure whether it would override of TLS or > not. > > Also, I will check in to the DNS situation. If the ports are not open, and nothing shows in the Postfix logs that is out of the ordinary, look for the cause elsewhere. Start with DNS. Also, if you have a working submission service there is no reason whatsoever to set up a wrapper mode for SMTPS. It's not a standard, and its use is deprecated. It should however not interfere with your submission port setup, as they are seperate entries in your 'master.cf' file. But again, look closely at your logs. Verify your DNS settings. Test with telnet, see if you get a prompt from the client location on port 587, and so on. See if the problem is in any way dependent on location, a specific device, etcetera, etcetera. Good luck :-) Mvg, Jona
Re: question about postfix queue scheduler
On 06/04/2013 02:20 PM, Erwan David wrote: On Tue, Jun 04, 2013 at 01:44:46PM CEST, Tom Hendrikx said: On 06/04/2013 01:22 PM, Antonio Gutiérrez Mayoral wrote: Hi Wietse, Yes, its a solution, but these emails should be delivered in bussines-time :-( (it doesnt matter if it takes 2 hours... but in bussiness time...) thank you so much! You could run a script as a cronjob that queues x messages when the active queue contains (100 minus x) messages (where 100 is an arbitrary number). This means that all mails on HOLD trickle out as quick as possible, while not overloading the active queue... It means when the queue has 100 messages, you stop sending anything ? You could check the headers for identifying features (maybe the list ID, or a subject part, or...whatever works), and instantly DEFER them. This will put all messages in the deferred queue, guaranteeing they won't choke incoming: if the deferred queue is not empty, one message will be taken from incoming and deferred, in turn. -- J.
Re: question about postfix queue scheduler
Jeroen Geilman: > On 06/04/2013 02:20 PM, Erwan David wrote: > > On Tue, Jun 04, 2013 at 01:44:46PM CEST, Tom Hendrikx > > said: > >> On 06/04/2013 01:22 PM, Antonio Guti?rrez Mayoral wrote: > >>> Hi Wietse, > >>> > >>> Yes, its a solution, but these emails should be delivered in > >>> bussines-time :-( > >>> (it doesnt matter if it takes 2 hours... but in bussiness time...) > >>> > >>> thank you so much! > >>> > >> You could run a script as a cronjob that queues x messages when the > >> active queue contains (100 minus x) messages (where 100 is an arbitrary > >> number). This means that all mails on HOLD trickle out as quick as > >> possible, while not overloading the active queue... > > It means when the queue has 100 messages, you stop sending anything ? > > > > You could check the headers for identifying features (maybe the list ID, > or a subject part, or...whatever works), and instantly DEFER them. > > This will put all messages in the deferred queue, guaranteeing they > won't choke incoming: if the deferred queue is not empty, one message > will be taken from incoming and deferred, in turn. Currently the queue manager can group recipients into jobs when they share the same queue file, and uses that to prevent a limited number of many-recipient messages from blocking later email with fewer recipients. The fix would be to group recipients into jobs based on the sender attribute (or size, or whatever) and apply similar logic to prevent a limited messages from one sender from blocking later email from other senders (or or to prevent large messages from blocking later messages that are smaller in size). However if one sender manages to saturate the queue then it will take time before other email gets a chance to be scheduled. Wietse
Re: Server hard reset, everything seems ok except local list (mailman) mail
On 2013-06-08 8:26 AM, Wietse Venema wrote: [the same error on the virtual socket disappeared after a while] The Postfix warranty does not cover file system corruption, so I can only provide generic system repair suggestions. If Solaris or *BSD, boot single-user mode and fsck the file system. If Linux, do whatever your distro requires to force a full fsck. If fsck does not resolve the issue, then the file system repair program messed up the UNIX-domain sockets. Stop Postfix, remove the 'private' and 'public' queue directories, and restart Postfix. If that doesn't help look for a spare computer system. Thanks Wietse... but just to confirm... If I delete these two directories, postfix will recreate them automatically when I start it back up? Thanks again... -- Best regards, Charles
Re: Server hard reset, everything seems ok except local list (mailman) mail
Charles Marcus: > On 2013-06-08 8:26 AM, Wietse Venema wrote: > > [the same error on the virtual socket disappeared after a while] > > > > The Postfix warranty does not cover file system corruption, so > > I can only provide generic system repair suggestions. > > > > If Solaris or *BSD, boot single-user mode and fsck the file system. > > If Linux, do whatever your distro requires to force a full fsck. > > > > If fsck does not resolve the issue, then the file system repair > > program messed up the UNIX-domain sockets. Stop Postfix, remove the > > 'private' and 'public' queue directories, and restart Postfix. > > > > If that doesn't help look for a spare computer system. > > Thanks Wietse... but just to confirm... > > If I delete these two directories, postfix will recreate them > automatically when I start it back up? Yes. The "postfix start" command invokes "postfix check" which creates missing directories. Wietse
Re: Server hard reset, everything seems ok except local list (mailman) mail
Wietse Venema wrote: Charles Marcus: On 2013-06-08 8:26 AM, Wietse Venema wrote: [the same error on the virtual socket disappeared after a while] The Postfix warranty does not cover file system corruption, so I can only provide generic system repair suggestions. If Solaris or *BSD, boot single-user mode and fsck the file system. If Linux, do whatever your distro requires to force a full fsck. If fsck does not resolve the issue, then the file system repair program messed up the UNIX-domain sockets. Stop Postfix, remove the 'private' and 'public' queue directories, and restart Postfix. If that doesn't help look for a spare computer system. Thanks Wietse... but just to confirm... If I delete these two directories, postfix will recreate them automatically when I start it back up? Yes. The "postfix start" command invokes "postfix check" which creates missing directories. mostly out of curiosity, but also for future reference - would deleting those directories delete queued mail, or is that stored elsewhere? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: Server hard reset, everything seems ok except local list (mailman) mail
On 2013-06-08 5:01 PM, wie...@porcupine.org (Wietse Venema) wrote: Charles Marcus: On 2013-06-08 8:26 AM, Wietse Venema wrote: [the same error on the virtual socket disappeared after a while] The Postfix warranty does not cover file system corruption, so I can only provide generic system repair suggestions. If Solaris or *BSD, boot single-user mode and fsck the file system. If Linux, do whatever your distro requires to force a full fsck. If fsck does not resolve the issue, then the file system repair program messed up the UNIX-domain sockets. Stop Postfix, remove the 'private' and 'public' queue directories, and restart Postfix. If that doesn't help look for a spare computer system. Thanks Wietse... but just to confirm... If I delete these two directories, postfix will recreate them automatically when I start it back up? Yes. The "postfix start" command invokes "postfix check" which creates missing directories. This is good to know for future reference, but alas it didn't work for me (same problem), however, I've determined that the problem only manifests under very specific conditions, the main one being when I send to a list that has only other lists as members (ie multiple nested lists, using mailman, been working fine for years). If I send to a list with only individual recipients, even dozens, everything works fine and those warnings are not evident. Also, if any of the list members have their vacation message enabled, they will get the original message, but the vacation message gets stuck with the 'mail transport unavailable'... Otherwise, vacation messages are working properly (confirmed multiple times, from both local and external senders). I'm working on the mailman list to see if they can help. Any other ideas welcome... -- Best regards, Charles
Re: Server hard reset, everything seems ok except local list (mailman) mail
On Sat, Jun 08, 2013 at 05:52:55PM -0400, Charles Marcus wrote: > I'm working on the mailman list to see if they can help. Make sure all databases (built via postalias, ...) are in good working order. Rebuild them all from the plaintext source files. Use netstat/lsof to find processes listening on or connected to various sockets in /var/spool/postfix/private, which sockets have the most processes? Relevant things to check: - Kernel resource limits, perhaps you need to run fewer processes. - Which program appears the largest number of times in "ps" output. - Is there a lot of mail in the deferred queue? - Are you generating postmaster notices that may make the problem worse? How many local(8) processes are running? What files does the oldest of them have open? How long have they been running? Is there any logging from postfix/local? ... Is there any logging by local other than successful deliveries (if any). Is local(8) able to read the passwd file, or are that file's permissions broken? Run (id -nu) as "postfix" does it work? -- Viktor.
Re: Show username for "SASL LOGIN authentication failed:"?
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. > 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. -- NO ONE WANTS TO HEAR FROM MY ARMPITS Bart chalkboard Ep. 3F01
Re: Show username for "SASL LOGIN authentication failed:"?
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 2. What user is someone else trying to hijack. UGFzc3dvcmQ6 is the user that try to use your postfix to sendmail, it does not matter if that user is not local, its the auth you see trying being abused on your host i have seen at most 10 failed logins here for that user, so pretty common here as well i have limited it here to remove sasl auth on port 25, and on port 587 i have limited ipranges to just be the networking users is on, this stops it very well for me I need this because a user of mine was hijacked a few days ago. I have fail2ban installed and working (banning IPs for 1 hour after 10 incorrect passwords), but looking through the logs in the last month I realized this might have been a distributed attack actually. UGFzc3dvcmQ6 make a fail2ban rule to catch this in logs, and make it perm firewalled, not just let fail2ban do its work Running postfix 2.5.9. pretty old :) -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
