Re: Strange problem with postfix and dovecot sasl auth
Terry Carmen wrote: Hello, I've been trying to setup postfix with tls and smtp auth (dovecot sasl). I'm now stuck with the smtp auth part, with a strange error. For a few days I've tried to search information about similar problems, but found none. Now I'm hoping somebody here could help me out. I'm running Ubuntu Jaunty on AMD64. I've disabled tls (and a lot of other options, and not running in a chroot jail) for now. The problem is, that as soon as I enable smtp auth in postfix (smtpd_sasl_auth_enable), smtp stops working. When doing bash:# telnet localhost 25 Trying ::1... ^ I'm guessing that something in the mix isn't properly configured for IPv6. I's probably configurable, but unless you really need IPv6, I'd suggest just disabling IPv6 in your network stack, commenting out any IPv6 references in Postfix and trying again. Terry Hi Terry, Thanks for the suggestion. Should've been more clear originally, but I already had tried that. And I now tried it again, to no avail (ie. commenting out the 'inet_protocols = all', and dropping the ipv6 loopback from my 'mynetworks'). So doesn't seem to be an ipv6 issue as I understand. For reference, I had to enable ipv6 in postfix, since the new Ubuntu Jaunty has ipv6 compiled into the kernel as opposed to being a module. And there seems to be no way of disabling it. And the fetchmail package distributed with jaunty barfs, if ipv6 is enabled in the system, but not in postfix at least, this seems to be the case. br, juhis -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Strange problem with postfix and dovecot sasl auth
Wietse Venema wrote: Juha Pahkala: Apr 24 15:42:30 server postfix/smtpd[8126]: name_mask: noanonymous Apr 24 15:42:30 server postfix/smtpd[8126]: xsasl_dovecot_server_connect: Connecting Apr 24 15:42:40 server postfix/smtpd[8126]: xsasl_dovecot_server_connect: auth reply: status Apr 24 15:42:50 server postfix/smtpd[8126]: fatal: no SASL authentication mechanisms Your DOVECOT configuration provides no authentication mechanisms that are allowed by POSTFIX smtpd_sasl_security_options. Wietse Thanks for your answer. I'm not quite sure I understand it though. This is how I understand the situation currently: Postfix has (by default) disabled anonymous auth mechanisms. But it does allow plaintext auth. My dovecot provides plain and login. So if I understand correctly, the dovecot plain should be fine? I tried to add cram-md5 and digest-md5 to dovecot auth mechanisms, but it didn't change anyhing. I even tried to set smtpd_sasl_security_options = in postfix main.cf, ie. allowing anonymous auth. And according to postfix documentation... Postfix treats anonymous login as no authentication. So no authentication should be going on, but still I get the error. But the setup does work if I disable sasl auth with smtpd_sasl_auth_enable =no. I'm a bit confused here. Am I making any sense here, surely hope not :) juhis -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
policy-2-postfix process connection pegged at 201
freebsd 7.1 and 7.0 postfix mail_version = 2.4.10 When traffic triggers postfix to log: postfix/smtpd[4]: warning: problem talking to server 127.0.0.1:10041: Operation timed out ... I see that the process qty of policy-to-postfix pegs at 201. As long as that qty stays below 200, there are no postfix timeouts. I can't find any param in the policy process/docs or postfix/docs that is 200. Where is this 200? Len
Re: Conversation with DOMAIN timed out while sending end of data -- message may be sent more than once
On Thursday 23 April 2009 10:02:29 Jørn Odberg wrote: I can now see that the recieving side has an ESTABLISHED connection from the sender, even after the sender tell me it has lost the connection with the reciever. So it seems like something in the middle is forcing the connection to a close... I have now captured some more tcpdumping from both sides. http://postfix.jorno.net/2009_04_23-BamBib-NotBib/ The root of evil are some misguided firewall configurations which block ICMP type 3 packets. As a misguided attempt to work around the first problem, some firewalls or routers intentionally ignore the DF flag (don't fragment), and fragment a long packet anyway, instead of sending an ICMP notification and dropping a packet. And some receiving firewalls drop fragments of a packet which has a DF flag set. A workaround is sometimes to force a smaller MTU at your mailer. Or to turn off MTU discovery (= not to set a DF flag). A fix is to disable blocking of ICMP type 3 packets in firewalls (your outgoing, or recipient's incoming), and turn off the second mentioned misfeature. Mark
Force mail to go through primary MX
Hi, I am running Postfix on Ubuntu 9.04. I have a primary MX server which does antispam/av etc, and the Postfix system which is receiving the messages for the mailing lists etc. I want to stop people from sending directly to the Postfix server, and only allow connections to the relevant domains from the primary MX servers. Is this possible? Thanks. Andrew.
Re: Working with the postfix log files
Scott Haneda wrote: As a test, I have disabled authenticated SMTP on port 25. I just fired up thunderbird, set the SMTP port to 25, and enabled SSL. Sending a test email, and I get an error back from the Thunderbird. Thunderbird chewed on this for a long time. My concern is what was in the logs. If a customer of mine is on the phone with me, and I tell them to make a connection, and the server is rather busy, I am not seeing anything I am going to be able to use form the logs, to help them out Apr 24 18:13:17 catalyst postfix/smtpd[831]: connect from c-76-102-xx1-xx.hsd1.ca.comcast.net[76.102.xx1.xx] Apr 24 18:14:21 catalyst postfix/smtpd[831]: lost connection after UNKNOWN from c-76-102-xx1-xx.hsd1.ca.comcast.net[76.102.xx1.xx] Apr 24 18:14:21 catalyst postfix/smtpd[831]: disconnect from c-76-102-xx1-xx.hsd1.ca.comcast.net[76.102.xx1.xx] I think I would have to ask them to locate their IP, then I could help them out. Suggestions? Yes, when you attempt an SSL connection to a non-SSL port, the only thing postfix sees is an SSL handshake, which mostly just looks like garbage. I don't know if it's even possible for postfix to log something more meaningful in this case. Your best bet in this case (and many others) is to point the user to a web site with screen shots of a proper configuration for their mail client. And yes, for a number of connection problems, you will need to know the IP the client is coming from. For internet users, you can point them to http://whatsmyip.net or another of the many similar services. -- Noel Jones
Re: Force mail to go through primary MX
Andrew Hodgson wrote: Hi, I am running Postfix on Ubuntu 9.04. I have a primary MX server which does antispam/av etc, and the Postfix system which is receiving the messages for the mailing lists etc. I want to stop people from sending directly to the Postfix server, and only allow connections to the relevant domains from the primary MX servers. Is this possible? Thanks. Andrew. Use a check_client_access map to control what IPs can send mail to your server. # main.cf smtpd_client_restrictions = check_client_access cidr:/etc/postfix/allowed_clients # reject all unlisted clients reject # allowed_clients 192.168.3.0/24 OK 192.0.2.12 OK ... -- Noel Jones
Re: policy-2-postfix process connection pegged at 201
On Sat, Apr 25, 2009 at 02:03:43PM -0500, Len Conrad wrote: freebsd 7.1 and 7.0 postfix mail_version = 2.4.10 When traffic triggers postfix to log: postfix/smtpd[4]: warning: problem talking to server 127.0.0.1:10041: Operation timed out ... I see that the process qty of policy-to-postfix pegs at 201. As long as that qty stays below 200, there are no postfix timeouts. I can't find any param in the policy process/docs or postfix/docs that is 200. Where is this 200? Most likely default_process_limit, put a 0 in the process limit column of the master.cf entry for the policy service. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Force mail to go through primary MX
Noel Jones wrote: Use a check_client_access map to control what IPs can send mail to your server. # main.cf smtpd_client_restrictions = check_client_access cidr:/etc/postfix/allowed_clients # reject all unlisted clients reject Andrew, is your server listed as a secondary MX for the domains in question? If your server is listed as a MX host officially in DNS, you should IMHO not use plain reject there, but rather a 4** error message to make sure that clients connect to the primary MX instead. As far as I can tell, reject would force the clients to give up on that message completely and bounce it to the sender. Hope this helps, wolfgang
RE: Force mail to go through primary MX
Wolfgang Zeikat wrote: Noel Jones wrote: Use a check_client_access map to control what IPs can send mail to your server. [...] Andrew, is your server listed as a secondary MX for the domains in question? No, the primary MX server is the only server listed in the MX table. However, it may be possible that I want to host some other domains on the server, which the server would be primary MX for at some point, but I will probably use the solution posted here in the short-term at least. Thanks. Andrew.
RE: Force mail to go through primary MX
Noel Jones wrote: Andrew Hodgson wrote: Hi, I am running Postfix on Ubuntu 9.04. I have a primary MX server which does antispam/av etc, and the Postfix system which is receiving the messages for the mailing lists etc. I want to stop people from sending directly to the Postfix server, and only allow connections to the relevant domains from the primary MX servers. Use a check_client_access map to control what IPs can send mail to your server. # main.cf smtpd_client_restrictions = check_client_access cidr:/etc/postfix/allowed_clients # reject all unlisted clients reject Thanks, that worked for me in the end, though I added in a permit_mynetworks statement to allow the Mailman to relay through the server from localhost. All tested ok, Andrew.
Re: policy-2-postfix process connection pegged at 201
freebsd 7.1 and 7.0 postfix mail_version = 2.4.10 When traffic triggers postfix to log: postfix/smtpd[4]: warning: problem talking to server 127.0.0.1:10041: Operation timed out ... I see that the process qty of policy-to-postfix pegs at 201. As long as that qty stays below 200, there are no postfix timeouts. I can't find any param in the policy process/docs or postfix/docs that is 200. Where is this 200? Most likely default_process_limit, put a 0 in the process limit column of the master.cf entry for the policy service. thanks, but none of the 3 policy services, all listen on TCP, talk about configuring a policy line in master.cf. They aren't spawned by postfix, but started with init scripts and permanently resident. What would a policy line look like in master.cf? Len -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly. __ IMGate OpenSource Mail Firewall www.IMGate.net
Re: policy-2-postfix process connection pegged at 201
Len Conrad: As long as that qty stays below 200, there are no postfix timeouts. I can't find any param in the policy process/docs or postfix/docs that is 200. Where is this 200? Most likely default_process_limit, put a 0 in the process limit column of the master.cf entry for the policy service. thanks, but none of the 3 policy services, all listen on TCP, talk about configuring a policy line in master.cf. They aren't spawned by postfix, but started with init scripts and permanently resident. What would a policy line look like in master.cf? If the policy server's TCP port number exists in master.cf, then the process limit field must be 0. Wietse
Re: Strange problem with postfix and dovecot sasl auth
Wietse Venema wrote: Juha Pahkala: Wietse Venema wrote: Juha Pahkala: Apr 24 15:42:30 server postfix/smtpd[8126]: name_mask: noanonymous Apr 24 15:42:30 server postfix/smtpd[8126]: xsasl_dovecot_server_connect: Connecting Apr 24 15:42:40 server postfix/smtpd[8126]: xsasl_dovecot_server_connect: auth reply: status Apr 24 15:42:50 server postfix/smtpd[8126]: fatal: no SASL authentication mechanisms Your DOVECOT configuration provides no authentication mechanisms that are allowed by POSTFIX smtpd_sasl_security_options. Wietse Thanks for your answer. I'm not quite sure I understand it though. This is how I understand the situation currently: Postfix has (by default) disabled anonymous auth mechanisms. But it does allow plaintext auth. My dovecot provides plain and login. So if I understand correctly, the dovecot plain should be fine? Postfix receives no methods from the Dovecot authentication server that satisfy the smtpd_sasl_security_options requirement. If you don't believe this, then you can try to trace the conversation between Postfix and the Dovecot authentication server. Wietser Hi Wietser, Don't get me wrong, I do believe you if you say so, but I just don't understand why. Given my dovecot config, which I believe is a quite standard way of configuring dovecot , I have no idea why it doesn't work. I've seen similar config files when searching the web, and they seem to work. Do you have any suggestions as to what could be wrong with my dovecot config? Thanks in advance, juhis -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
