Re: forcing authenticated users to use port 587?
On Wed, 7 Jan 2009 21:10:57 -0800 Jeff Weinberger j...@jweinberger.homeip.net wrote: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? Your smtpd_recipient_restrictions... Right now they're probably the same for the smptd daemons listening on ports 25 and 587 and they include one or more permit_* directives, probably permit_mynetworks and permit_sasl_authenticated. You'll remove those permit_* restrictions, except possibly permit_mynetworks from main.cf and replace them with an override (-o switch) on the submission service in master.cf. submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? It's an extension of a great security model, but one of the things that makes that model work is that it has been made easy to implement. It's possible to break things like scripts that need to send mail off the server with a fairly insignificant gain in security. It's not hard to do, but you do need to know the system well to do it because it's at least 2 steps off from any of the documented deployment recipes. I'd do it for a small hobby server like mine just because it's my idea of a good time. I'd also do it for corporate situations where mynetworks includes machines that aren't in a room with a lock on the door, but not if it meant reconfiguring every PHP app and shell script that sends mail out of the company to authenticate itself. Chris Babcock signature.asc Description: PGP signature
Re: Blocking Spam
On Wed, 7 Jan 2009 23:30:06 -0800 (PST) bijayant kumar bijayan...@yahoo.com wrote: Bijayant Kumar --- On Tue, 6/1/09, DJ Lucas d...@lucasit.com wrote: From: DJ Lucas d...@lucasit.com Subject: Re: Blocking Spam To: postfix-users@postfix.org Date: Tuesday, 6 January, 2009, 2:00 PM bijayant kumar wrote: Bijayant Kumar --- On Tue, 6/1/09, DJ Lucas d...@lucasit.com wrote: From: DJ Lucas d...@lucasit.com Subject: Re: Blocking Spam To: postfix postfix-users@postfix.org Date: Tuesday, 6 January, 2009, 6:34 AM bijayant kumar wrote: Hello list, Now a days we are getting lots of spam emails from our own email-ids. I want to block this. I have tried to block senders domains which are local and not doing smtp-auth. While implementing I come across a new problem like, when I rejected a spam coming from my own email-id from another spam server, I got Bounce-Notification message also. As the account(my email id) is local, it entitled to get the Bounce Notification. How to overcome this issue? Any suggestion or reading. SNIP I am trying to reject the mails which is coming from a...@abc.com without smtp-authentication. It is being rejected but the bounce message is getting delivered to a...@abc.com as this domain and email is local. This is the problem. Bijayant Kumar What is the source of the NDR (show headers if it is not you) and why/how was the original message rejected (logs)? I think I was not clear on my question. As we all know spammers uses the from address as our own email address and spamming like anything, right. In those emails from address and To address both are same. So, I tried to block those spams which are local and not doing smtp-authentication. I have tried to simulate the scenario on my local testing environments. I have created a test domain kavach.com and a user bijay...@kavach.com. I have telneted on one another postfix installation and tried to send emails from bijay...@kavach.com to bijay...@kavach.com. What I observed the email is rejected as desired because it has sent without the smtp-authentication. But bijay...@kavach.com also received the bounce-notification message i.e undelivered mail returned to sender. Postconf -n on test machine mynetworks = 127.0.0.0/8 mynetworks_style = subnet myorigin = $mydomain newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.5.5/readme sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_sender_access hash:/etc/postfix/access_sender smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous unknown_local_recipient_reject_code = 550 cat /etc/postfix/access_sender kavach.com REJECT .kavach.com REJECT Mail-Log I sent a mail from another postfix installation postfix/smtpd[14415]: connect from unknown[192.168.99.22] postfix/smtpd[14415]: NOQUEUE: reject: RCPT from unknown[192.168.99.22]: 554 5.7.1 bijay...@kavach.com: Sender address rejected: Access denied; from=bijay...@kavach.com to=bijay...@kavach.com proto=ESMTP helo=test1.localdomain postfix/smtpd[14415]: disconnect from unknown[192.168.99.22] postfix/smtpd[14415]: connect from unknown[192.168.99.22] postfix/smtpd[14415]: 4C8ED7F68D: client=unknown[192.168.99.22] postfix/cleanup[14421]: 4C8ED7F68D: message-id=20090106054312.37623df...@test1.localdomain postfix/qmgr[14308]: 4C8ED7F68D: from=, size=2520, nrcpt=1 (queue active) postfix/smtpd[14415]: disconnect from unknown[192.168.99.22] postfix/virtual[14422]: 4C8ED7F68D: to=bijay...@kavach.com, relay=virtual, delay=0.05, delays=0.03/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir) Hope I am clear this time. Unfortunately, you did not ask a question, but using the logs will help the reader (me) to figure out what the question is. :-) Oopssorry my mistake Right now, it is working perfectly as per your description. 192.168.99.22 is not the final destination, nor is it responsible for the sender of the message, but it accepted the message anyway, and sent it on to the final destination. The destination correctly rejected it, as you configured it to do. 192.168.99.22 received the 550 message and notified the original sender (since it is not responsible for the sender, it notified the sever responsible for the sender with an NDR). I think your question revolves around 192.168.99.22 sending a bounce message. The short answer is that it is misconfigured, in that it
Re: About bounce nonexist mx server mails
On Thu, Jan 08, 2009 at 11:26:57AM +0800, tony liu wrote: Hello, When my customers send mails with nonsexist domain(sometimes maybe typo error, EX. u...@hotmail.org ), these mails will be rejected and in queue for a long time(normally 5 days), Is there a way for postfix to remove these mails immediately or just send a bounce mails to the sender? You can just refuse them: put reject_unknown_recipient_domain in your smtpd_recipient_restrictions -- assuming the typo domain has no A nor MX record, your example hotmail.org however does have an A record thus the mail will be accepted and delivery attempted as usual. RCPT TO: t...@hotmail.comm 450 4.1.2 t...@hotmail.comm: Recipient address rejected: Domain not found Geert
Access and smtpd_sender_restrictions
Hi list! I'm trying to install a postfix with some restrictions, including a sender restriction, but I'm just missing something. The idea is to allow only one domain to send mails from that server, but I'm having access denied including the domain that is supposed to be allowed. Here is what I got: main.cf: smtpd_sender_restrictions= check_client_access hash:/etc/postfix/access reject access: example.com OK And creating the database with: # postmap hash:/etc/postfix/access Here is the output of a telnet session: $ telnet mail.example.com Trying XXX.XXX.XXX.XX... Connected to mail.example.com. Escape character is '^]'. 220 mail.example.com ESMTP Postfix helo martin 250 mail.example.com mail from: mar...@example.com 250 2.1.0 Ok rcpt to: mar...@gmail.com 554 5.7.1 mar...@example.com: Sender address rejected: Access denied quit 221 2.0.0 Bye I've googling around, reading access manual and main.cf examples, but can't figure out what's wrong with it. Any idea is welcome ;) Cheers Martín
Re: Blocking Spam
It's doing what you're asking... REJECT means bounce the message. You probably want to DISCARD it. DISCARD means nobody will receive the bounce message, right? If any bodies mails is rejected from our server he/she will never know what was the issue. Right, which is why you should be very careful about where you apply that rule. Specifically here you are making a policy to the effect of, If mail claiming to to be from one of our users did, in fact, arrive from a foreign server then we do not want to send a bounce message. That is the rule you are asking how to enforce. Now that you know what it means you can make a decision about whether to do it. There *MAY BE* legitimate reasons for for mail to come into your network from a server outsite the network addressed to one of your users and purporting to be from that user. For example, test messages from remote workers sending through their home ISP. Just so that you are aware of the other side of the issue. It means that we can not do any thing for that kind of mails at the Postfix level. We have to receive those *SPAM* Mails in which from and to address are same or spams coming from our one of the email addresses to any users, right? If these types of mails can be rejected by the Postfix then please let me know how or any pointer any docs will be very useful to me. http://www.postfix.org/access.5.html The key is *where* you place the DISCARD action... smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination YOUR CHECKS HERE You've already permitted mail originating from your domain, so if you discard mail with addresses from your domain in your checks it only affects people claiming to be your users originating mail outside your network. That can include remote workers relaying through their home ISP's network. If, however, you make a policy that your users are not to originate mail from their accounts outside of your network then you are not dropping any legitimate mail. The wisdom of the policy is outside the scope of the list, but there's no shortage of people who will either tell you Don't do it, or Fine, but you need to provide a way (auth) for users to follow the policy. Chris Babcock signature.asc Description: PGP signature
Re: Access and smtpd_sender_restrictions
On Thu, Jan 8, 2009 at 9:20 AM, Martin Spinassi martins.li...@gmail.com wrote: main.cf: smtpd_sender_restrictions= check_client_access hash:/etc/postfix/access reject s/check_client_access/check_sender_access/ but this a problem if is a external MTA. Martín -- Reinaldo de Carvalho http://korreio.sf.net (Now available in English) http://python-cyrus.sf.net
tracking MTA connections
I'm attempting to generate some rrd graphs to track MTA connections for postfix. With sendmail it was possible to do this by greping the ps list for the number of sendmail processes. How would I accomplish this on postfix? ~Cory Coager The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender.
Re: Access and smtpd_sender_restrictions
On Thu, 2009-01-08 at 07:54 -0500, Wietse Venema wrote: Martin Spinassi: [ Charset UTF-8 unsupported, converting... ] Hi list! I'm trying to install a postfix with some restrictions, including a sender restriction, but I'm just missing something. The idea is to allow only one domain to send mails from that server, but I'm having access denied including the domain that is supposed to be allowed. Here is what I got: main.cf: smtpd_sender_restrictions= check_client_access hash:/etc/postfix/access reject ... 554 5.7.1 mar...@example.com: Sender address rejected: Access denied So, what's wrong with it? Wietse Thanks for the response Wietse. It'd allow mail from the domain example.com, that's why I also added example.com OK to access. Cheers Martín
Re: tracking MTA connections
* Cory Coager ccoa...@davisvision.com: I'm attempting to generate some rrd graphs to track MTA connections for postfix. With sendmail it was possible to do this by greping the ps list for the number of sendmail processes. How would I accomplish this on postfix? grep for the smtp processes (not smtpd) (or vice versa) -- Ralf Hildebrandt (ralf.hildebra...@charite.de) snick...@charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de Java is, in many ways, C++--. - Michael Feldman.
Re: forcing authenticated users to use port 587?
Jeff Weinberger wrote, at 01/08/2009 12:10 AM: Hi: Based on good practice and the help and urging of some of the gurus on this list, I am moving my users to using the submission service (port 587) instead of port 25 to send mail from their mail clients. Once most of them move, I'd like to start warning the ones who don't that they should (ok, maybe just bugging them). But then I was thinking I might eventually want to require that they use port 587. My question is really two-fold: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? Yes, you can simply set smtpd_sasl_auth_enable = no (which is the default, so you could also remove the line, but being explicit might be more helpful in this case). You can also remove permit_sasl_authenticated from smtpd_*_restrictions, but it might be wise to leave it in place for the time being (it shouldn't cause any problems). Your submission service in master.cf should already have -o smtpd_sasl_auth_enable=yes in it. Keep in mind, however, that some users will still be able to use port 25 to send messages to domains that the server accepts mail for. To them, it may seem that relaying works inconsistently. 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? The decision to restrict mail submission to port 587 depends on your needs. I manage some environments where this is enforced. I actually like the separation, but it sometimes requires additional support for legacy clients (achieved in various ways). In other environments with a more diverse and general population, I continue to allow submission on port 25, but only with mechanisms that are considered secure. You'll probably want to begin with this arrangement, as you are suggesting. It's kinder to your users, if you're not in any rush. The important thing is that you're opening port 587 (with sane settings) to support road warriors and users whose ISPs block outgoing connections to port 25. This move benefits them as much (if not more) as you.
Re: Access and smtpd_sender_restrictions
On Thu, 2009-01-08 at 10:10 -0300, Reinaldo de Carvalho wrote: On Thu, Jan 8, 2009 at 9:20 AM, Martin Spinassi martins.li...@gmail.com wrote: main.cf: smtpd_sender_restrictions= check_client_access hash:/etc/postfix/access reject s/check_client_access/check_sender_access/ but this a problem if is a external MTA. Martín Hey! That did the trick! Thanks for the help. Can you explain me why is it a problem if it si an external MTA? Cheers Martín
Re: About bounce nonexist mx server mails
On Thu, Jan 08, 2009 at 09:59:54AM -0300, Reinaldo de Carvalho wrote: On Thu, Jan 8, 2009 at 6:01 AM, Geert Hendrickx g...@telenet.be wrote: You can just refuse them: put reject_unknown_recipient_domain in your smtpd_recipient_restrictions -- assuming the typo domain has no A nor MX record, your example hotmail.org however does have an A record thus the mail will be accepted and delivery attempted as usual. RCPT TO: t...@hotmail.comm 450 4.1.2 t...@hotmail.comm: Recipient address rejected: Domain not found Geert reject_unknown_recipient_domain work only for top-level domain name (TLDs) errors (.comm, .opgg, .nett). I don't see why. RCPT TO: t...@blablafoo.com 450 4.1.2 t...@blablafoo.com: Recipient address rejected: Domain not found Anyway, as said, this check will only refuse mail for domains that really do not exist (NXDOMAIN) or don't have an A, AAA or MX record. For cases like hotmail.org which do exist but are known not to deliver (correctly), you'll have to manually blacklist them. Geert
Re: forcing authenticated users to use port 587?
Chris Babcock wrote, at 01/08/2009 03:19 AM: On Wed, 7 Jan 2009 21:10:57 -0800 Jeff Weinberger j...@jweinberger.homeip.net wrote: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? Your smtpd_recipient_restrictions... Right now they're probably the same for the smptd daemons listening on ports 25 and 587 and they include one or more permit_* directives, probably permit_mynetworks and permit_sasl_authenticated. You'll remove those permit_* restrictions, except possibly permit_mynetworks from main.cf and replace them with an override (-o switch) on the submission service in master.cf. submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject Better to uncomment the default submission settings in your master.cf and work from that, if needed. In recent versions of Postfix, this is: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING Before editing the settings provided with your version of Postfix, please take time to understand what you are doing. The defaults are very sane, and rarely need adjusting. 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? It's an extension of a great security model, but one of the things that makes that model work is that it has been made easy to implement. It's possible to break things like scripts that need to send mail off the server with a fairly insignificant gain in security. It's not hard to do, but you do need to know the system well to do it because it's at least 2 steps off from any of the documented deployment recipes. I'd do it for a small hobby server like mine just because it's my idea of a good time. I'd also do it for corporate situations where mynetworks includes machines that aren't in a room with a lock on the door, but not if it meant reconfiguring every PHP app and shell script that sends mail out of the company to authenticate itself. This isn't necessarily a bad thing. I've found that applications and devices with poor SMTP support deserve a security audit that often reveals other weaknesses. If they're not immediately fixable, it's useful to isolate them on a separate and secure relay while waiting for them to be upgraded or replaced.
RE: CDB map files for virtual alias maps
So that seems to be it. I would really need to compile an authentic postfix version. Can you give me a link to source RPM of 2.5.5 for centos 5 Wietse does not release any RPM versions of Postfix. As you can imagine, keeping that up for all the RPM-based distros would be quite a feat. However, Simon Mudd has done a great job making SRPMs from which you can build Postfix for just about any distro. The problem is, I think that's what you used in this case. This was a problem I reported to him a year or two ago, where it would always result in case-sensitive cdb lookups. This was fixed in 2.4.7-2 and it worked fine in my tests. However, it looks like it has crept back into some release after 2.4.7-2. To verify, I just built and installed Simon's 2.4.7-2 SRPM and cdb works fine (not case sensitive). But in 2.5.5-1 it is broken again. Looking at the changelog files, I'd guess 2.5.1-0.4 broke it again, since in that release he no longer mentions 2.4.7-2. You probably need to contact Simon and ask him to look at this cdb problem one more time. --Brian
Re: forcing authenticated users to use port 587?
On Jan 8, 2009, at 5:49 AM, Jorey Bump wrote: Jeff Weinberger wrote, at 01/08/2009 12:10 AM: Hi: Based on good practice and the help and urging of some of the gurus on this list, I am moving my users to using the submission service (port 587) instead of port 25 to send mail from their mail clients. Once most of them move, I'd like to start warning the ones who don't that they should (ok, maybe just bugging them). But then I was thinking I might eventually want to require that they use port 587. My question is really two-fold: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? Yes, you can simply set smtpd_sasl_auth_enable = no (which is the default, so you could also remove the line, but being explicit might be more helpful in this case). You can also remove permit_sasl_authenticated from smtpd_*_restrictions, but it might be wise to leave it in place for the time being (it shouldn't cause any problems). Your submission service in master.cf should already have -o smtpd_sasl_auth_enable=yes in it. Keep in mind, however, that some users will still be able to use port 25 to send messages to domains that the server accepts mail for. To them, it may seem that relaying works inconsistently. 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? The decision to restrict mail submission to port 587 depends on your needs. I manage some environments where this is enforced. I actually like the separation, but it sometimes requires additional support for legacy clients (achieved in various ways). In other environments with a more diverse and general population, I continue to allow submission on port 25, but only with mechanisms that are considered secure. You'll probably want to begin with this arrangement, as you are suggesting. It's kinder to your users, if you're not in any rush. The important thing is that you're opening port 587 (with sane settings) to support road warriors and users whose ISPs block outgoing connections to port 25. This move benefits them as much (if not more) as you. Thank you for your help and insight.!! I'm glad to hear that this is a fairly common option and one that can be supported, even if with some hoop-jumping. As far as how to make it happen... Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Thanks! --Jeff
Re: forcing authenticated users to use port 587?
Jeff Weinberger wrote, at 01/08/2009 09:27 AM: Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? Actually, smtpd_sasl_auth_enable = no means that authentication is not enabled. IOW, Postfix won't offer 250-AUTH [mech list] after HELO/EHLO. Attempts to authenticate will generate an error. Most modern clients are intelligent enough to detect the absence of AUTH and will not attempt to authenticate. Good ones will abort and notify the user. Bad ones might attempt to continue, in case the server will still accept the message. If the domain is a destination your server handles, it will probably accept the message, otherwise it will reject it. In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks.
Re: tracking MTA connections
Ralf Hildebrandt said the following on 01/08/2009 08:39 AM: * Cory Coager ccoa...@davisvision.com: I'm attempting to generate some rrd graphs to track MTA connections for postfix. With sendmail it was possible to do this by greping the ps list for the number of sendmail processes. How would I accomplish this on postfix? grep for the smtp processes (not smtpd) (or vice versa) The number of smtp processes never changes so this won't work. ~Cory Coager The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender.
Re: tracking MTA connections
* Cory Coager ccoa...@davisvision.com: I'm attempting to generate some rrd graphs to track MTA connections for postfix. With sendmail it was possible to do this by greping the ps list for the number of sendmail processes. How would I accomplish this on postfix? grep for the smtp processes (not smtpd) (or vice versa) The number of smtp processes never changes so this won't work. Why ask if you know better? Of course it changes. -- Ralf Hildebrandt (ralf.hildebra...@charite.de) snick...@charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de Signatures cause cancer.
Re: tracking MTA connections
* Ralf Hildebrandt ralf.hildebra...@charite.de: grep for the smtp processes (not smtpd) (or vice versa) The number of smtp processes never changes so this won't work. Why ask if you know better? Of course it changes. mail-ausfall:~# ps auxwww|grep smtp -n |wc -l 6 mail-ausfall:~# ps auxwww|grep smtp -n |wc -l 4 -- Ralf Hildebrandt (ralf.hildebra...@charite.de) snick...@charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de Unix IS user friendly - it's just selective about who its friends are.
Re: tracking MTA connections
* Ralf Hildebrandt ralf.hildebra...@charite.de: grep for the smtp processes (not smtpd) (or vice versa) The number of smtp processes never changes so this won't work. Why ask if you know better? Of course it changes. mail-ausfall:~# ps auxwww|grep smtp -n |wc -l 6 mail-ausfall:~# ps auxwww|grep smtp -n |wc -l 4 Unfortunately its not working. # ps auxwww|grep smtp -n postfix 16747 0.0 0.0 3728 1172 ?S10:08 0:00 smtp -n pmx -t unix -u postfix 18905 0.0 0.0 3728 1160 ?S10:21 0:00 smtp -n pmx -t unix -u The version installed is 2.5.4. It doesn't look like child processes get spawned from new connections. I ran the command on watch and the output never changes however postfix is processing about 5 messages per minute. Why am I getting different results? Is this a configuration tweak? ~Cory Coager The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender.
Re: tracking MTA connections
* Cory Coager ccoa...@davisvision.com: Unfortunately its not working. # ps auxwww|grep smtp -n postfix 16747 0.0 0.0 3728 1172 ?S10:08 0:00 smtp -n pmx -t unix -u postfix 18905 0.0 0.0 3728 1160 ?S10:21 0:00 smtp -n pmx -t unix -u The version installed is 2.5.4. It doesn't look like child processes get spawned from new connections. Well, there ARE enough processes as is. Your server is very low volume it seems. I ran the command on watch and the output never changes however postfix is processing about 5 messages per minute. Why am I getting different results? Is this a configuration tweak? a) connection caching b) low volume -- Ralf Hildebrandt (ralf.hildebra...@charite.de) snick...@charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de In den USA wird ja nichts mehr hergestellt außer Intellectual Property (haha) und Dilbert-style Management Best Practices. -- fefe
Re: tracking MTA connections
Cory Coager wrote:
Ralf Hildebrandt said the following on 01/08/2009 08:39 AM:
* Cory Coager ccoa...@davisvision.com:
I'm attempting to generate some rrd graphs to track MTA connections for
postfix. With sendmail it was possible to do this by greping the ps
list for the number of sendmail processes. How would I accomplish this
on postfix?
grep for the smtp processes (not smtpd)
(or vice versa)
The number of smtp processes never changes so this won't work.
~Cory Coager
Postfix keeps idle processes around for $max_idle (default
100s), so the process count is only an approximation of the
number of connections. Idle processes are reused $max_use
(default 100) times before they are retired. The number of
processes will change with the number of connections until the
maximum number of configured connections is reached. I
suspect this is similar to what you get when counting
sendmail processes.
To get an accurate connection count, you will need to parse
netstat or lsof output to count established connections.
Even this may give an inaccurate number if there are more
connections than available smtpd processes.
I use this perl one liner on FreeBSD, you may need to adjust
it for another OS.
netstat -an 2/dev/null | perl -lne '
$in = 0 if $in == undef;
$out = 0 if $out == undef;
++$in if (/ESTABLISHED/
/(?:^|\s)\d+\.\d+\.\d+\.\d+[.:](\d+)\s+\d+\.\d+\.\d+\.\d+[.:]\d+/
$1 eq 25);
++$out if (/ESTABLISHED/
/(?:^|\s)\d+\.\d+\.\d+\.\d+[.:]\d+\s+\d+\.\d+\.\d+\.\d+[.:](\d+)/
$1 eq 25);
END {print $ARGV[0], Port 25 status: , $in,
Established incoming, , $out, Established outgoing};
'
--
Noel Jones
Re: tracking MTA connections
* Ralf Hildebrandt ralf.hildebra...@charite.de: Well, there ARE enough processes as is. Your server is very low volume it seems. I ran the command on watch and the output never changes however postfix is processing about 5 messages per minute. Why am I getting different results? Is this a configuration tweak? a) connection caching b) low volume You could parse the log for postfix/smtp[ entries -- Ralf Hildebrandt (ralf.hildebra...@charite.de) snick...@charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de The Tao that is seen Is not the true Tao-until You bring fresh toner.
Re: CDB map files for virtual alias maps
On Thu, Jan 08, 2009 at 09:25:33AM -0500, Brian Collins wrote: So that seems to be it. I would really need to compile an authentic postfix version. Can you give me a link to source RPM of 2.5.5 for centos 5 Wietse does not release any RPM versions of Postfix. As you can imagine, keeping that up for all the RPM-based distros would be quite a feat. However, Simon Mudd has done a great job making SRPMs from which you can build Postfix for just about any distro. The problem is, I think that's what you used in this case. This was a problem I reported to him a year or two ago, where it would always result in case-sensitive cdb lookups. This was fixed in 2.4.7-2 and it worked fine in my tests. However, it looks like it has crept back into some release after 2.4.7-2. To verify, I just built and installed Simon's 2.4.7-2 SRPM and cdb works fine (not case sensitive). But in 2.5.5-1 it is broken again. Looking at the changelog files, I'd guess 2.5.1-0.4 broke it again, since in that release he no longer mentions 2.4.7-2. You probably need to contact Simon and ask him to look at this cdb problem one more time. The SRPM includes a: postfix-dict_cdb-1.1.11-20021104.tar.gz in which we find: dict_cdb.sh README_FILES/CDB_README src/global/mkmap_cdb.c src/util/dict_cdb.c src/util/dict_cdb.h if these are used to replace the correct 2.5 versions of these files, then indeed the RPM is broken. -- 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: Preventing relay of multiple recipients or cc to multiple recipients
On Thu, Jan 08, 2009 at 11:03:51AM +0100, Bas van Reeuwijk wrote:
Am I correct in understandig that I should set null_sender to empty in the
pipe command to my content filter, because the default is set to
'MAILER-DAEMON'?
Yes.
Currently my filter entry in the master.cf is as follows:
spamfilterunix - n n - - pipe flags=Rq
user=spamfilter argv=/usr/local/bin/spamfilter.sh -f ${sender} --
${recipient}
So it should become?:
spamfilterunix - n n - - pipe flags=Rq
null_sender= user=spamfilter argv=/usr/local/bin/spamfilter.sh -f
${sender} -- ${recipient}
Exactly, with suitable leading whitespace on lines after the first if it
is not all on one line:
spamfilterunix - n n - - pipe
flags=Rq null_sender= user=spamfilter
argv=/usr/local/bin/spamfilter.sh -f ${sender} -- ${recipient}
Check the script to make sure it does not break with an empty -f
option value. If spamfilter only uses the command-line arguments
for re-injecting into sendmail(1) and otherwise only looks at the
message content (not envelope) you are done. Otherwise you need
to see how it parses/uses the -f sender option.
--
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: Access and smtpd_sender_restrictions
Martin Spinassi a écrit : On Thu, 2009-01-08 at 10:10 -0300, Reinaldo de Carvalho wrote: On Thu, Jan 8, 2009 at 9:20 AM, Martin Spinassi martins.li...@gmail.com wrote: main.cf: smtpd_sender_restrictions= check_client_access hash:/etc/postfix/access reject s/check_client_access/check_sender_access/ but this a problem if is a external MTA. Martín Hey! That did the trick! Thanks for the help. Can you explain me why is it a problem if it si an external MTA? Cheers Martín you can explain this better smtpd_sender_restrictions= check_client_access hash:/etc/postfix/access reject s/check_client_access/check_sender_access/
Re: Access and smtpd_sender_restrictions
john.swilt...@wanadoo.fr a écrit : Martin Spinassi a écrit : On Thu, 2009-01-08 at 10:10 -0300, Reinaldo de Carvalho wrote: On Thu, Jan 8, 2009 at 9:20 AM, Martin Spinassi martins.li...@gmail.com wrote: main.cf: smtpd_sender_restrictions= check_client_access hash:/etc/postfix/access reject s/check_client_access/check_sender_access/ but this a problem if is a external MTA. Martín Hey! That did the trick! Thanks for the help. Can you explain me why is it a problem if it si an external MTA? Cheers Martín you can explain this better smtpd_sender_restrictions= check_client_access hash:/etc/postfix/access reject s/check_client_access/check_sender_access/
Re: Access and smtpd_sender_restrictions
On Thu, Jan 8, 2009 at 11:10 AM, Martin Spinassi martins.li...@gmail.com wrote: On Thu, 2009-01-08 at 10:10 -0300, Reinaldo de Carvalho wrote: On Thu, Jan 8, 2009 at 9:20 AM, Martin Spinassi martins.li...@gmail.com wrote: main.cf: smtpd_sender_restrictions= check_client_access hash:/etc/postfix/access reject s/check_client_access/check_sender_access/ but this a problem if is a external MTA. Martín Hey! That did the trick! Thanks for the help. Can you explain me why is it a problem if it si an external MTA? Martín Because any sender not equal to example.com will be reject. You should enforce sender domain only for local network or autenthicated connections. Example: smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access # /etc/postfix/access example.com permit_mynetworks, permit_sasl_authenticated, reject # postmap /etc/postfix/access -- Reinaldo de Carvalho http://korreio.sf.net (Now available in English) http://python-cyrus.sf.net
Re: forcing authenticated users to use port 587?
On Thu, 08 Jan 2009 09:53:45 -0500, Jorey Bump l...@joreybump.com wrote: Jeff Weinberger wrote, at 01/08/2009 09:27 AM: Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? Actually, smtpd_sasl_auth_enable = no means that authentication is not enabled. IOW, Postfix won't offer 250-AUTH [mech list] after HELO/EHLO. Attempts to authenticate will generate an error. Most modern clients are intelligent enough to detect the absence of AUTH and will not attempt to authenticate. Good ones will abort and notify the user. Bad ones might attempt to continue, in case the server will still accept the message. If the domain is a destination your server handles, it will probably accept the message, otherwise it will reject it. In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Jory: Thanks again! So it looks like it's as simple as smtpd_sasl_auth_enable = no for port 25, and then making sure everything else is set so that mail coming in on port 25 has to be for one of my domains or it's rejected. Thanks! I appreciate the help!
Re: tracking MTA connections
Noel Jones said the following on 01/08/2009 10:34 AM:
Postfix keeps idle processes around for $max_idle (default 100s), so
the process count is only an approximation of the number of
connections. Idle processes are reused $max_use (default 100) times
before they are retired. The number of processes will change with the
number of connections until the maximum number of configured
connections is reached. I suspect this is similar to what you get
when counting sendmail processes.
To get an accurate connection count, you will need to parse netstat
or lsof output to count established connections. Even this may give
an inaccurate number if there are more connections than available
smtpd processes.
I use this perl one liner on FreeBSD, you may need to adjust it for
another OS.
netstat -an 2/dev/null | perl -lne '
$in = 0 if $in == undef;
$out = 0 if $out == undef;
++$in if (/ESTABLISHED/
/(?:^|\s)\d+\.\d+\.\d+\.\d+[.:](\d+)\s+\d+\.\d+\.\d+\.\d+[.:]\d+/
$1 eq 25);
++$out if (/ESTABLISHED/
/(?:^|\s)\d+\.\d+\.\d+\.\d+[.:]\d+\s+\d+\.\d+\.\d+\.\d+[.:](\d+)/
$1 eq 25);
END {print $ARGV[0], Port 25 status: , $in, Established
incoming, , $out, Established outgoing};
'
Parsing netstat seems to work. It doesn't need to be 100% accurate for
what I'm doing.
Thanks!
~Cory Coager
The information contained in this communication is intended
only for the use of the recipient(s) named above. It may
contain information that is privileged or confidential, and
may be protected by State and/or Federal Regulations. If
the reader of this message is not the intended recipient,
you are hereby notified that any dissemination,
distribution, or copying of this communication, or any of
its contents, is strictly prohibited. If you have received
this communication in error, please return it to the sender
immediately and delete the original message and any copy
of it from your computer system. If you have any questions
concerning this message, please contact the sender.
Re: Access and smtpd_sender_restrictions
On Thu, 2009-01-08 at 14:02 -0300, Reinaldo de Carvalho wrote: [ snip ] Hey! That did the trick! Thanks for the help. Can you explain me why is it a problem if it si an external MTA? Martín Because any sender not equal to example.com will be reject. You should enforce sender domain only for local network or autenthicated connections. Example: smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access # /etc/postfix/access example.com permit_mynetworks, permit_sasl_authenticated, reject # postmap /etc/postfix/access I see it now... I'll try to be a little more detailed. The server will be used by a web site. It'll use it for register users, send passwords, remainders, etc. The problem here is that sometimes developers screw it, and mails are send using some @gmail or @yahoo domain (mostly for some test and then leaved there by mistake). What I want to do here is force them to not do such things in production environment (yes, I can shoot them too, but you know...). Server shouldn't receive any mail at all. May be I'd add to /etc/postfix/access? Another solution is to install cyrus and add a user, then restrict only logged users, but (correct me), it will accept any (forged) domain, and it can be authenticated anyway. Thanks again for your responses and patience! ;) Cheers Martín
Send-Only Server Config?
Hi All, I'm hoping for a little guidance with this. My apologies for not doing a proper search on this first, but I'm a bit pressed for time. I've been asked to build a mail server for the purpose of sending mail from various machines within a LAN to anywhere on the Net. I'm guessing that this would be considered a relay in a sense, since the server will not be receiving mail from the outside, but please correct me if I'm wrong. My first question is, is this a do-able solution? I've only built 1 Postfix server previously, and it took me awhile and didn't quite work as expected (due to my own lack of configuration, not with Postfix.) I'm not going to use Exim or Qmail, as I believe this setup would be very simplistic, and Postfix should be more than able to handle this, along with any potential add-ons later on (automatically archiving all outbound messages to another address, adding virus scanning, etc.) Is there any documentation available on how to get this setup? Again, my apologies for not researching this in more detail, but I need to get an answer out as soon as possible, and I figured this list would be my best bet. TIA, ~MD
Reject_unlisted_recipient and wide aliasing
Hello,
I don't want my mail queue to fill due to fake mail (spam) so I'd like to
reject as much mail as I could at the smtp stage (avoiding mail entering
into my queues). My setup is multi-domain (vdomains) and it's working
reasonably well for my hosted domains (real) but not for those being
aliased. The problem (I guess) if that I'm using wide aliasing so I
have an alias table (virtual_alias_maps) of the form:
@aliasdomain.com@realdomain.com
(no users are being especified).
So all possible recipients at aliasdomain.com are being taken as
existing, and thus not being rejected by reject_unlisted_recipient rule.
This is expected behaviour (I guess), but I'm wondering whether there is
any elegant way to solve the problem without having to create one-to-one
aliases such as: us...@aliasdomain.com us...@realdomain.com,
us...@aliasdomain.com us...@realdomain.com, etc.
Do you know a cute way to solve this? Thank you.
PD: postconf -n attached:
===
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisfeed:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
delay_warning_time = 4
disable_vrfy_command = yes
mail_name = mxhs
mailbox_command = procmail -a $EXTENSION
message_reject_characters = \0
message_size_limit = 28311552
mydestination = $myhostname localhost localhost.$mydomain
myhostname = mx.mydomain.com
mynetworks = 127.0.0.2, 127.0.0.3
myorigin = $myhostname
recipient_delimiter = +
relay_domains = hash:/etc/postfix/listas hash:/etc/postfix/mxbackup
relocated_maps = hash:/etc/postfix/relocated
show_user_unknown_table_name = no
smtp_bind_address = undisclosed
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noplaintext
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
permit_mynetworks,
reject_authenticated_sender_login_mismatch,permit_sasl_authenticated,
reject_unauth_destination, reject_unlisted_recipient,
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_sender_login_maps = $virtual_mailbox_maps
smtpd_tls_cert_file = /etc/ssl/certs/mail.mydomain.com.crt
smtpd_tls_key_file = /etc/ssl/private/mail.mydomain.com.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/listas
virtual_alias_maps = mysql:/etc/postfix/valias.mysql
virtual_mailbox_domains = mysql:/etc/postfix/vdomain.mysql
virtual_mailbox_maps = mysql:/etc/postfix/vuser.mysql
virtual_transport = lmtp:unix:/private/cyrus
===
--
Saludos,
-Roman
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]
Re: Reject_unlisted_recipient and wide aliasing
Roman Medina-Heigl Hernandez wrote: Hello, I don't want my mail queue to fill due to fake mail (spam) so I'd like to reject as much mail as I could at the smtp stage (avoiding mail entering into my queues). My setup is multi-domain (vdomains) and it's working reasonably well for my hosted domains (real) but not for those being aliased. The problem (I guess) if that I'm using wide aliasing so I have an alias table (virtual_alias_maps) of the form: @aliasdomain.com@realdomain.com (no users are being especified). Wildcards break recipient validation. So all possible recipients at aliasdomain.com are being taken as existing, and thus not being rejected by reject_unlisted_recipient rule. This is expected behaviour (I guess), but I'm wondering whether there is any elegant way to solve the problem without having to create one-to-one aliases such as: us...@aliasdomain.com us...@realdomain.com, us...@aliasdomain.com us...@realdomain.com, etc. Do you know a cute way to solve this? Thank you. Use 1-1 mappings. Use a little script and a Makefile to let the computer build the aliased domain from the real domain list you already maintain. Size of the table is not an issue. Your postconf output looks OK. -- Noel Jones
Re: Reject_unlisted_recipient and wide aliasing
Noel Jones escribió: Roman Medina-Heigl Hernandez wrote: Hello, I don't want my mail queue to fill due to fake mail (spam) so I'd like to reject as much mail as I could at the smtp stage (avoiding mail entering into my queues). My setup is multi-domain (vdomains) and it's working reasonably well for my hosted domains (real) but not for those being aliased. The problem (I guess) if that I'm using wide aliasing so I have an alias table (virtual_alias_maps) of the form: @aliasdomain.com@realdomain.com (no users are being especified). Wildcards break recipient validation. So all possible recipients at aliasdomain.com are being taken as existing, and thus not being rejected by reject_unlisted_recipient rule. This is expected behaviour (I guess), but I'm wondering whether there is any elegant way to solve the problem without having to create one-to-one aliases such as: us...@aliasdomain.com us...@realdomain.com, us...@aliasdomain.com us...@realdomain.com, etc. Do you know a cute way to solve this? Thank you. Use 1-1 mappings. Use a little script and a Makefile to let the computer build the aliased domain from the real domain list you already maintain. Size of the table is not an issue. Your postconf output looks OK. Yes, all tasks can usually be automatized but sometimes it's good to simplify things. I don't know much about postfix internals, I suppose this is a design decission, I mean, aliases are resolved at later stages, but perhaps it could be good to have a simple check at the smtp stage in a way that if all targets of a given alias entry are local domains, then Postfix would evaluate $local_recipient_maps against those local domains. Same apply for other classes (such as virtual by checking $virtual_mailbox_maps). Of course if an alias points to another alias, this second alias could be resolved in the same way. In other words, the idea is to resolve the alias entry until you reach a point were you cannot know which users do a domain have for sure so the only choice is to add the mail to queue and let the other postfix subprocesses makes their job. If all final recipients can be checked against its corresponding map (i.e. you know for sure if they exist or not), reject_unlisted_recipient will be honored. If not, let the mail drop into the queue (for instance if you have an alias to an external domain; or if you have a mix of destination domains related to one alias entry: hosted and external, eg). I think it makes sense... and it could be an useful feature. It would be nice if Wietse could comment on this. -- Saludos, -Roman PGP Fingerprint: 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742 [Key ID: 0xEAD56742. Available at KeyServ]
Re: Blocking Spam
bijayant kumar a écrit : My question is, spammers forges the from address and sends the spam where from address and to address are same. Like in my case I am getting the spam mails from bijay...@kavach.com to bijay...@kavach.com. So, I googled and found that after reject_unauth_destination I have to add one check_sender_access in which I have to write kavach.com REJECT. It means that reject all the mails which are not doing smtp-authetication and the domains are local, right? To test the above settings I telnetted to 192.168.99.22 (another postfix installed machine) and tried to send mail from and rcpt to as bijay...@kavach.com. As expected it got rejected. But I have also received the bounce message also from the sender . I am wondering if this is by default then my users will get lots of bounce notification mails which they have never sent. So, the total idea behind implementing this feature will fail. There has to be some way that I am not able to find. Please suggest how should I proceed. Am I testing in the wrong way or missing any thing? and the test succeeds. the postfix that you configured _rejected_ the transaction. it did not send a bounce. The bounce was sent by 192.168.99.22 and this is the right behaviour for a real MTA. if the spam is sent by ratware (and not a real MTA), the ratware will generally ignore the rejection and no bounce will be created. so far so good. if the spammer sends using a real MTA, you will get a bounce. The BACKSCATTER README contains ideas to help fight backscatter. This won't block all backscatter, but it's a good start. Thats not a case, we are receiving the Bounce messages for local users. if the above is not enough, use a policy server (or a real time log parser) to temporarily block the offending IP.
Re: Reject_unlisted_recipient and wide aliasing
Roman Medina-Heigl Hernandez a écrit : Noel Jones escribió: [snip] Use 1-1 mappings. Use a little script and a Makefile to let the computer build the aliased domain from the real domain list you already maintain. Size of the table is not an issue. Your postconf output looks OK. Yes, all tasks can usually be automatized but sometimes it's good to simplify things. [snip] Here's an (I hope, illustrative) example of a mysql setup where this is not a problem: - table User contains user and domain columns. - table DomainAlias contains alias and destination columns. query = select User.domain from User, DomainAlias where alias = '%s' and destination = domain (the user column must never be empty). The limitation is that you can't use recursive domain aliases, so you can't implement this: @example.com@example.org @example.org@example.net but such recursive aliases would be expensive anyway, and one can resolve them ahead of time (in the UI that adds them, for instance). Of course, you can also use a policy service to fix the problem.
Re: Reject_unlisted_recipient and wide aliasing
Roman Medina-Heigl Hernandez wrote: Noel Jones escribió: Roman Medina-Heigl Hernandez wrote: Hello, I don't want my mail queue to fill due to fake mail (spam) so I'd like to reject as much mail as I could at the smtp stage (avoiding mail entering into my queues). My setup is multi-domain (vdomains) and it's working reasonably well for my hosted domains (real) but not for those being aliased. The problem (I guess) if that I'm using wide aliasing so I have an alias table (virtual_alias_maps) of the form: @aliasdomain.com@realdomain.com (no users are being especified). Wildcards break recipient validation. So all possible recipients at aliasdomain.com are being taken as existing, and thus not being rejected by reject_unlisted_recipient rule. This is expected behaviour (I guess), but I'm wondering whether there is any elegant way to solve the problem without having to create one-to-one aliases such as: us...@aliasdomain.com us...@realdomain.com, us...@aliasdomain.com us...@realdomain.com, etc. Do you know a cute way to solve this? Thank you. Use 1-1 mappings. Use a little script and a Makefile to let the computer build the aliased domain from the real domain list you already maintain. Size of the table is not an issue. Your postconf output looks OK. Yes, all tasks can usually be automatized but sometimes it's good to simplify things. I don't know much about postfix internals, I suppose this is a design decission, I mean, aliases are resolved at later stages, but perhaps it could be good to have a simple check at the smtp stage in a way that if all targets of a given alias entry are local domains, then Postfix would evaluate $local_recipient_maps against those local domains. Same apply for other classes (such as virtual by checking $virtual_mailbox_maps). Of course if an alias points to another alias, this second alias could be resolved in the same way. In other words, the idea is to resolve the alias entry until you reach a point were you cannot know which users do a domain have for sure so the only choice is to add the mail to queue and let the other postfix subprocesses makes their job. If all final recipients can be checked against its corresponding map (i.e. you know for sure if they exist or not), reject_unlisted_recipient will be honored. If not, let the mail drop into the queue (for instance if you have an alias to an external domain; or if you have a mix of destination domains related to one alias entry: hosted and external, eg). I think it makes sense... and it could be an useful feature. It would be nice if Wietse could comment on this. He has, more than once. Check the archives. Short summary - Recipient validation is an add-on feature not present in the original postfix design (such a feature wasn't considered important 10+ years ago). Adding recursive recipient validation is a worthy goal and may be addressed in a future redesign of postfix. This would probably involve a new address resolution daemon and redesign of the mail flow through postfix, not a trivial task. Back to my comments: I've found it convenient to create a Makefile that contains all my various maps and user tables. When I make a change to any of the source files, I just type make and everything is rebuilt without me having to do much thinking about which tables need to go where and what data affects more than one table. Even if postfix did have recursive recipient validation, I would still use this for my local administration. Here's a sample to help you get started: http://www.postfix.org/DATABASE_README.html#safe_db -- Noel Jones
Re: forcing authenticated users to use port 587?
Jeff Weinberger a écrit : Hi: Based on good practice and the help and urging of some of the gurus on this list, I am moving my users to using the submission service (port 587) instead of port 25 to send mail from their mail clients. Once most of them move, I'd like to start warning the ones who don't that they should (ok, maybe just bugging them). But then I was thinking I might eventually want to require that they use port 587. My question is really two-fold: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? You are certainly using permit_sasl_authenticated. so to prevent auth on port 25, simply remove this check from smtpd_recipient_restrictions. 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? There are benefits in separating MX and submission functions, either by using different ports (recommended) or by using a different IP. for example, you can use different header_checks and body_checks. you can block some IPs/networks on 25 but still allow your users to come from these IPs... you avoid having to implement exceptions in your smtpd restrictions... etc. It is also hoped that future versions of MUAs will be support port 587 (they could try to see if it is available and propose it as the default port, ... etc). All that said, you don't need to go that road too quickly. Many users have no idea what you tell them (I've seen that with software developpers).
Re: multiple e-mails on from:
Noel Jones a écrit : Cameron Camp wrote: I have a Postfix setup which runs several mailman lists. I'm getting in the headers: From: nore...@domain.com, r...@www.domain.com The From: header is text added by the mail client or your list processor. This isn't a postfix issue. or his client uses From: noreply r...@www.domain.com and postfix adds @myorigin to the non fqdn component. In either case, he should fix his client. maybe he wants From: noreply r...@www.domain.com
Re: Reject_unlisted_recipient and wide aliasing
mouss escribió:
Roman Medina-Heigl Hernandez a écrit :
Noel Jones escribió:
[snip]
Use 1-1 mappings. Use a little script and a Makefile to let the
computer build the aliased domain from the real domain list you already
maintain. Size of the table is not an issue.
Your postconf output looks OK.
Yes, all tasks can usually be automatized but sometimes it's good to
simplify things.
[snip]
Here's an (I hope, illustrative) example of a mysql setup where this is
not a problem:
- table User contains user and domain columns.
- table DomainAlias contains alias and destination columns.
query = select User.domain from User, DomainAlias where
alias = '%s' and destination = domain
(the user column must never be empty).
I got the idea (i.e. playing with mysql tables) but I didn't catch your
example. Could you elaborate a bit? Which map would you use that query in?
Virtual_alias_maps?
I got my own (experimental) solution, which is not perfect either. Based on
my former config (see my former mail), I've added a second query to
virtual_alias_maps, so now it is:
virtual_alias_maps = mysql:/etc/postfix/valias.mysql,
mysql:/etc/postfix/vdomainalias.mysql
Query for:
- valias.mysql:
query = select destino from alias where origen = '%s'
- vdomainalias.mysql:
query = select user from user, domainalias where origen =
substring_index('%s', '@', -1) and user = concat( substring_index('%s',
'@', 1), '@', destino);
Tips:
- substring_index('%s', '@', -1) is the domain part of '%s'
- substring_index('%s', '@', 1) is the user part of '%s'
- destino = destination, and origen = source
I think it won't work with recursion, and it will not catch user aliases
either, but it could be a good starting point (it is working, if domain
alias directly point to a real -non-aliased- domain).
The limitation is that you can't use recursive domain aliases, so you
can't implement this:
@example.com @example.org
@example.org @example.net
but such recursive aliases would be expensive anyway, and one can
resolve them ahead of time (in the UI that adds them, for instance).
Yes, domain alias recursion wouldn't be a problem. But it should resolve
user aliases to be a complete solution.
Any ideas to improve this? I think this could be solved with more mysql
magic...
--
Saludos,
-Roman
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]
PATCH: bug from May 19, 1997
While adding a feature I ran into a problem that is so old that I had to dig into my pre-alpha source code to find when it was introduced. Bugfix (introduced May 19, 1997): removing a parameter setting from main.cf did not reset the parameter to its default value. File: global/mail_params.c. This has rarely been an issue because most Postfix processes run for a limited amount of time, and because people usually do postfix reload after making a change, so that all daemons except master terminate voluntarily. A redundant design does have benefits ... Wietse diff -bcr /var/tmp/postfix-2.6-20090106/src/global/mail_conf.c ./mail_conf.c *** /var/tmp/postfix-2.6-20090106/src/global/mail_conf.cSat Apr 10 10:52:51 2004 --- ./mail_conf.c Thu Jan 8 20:45:10 2009 *** *** 173,178 --- 173,181 geteuid() != 0) /* untrusted */ mail_conf_checkdir(var_config_dir); path = concatenate(var_config_dir, /, main.cf, (char *) 0); + /* In case a name=value pair is removed from main.cf. */ + if (dict_handle(CONFIG_DICT) != 0) + dict_unregister(CONFIG_DICT); dict_load_file(CONFIG_DICT, path); myfree(path); }
Re: PATCH: bug from May 19, 1997
Wietse Venema wrote: While adding a feature I ran into a problem that is so old that I had to dig into my pre-alpha source code to find when it was introduced. Bugfix (introduced May 19, 1997): removing a parameter setting from main.cf did not reset the parameter to its default value. File: global/mail_params.c. This has rarely been an issue because most Postfix processes run for a limited amount of time, and because people usually do postfix reload after making a change, so that all daemons except master terminate voluntarily. A redundant design does have benefits ... Wietse diff -bcr /var/tmp/postfix-2.6-20090106/src/global/mail_conf.c ./mail_conf.c *** /var/tmp/postfix-2.6-20090106/src/global/mail_conf.c Sat Apr 10 10:52:51 2004 --- ./mail_conf.c Thu Jan 8 20:45:10 2009 *** *** 173,178 --- 173,181 geteuid() != 0) /* untrusted */ mail_conf_checkdir(var_config_dir); path = concatenate(var_config_dir, /, main.cf, (char *) 0); + /* In case a name=value pair is removed from main.cf. */ + if (dict_handle(CONFIG_DICT) != 0) + dict_unregister(CONFIG_DICT); dict_load_file(CONFIG_DICT, path); myfree(path); } Just goes to show you.. that the work is never done! -Matt
getting dns error
Hello, I am getting the following error when sending to the below mail server. I added the name of our internal relay server to our public dns and a ptr record, but I am still getting the error below. snip host mxi4p.craigslist.org[208.82.236.164] said: 554 5.7.1 unknown[207.47.100.34]: Client host rejected: rDNS/DNS validation failed. Please setup matching DNS and rDNS records:(in reply to RCPT TO command) snip Is there something else I need to add the postfix server? This is an internal mail relay server, behind a firewall and not accessible to the public. It only sends mail for our internal users and does not receive mail. Many thanks, James
Re: getting dns error
James D. Parra wrote: I am getting the following error when sending to the below mail server. I added the name of our internal relay server to our public dns and a ptr record, but I am still getting the error below. snip host mxi4p.craigslist.org[208.82.236.164] said: 554 5.7.1 unknown[207.47.100.34]: Client host rejected: rDNS/DNS validation failed. Please setup matching DNS and rDNS records:(in reply to RCPT TO command) snip Is there something else I need to add the postfix server? This is an internal mail relay server, behind a firewall and not accessible to the public. It only sends mail for our internal users and does not receive mail. % host 207.47.100.34 34.100.47.207.in-addr.arpa domain name pointer 207.47.100.34.static.musicreports.com. % host 207.47.100.34.static.musicreports.com Host 207.47.100.34.static.musicreports.com not found: 3(NXDOMAIN) ^^ Fix that. -- Sahil Tandon sa...@tandon.net
Re: forcing authenticated users to use port 587?
On Jan 8, 2009, at 6:53 AM, Jorey Bump wrote: Jeff Weinberger wrote, at 01/08/2009 09:27 AM: Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? Actually, smtpd_sasl_auth_enable = no means that authentication is not enabled. IOW, Postfix won't offer 250-AUTH [mech list] after HELO/ EHLO. Attempts to authenticate will generate an error. Most modern clients are intelligent enough to detect the absence of AUTH and will not attempt to authenticate. Good ones will abort and notify the user. Bad ones might attempt to continue, in case the server will still accept the message. If the domain is a destination your server handles, it will probably accept the message, otherwise it will reject it. In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Thank you an thank you to Chris for your help on this! I just have two, maybe obvious questionsif I may; I noticed that on several occasions, and in the default master.cf: -o milter_macro_daemon_name=ORIGINATING is suggested for the submission service. I'm not familiar with Milters and can't find information on what this is or what this does (at least in my search of the docs). Can you offer any pointers to where I can learn more specifics about milter macro daemons and this specific one? Also you noted: In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Does smtpd_sasl_auth_enable = no completely disable submission and prevent relaying for hosts I don't accept? or is there more I have to make sure I do? thank you again! --Jeff
Re: PATCH: bug from May 19, 1997
On Thu, Jan 08, 2009 at 09:07:07PM -0500, Wietse Venema wrote: While adding a feature I ran into a problem that is so old that I had to dig into my pre-alpha source code to find when it was introduced. Bugfix (introduced May 19, 1997): removing a parameter setting from main.cf did not reset the parameter to its default value. File: global/mail_params.c. This has rarely been an issue because most Postfix processes run for a limited amount of time, and because people usually do postfix reload after making a change, so that all daemons except master terminate voluntarily. Translation, this only matters for parameters that change the behaviour of the master daemon. Removing such a parameter from main.cf did not result in changed master(8) behaviour without a full restart. Most users don't modify master(8) parameters other than inet_interfaces, and changing this without a restart is not supported. Thus no surprise that there have not been very many problem reports for this. By the way, will it be legal to do crazy things like change the queue_directory and/or data_directory of a running Postfix instance? -- 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: forcing authenticated users to use port 587?
Jeff Weinberger wrote: I noticed that on several occasions, and in the default master.cf: -o milter_macro_daemon_name=ORIGINATING is suggested for the submission service. I'm not familiar with Milters and can't find information on what this is or what this does (at least in my search of the docs). Can you offer any pointers to where I can learn more specifics about milter macro daemons and this specific one? This parameter is clearly defined in the documentation: http://www.postfix.org/postconf.5.html#milter_macro_daemon_name http://www.postfix.org/MILTER_README.html Also you noted: In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Does smtpd_sasl_auth_enable = no completely disable submission and prevent relaying for hosts I don't accept? or is there more I have to make sure I do? This disables submission via SASL authenticated clients on port 25. -- Sahil Tandon sa...@tandon.net
Cannot connect to smtp server
i have recently shifted to a different place. I had a functioning postfix setup on my laptop but it is not working in this new place. I use gmail's smtp server to send e-mail. Please note the following. 1. Internet works fine. 2. Evolution can send e-mail using the same smtp server account 3. I cannot ping any address on the internet. When I send the mail, it just stays in the queue. The results of mailq, tail /var/log/mail.log, and postconf -n are pasting below for reference. I shall be grateful if someone could help sort this out. Vikas mailq -Queue ID- --Size-- Arrival Time -Sender/Recipient--- 0B24711B785 506 Fri Jan 9 04:43:29 vi...@panahar (connect to smtp.gmail.com[66.249.93.111]:587: Connection timed out) villagestud...@yahoo.com -- 0 Kbytes in 1 Request. tail /var/log/mail.log Jan 9 04:44:25 panahar postfix/tlsmgr[5397]: warning: redirecting the request to postfix-owned data_directory /var/lib/postfix Jan 9 04:44:25 panahar postfix/tlsmgr[5397]: warning: request to update table btree:/var/run/smtp_tls_session_cache in non-postfix directory /var/run Jan 9 04:44:25 panahar postfix/tlsmgr[5397]: warning: redirecting the request to postfix-owned data_directory /var/lib/postfix Jan 9 04:44:55 panahar postfix/smtp[5396]: connect to smtp.gmail.com[66.249.93.109]:587: Connection timed out Jan 9 04:45:25 panahar postfix/smtp[5396]: connect to smtp.gmail.com[66.249.93.111]:587: Connection timed out Jan 9 04:45:25 panahar postfix/smtp[5396]: 0B24711B785: to=villagestud...@yahoo.com, relay=none, delay=116, delays=56/0.06/60/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[66.249.93.111]:587: Connection timed out) Jan 9 04:54:25 panahar postfix/qmgr[5394]: 0B24711B785: from=vi...@panahar, size=506, nrcpt=1 (queue active) Jan 9 04:54:55 panahar postfix/smtp[5630]: connect to smtp.gmail.com[66.249.93.109]:587: Connection timed out Jan 9 04:55:25 panahar postfix/smtp[5630]: connect to smtp.gmail.com[66.249.93.111]:587: Connection timed out Jan 9 04:55:25 panahar postfix/smtp[5630]: 0B24711B785: to=villagestud...@yahoo.com, relay=none, delay=716, delays=655/0.03/60/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[66.249.93.111]:587: Connection timed out) postconf -n append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes config_directory = /etc/postfix disable_dns_lookups = yes inet_protocols = all mailbox_command = procmail -a $EXTENSION mailbox_size_limit = 0 mydestination = shireen, localhost.localdomain, localhost, shireen.jnu.ac.in myhostname = shireen.jnu.ac.in mynetworks = 127.0.0.0/8 myorigin = /etc/mailname recipient_delimiter = + relayhost = [smtp.gmail.com] smtp_generic_maps = hash:/etc/postfix/generic smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous smtp_tls_CAfile = /etc/postfix/cacert.pem smtp_tls_cert_file = /etc/postfix/FOO-cert.pem smtp_tls_key_file = /etc/postfix/FOO-key.pem smtp_tls_loglevel = 1 smtp_tls_per_site = hash:/etc/postfix/tls_per_site smtp_tls_session_cache_database = btree:/var/run/smtp_tls_session_cache smtp_use_tls = yes smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) smtpd_sasl_auth_enable = no smtpd_sasl_local_domain = $myhostname smtpd_tls_CAfile = /etc/postfix/cacert.pem smtpd_tls_cert_file = /etc/postfix/FOO-cert.pem smtpd_tls_key_file = /etc/postfix/FOO-key.pem smtpd_tls_received_header = yes smtpd_tls_session_cache_database = btree:/var/run/smtpd_tls_session_cache smtpd_use_tls = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport
Re: Cannot connect to smtp server
At 08:56 PM 1/8/2009, you wrote: i have recently shifted to a different place. Uhhh do you mean a new internet provider? Or something else? I had a functioning postfix setup on my laptop but it is not working in this new place. I'm confused. Why are you running postfix on a laptop? I use gmail's smtp server to send e-mail. Why not use the SMTP server provided by your ISP? Please note the following. 1. Internet works fine. 2. Evolution can send e-mail using the same smtp server account 3. I cannot ping any address on the internet. Sounds like a ISP issue.. When I send the mail, it just stays in the queue. The results of mailq, tail /var/log/mail.log, and postconf -n are pasting below for reference. From the laptop, what happens when you telnet smtp.gmail.com 25 I shall be grateful if someone could help sort this out. relayhost = [smtp.gmail.com] Do you have the brackets in the main.cf? Not sure if that will cause a problem or not.
Re: Cannot connect to smtp server
On Friday, January 09, 2009 at 06:20 CET, Evan Platt e...@espphotography.com wrote: At 08:56 PM 1/8/2009, you wrote: [...] relayhost = [smtp.gmail.com] Do you have the brackets in the main.cf? Not sure if that will cause a problem or not. Quite the contrary -- they SHOULD be there in order to suppress MX lookups of the relayhost name. See the documentation. -- Magnus Bäck mag...@dsek.lth.se
Re: Cannot connect to smtp server
At 09:26 PM 1/8/2009, you wrote: Quite the contrary -- they SHOULD be there in order to suppress MX lookups of the relayhost name. See the documentation. Huh. Yer right. Never had that in my main.cf - never had a problem either. I added it and reloaded. Thanks for the edumacation :)
Re: Cannot connect to smtp server
Please send your replies to the list, not to me. At 09:58 PM 1/8/2009, you wrote: From the laptop, what happens when you telnet smtp.gmail.com 25 telnet smtp.gmail.com 25 Trying 66.249.93.109... Trying 66.249.93.111... telnet: Unable to connect to remote host: Connection refused But gmail does not only use port 25. It uses port 465 (with ssl) and 587 (with tls) as well. I can telnet to port 465. telnet smtp.gmail.com 465 Trying 66.249.93.111... Connected to gmail-smtp-msa.l.google.com. Escape character is '^]'. It occurred to me when I wrote the above that my postfix was using port 587. I have now changed the transport and sasl_passwd files to point them to port 465. The log now has the following. Jan 9 05:52:53 panahar postfix/smtp[8128]: 683BC11B785: conversation with smtp.gmail.com[66.249.93.109] timed out while receiving the initial server greeting Jan 9 05:53:53 panahar postfix/smtp[8157]: 37F8711B773: conversation with smtp.gmail.com[66.249.93.111] timed out while receiving the initial server greeting Any ideas? Vikas
Re: Cannot connect to smtp server
At 09:20 PM 1/8/2009, you wrote: From the laptop, what happens when you telnet smtp.gmail.com 25 My bad, this should be telnet smtp.gmail.com 587
Re: forcing authenticated users to use port 587?
--- In post...@yahoogroups.com, Sahil Tandon sa...@... wrote: Jeff Weinberger wrote: I noticed that on several occasions, and in the default master.cf: -o milter_macro_daemon_name=ORIGINATING is suggested for the submission service. I'm not familiar with Milters and can't find information on what this is or what this does (at least in my search of the docs). Can you offer any pointers to where I can learn more specifics about milter macro daemons and this specific one? This parameter is clearly defined in the documentation: http://www.postfix.org/postconf.5.html#milter_macro_daemon_name http://www.postfix.org/MILTER_README.html Thanks for pointing it out - I've read it several times already. ORIGINATING is not mentioned at all in MILTER_README. And while I'm sure the postconf(5) brief explanation is meaningful to you, it means nothing to me. As I noted, I am completely unfamiliar with milters, and don't know what a milter daemon is. I don't expect a tutorial, but I am hoping that the very knowledgeable people on this list can suggest somewhere where I can learn enough to understand what this: milter_macro_daemon_name=ORIGINATING does and what it means. Any explanation of why it is suggested in the default set up in the distribution is helpful as well. Thank you. Also you noted: In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Does smtpd_sasl_auth_enable = no completely disable submission and prevent relaying for hosts I don't accept? or is there more I have to make sure I do? This disables submission via SASL authenticated clients on port 25. -- Sahil Tandon sa...@...
