Re: Strange SASL Authentication Issue
Robert Krig: I've got a weird issue on one of my postfix installations that I can't explain. My postfix setup uses MySQL as an authentication backend, and the accounts are managed via Postfixadmin. All of our webservers use phpmailer to send out registration notices to users who register on our site. Now, there are plenty of other accounts on this mail server. Once in a while what happens, and ONLY with this one mail account which is used to send out registration emails, is that for no apparent reason SASL Authentication will stop working, but ONLY for that one account. All other accounts are happy to go about their Why do you believe that there is a problem with SASL authentication between the PHP application and Postfix? Your posting provides no concrete symptoms (logging!) that would allow the list to help you towards a solution. It is not unusual for people to confuse authentication and encryption. http://www.postfix.org/DEBUG_README.html#mail. DO NOT TURN ON VERBOSE LOGGING until asked to do so. The default Postfix logging may look like useless garbage to you, but it provides a lot of detail that gets drowned out out when you open the firehose. Wietse
Re: Disable sending mails via telnet
I´m testing a server, so I need to unable people[users], to connect via telnet[smtp.mydomain.com:25] to the mail server. 2012/1/10 Leslie León Sinclair les...@electrica.cujae.edu.cu: Can anyone point me in the right direction, I´m stucked here and Google is not helping... define telnet here, do you mean: direct connection to port 25? or an *actual* telnet session (port 23). Ildefonso. Best regards. Participe en Universidad 2012, del 13 al 17 de febrero de 2012. Habana, Cuba: http://www.congresouniversidad.cu Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu Participe en Universidad 2012, del 13 al 17 de febrero de 2012. Habana, Cuba: http://www.congresouniversidad.cu Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
Re: Disable sending mails via telnet
Telnet the protocol in port 25... On Tuesday, January 10, 2012, 16:45:25, Leslie León Sinclair wrote: Can anyone point me in the right direction, I´m stucked here and Google is not helping... TELNET the Protocol or a telnet client? Participe en Universidad 2012, del 13 al 17 de febrero de 2012. Habana, Cuba: http://www.congresouniversidad.cu Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
Re: Postfix 2.9 feature freeze for stable release
Wietse Venema: We are approaching the end of the Postfix 2.9 development cycle. In the past weeks I have been cleaning up Postfix database error handling without introducing new features (except for changing a bunch of fatal errors into less dramatic events). This is a good time to stop changing code and polish documentation. Courageous people are encouraged to grab a copy of the current snapshot (20120108 or later) and report any anomalies. Expect to see a stable Postfix 2.9 release in a few weeks from now. I've put out snapshot 20120110 yesterday. This improves the logging of various table lookup errors, fixes too verbose logging in the memcache client during cache cleanup, and continues the effort to turn fatal table lookup/update errors into warnings (graceful degradation). Wietse
Re: Disable sending mails via telnet
Sorry my mistake, I´m punishing myself right now, by the way I asked here in the list, but I was tired dealing with this problem. Reading yesterday´s mail now... I feel like a barbarian... It´s not gonna happen again, or at least, I will try. Good day to all... Welcome to the postfix-users mailing list. Upon subscribing, you should have received a message explaining how to ask for help, to wit: http://www.postfix.org/DEBUG_README.html#mail Participe en Universidad 2012, del 13 al 17 de febrero de 2012. Habana, Cuba: http://www.congresouniversidad.cu Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
Re: Disable sending mails via telnet
Leslie Le?n Sinclair: I?m testing a server, so I need to unable people[users], to connect via telnet[smtp.mydomain.com:25] to the mail server. So it is OK if they connect to your server with netcat, openssl s_client, any script written in Perl, Python, PHP, Javascript, with a real email client, with a botnet zombie, and so on? Wietse
Re: Strange SASL Authentication Issue
On Wednesday 11 January 2012 07:14:14 Wietse Venema wrote: Why do you believe that there is a problem with SASL authentication between the PHP application and Postfix? Because the only error that shows up in the log file is this: ## postfix/smtpd[7310]: connect from www2.domain.com[xx.xx.xx.xx] postfix/smtpd[7310]: warning: www2.domain.com[xx.xx.xx.xx]: SASL LOGIN authentication failed: authentication failure postfix/smtpd[7310]: lost connection after RSET from www2.domain.com[xx.xx.xx.xx] postfix/smtpd[7310]: disconnect from www2.domain.com[xx.xx.xx.xx] ## For comparison, this is what it normally looks like: ## postfix/smtpd[7310]: connect from www2.domain.com[xx.xx.xx.xx] postfix/smtpd[7310]: A406B202D9: client=www2.domain.com[xx.xx.xx.xx], sasl_method=LOGIN, sasl_username=nore...@domain.com postfix/cleanup[7309]: A406B202D9: message- id=7d3559e19e3c13f1aa342b9d5a33a...@www.domain.com postfix/qmgr[9970]: A406B202D9: from=i...@domain.com, size=733, nrcpt=1 (queue active) postfix/smtpd[7310]: disconnect from www2.domain.com[xx.xx.xx.xx] postfix/smtp[7360]: A406B202D9: to=u...@web.de, relay=mx- ha01.web.de[xxx.xx.xxx.xxx]:25, delay=0.21, delays=0.08/0.02/0.05/0.06, dsn=2.0.0, status=sent (250 OK id=1Rg1kQ-0002ax-00) postfix/qmgr[9970]: A406B202D9: removed ## Your posting provides no concrete symptoms (logging!) that would allow the list to help you towards a solution. It is not unusual for people to confuse authentication and encryption. http://www.postfix.org/DEBUG_README.html#mail. DO NOT TURN ON VERBOSE LOGGING until asked to do so. The default Postfix logging may look like useless garbage to you, but it provides a lot of detail that gets drowned out out when you open the firehose. Wietse I've enabled debug logging only for the affected hosts, so that my log files don't get overwhelmed with useless noise. Like I said, it's weird. If the affected clients could not send any mail it would be one thing, but why they seem to work fine for weeks and then once in a while simply refuse to authenticate properly, is beyond me. Could it have something to do with smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination which I have in my main.cf? The affected hosts are in my mynetworks list. As far as I understand it, this would mean that the hosts which are listed in mynetworks do not HAVE to authenticate. The phpmailer clients in this case are configured to try and authenticate with the proper username and password. Is there a possibility that there is a race condition of some sort? We have 4 webservers. www1, www2, www3, www4. They all use the same username and password to authenticate and send mail via the same account. Could there be a problem if they try to authenticate simultaneously? Or would it be better to remove the permit_mynetworks line, so that they are forced to authenticate properly? Whats weird is that the problem gets fixed by simply restarting the services.
Re: Disable sending mails via telnet
[ top-posting fixed, please do not do that here ] On Wednesday 11 January 2012 07:23:46 Leslie León Sinclair wrote: On Tuesday, January 10, 2012, 16:45:25, Leslie León Sinclair wrote: Can anyone point me in the right direction, I´m stucked here and Google is not helping... TELNET the Protocol or a telnet client? Telnet the protocol in port 25... Google is not helping because apparently you do not know what you are asking, nor have you yet understood the other posts in this thread. People can use telnet(1), the application, as a simple TCP text client. That application can connect directly to a SMTP server. If the user knows how to speak SMTP, the user can send mail. Postfix does not implement a telnetd(8) server. That would be an example of telnet the protocol. There is NO difference between a person using telnet(1) to speak SMTP or using any other mail client to speak SMTP. (Again, offer void where taxed or prohibited, or if the person does not understand SMTP adequately.) TCP is TCP. What you are asking is not possible. Perhaps you should consider why you think this goal is desirable or important. It is generally far harder to manually speak SMTP to a server than it is to configure a mail client. I use Kmail or mutt(1), myself. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Disable sending mails via telnet
First: I apology bellow about my yesterday´s behavior. My issue: I have a postfix[Debian] server, and it´s working nice, but I need to block people to send mails via telnet[telnet mydomain.com 25], everything is working nice and shiny, error/warning logs are empty, dovecot logging normal, no error so far, but still the issue. Now: I will do a VM with the same config and will test, on other machine, to see some changes in SASL and stuff related and later I post my results with main.cf included. Until then, please do not replys to my mails, I´ll be out for a while... Best regards... Sorry my mistake, I´m punishing myself right now, by the way I asked here in the list, but I was tired dealing with this problem. Reading yesterday´s mail now... I feel like a barbarian... It´s not gonna happen again, or at least, I will try. Good day to all... Participe en Universidad 2012, del 13 al 17 de febrero de 2012. Habana, Cuba: http://www.congresouniversidad.cu Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
RE: Disable sending mails via telnet
Just an idea, feel free to correct me. Is there some way within Postfix to implement a timeout on the SMTP conversation? Obviously a user typing HELO, MAIL FROM, RCPT TO etc will be a lot slower than a conversation between two computers. Of course this could break something else, like I said, just an idea. Kind Regards, James Day (IT Engineer) Ontraq Limited Tel: 01245 265100 Fax: 01245 265700 Web: www.ontraq.com -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Leslie León Sinclair Sent: 11 January 2012 13:49 To: postfix-users@postfix.org Subject: Re: Disable sending mails via telnet First: I apology bellow about my yesterday´s behavior. My issue: I have a postfix[Debian] server, and it´s working nice, but I need to block people to send mails via telnet[telnet mydomain.com 25], everything is working nice and shiny, error/warning logs are empty, dovecot logging normal, no error so far, but still the issue. Now: I will do a VM with the same config and will test, on other machine, to see some changes in SASL and stuff related and later I post my results with main.cf included. Until then, please do not replys to my mails, I´ll be out for a while... Best regards... Sorry my mistake, I´m punishing myself right now, by the way I asked here in the list, but I was tired dealing with this problem. Reading yesterday´s mail now... I feel like a barbarian... It´s not gonna happen again, or at least, I will try. Good day to all... Participe en Universidad 2012, del 13 al 17 de febrero de 2012. Habana, Cuba: http://www.congresouniversidad.cu Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
Re: Strange SASL Authentication Issue
Robert Krig: On Wednesday 11 January 2012 07:14:14 Wietse Venema wrote: Why do you believe that there is a problem with SASL authentication between the PHP application and Postfix? Because the only error that shows up in the log file is this: ## postfix/smtpd[7310]: connect from www2.domain.com[xx.xx.xx.xx] postfix/smtpd[7310]: warning: www2.domain.com[xx.xx.xx.xx]: SASL LOGIN authentication failed: authentication failure Fortunately, the Postfix SMTP server is a short-lived process that runs for a few minutes at a time without ever changing the system configuration. Every new Postfix SMTP server process is like a new-born with a blank memory of its past. Therefore, if SASL logins fail, especially when they fail persistently, then either the SASL client has changed, or the SASL server infrastructure **outside POSTFIX** has changed. This would be a good time to provide configuration information about how Postfix interfaces to the SASL server infrastructure **outside POSTFIX**. There are two such possible infrastructures: Dovecot or Cyrus SASL. This choice is made with the smtpd_sasl_type parameter. Examine the output from: # postconf smtpd_sasl_type If this is dovecot, you need to check the Dovecot authentication server logs. If this is cyrus, you need to report what's in the smtpd.conf file, whose location depends on how your distributor has tweaked the details of the SASL server infrastructure **outside POSTFIX**. This file could be located in /usr/local/lib/sasl2, in /etc/postfix, or any number of other places. I suggest doing: # find / -name smtpd.conf and reporting the contents of any files thus found. Wietse
Re: Strange SASL Authentication Issue
On Wednesday 11 January 2012 07:45:46 Robert Krig wrote: On Wednesday 11 January 2012 07:14:14 Wietse Venema wrote: Why do you believe that there is a problem with SASL authentication between the PHP application and Postfix? Because the only error that shows up in the log file is this: ## postfix/smtpd[7310]: connect from www2.domain.com[xx.xx.xx.xx] postfix/smtpd[7310]: warning: www2.domain.com[xx.xx.xx.xx]: SASL LOGIN authentication failed: authentication failure postfix/smtpd[7310]: lost connection after RSET from www2.domain.com[xx.xx.xx.xx] postfix/smtpd[7310]: disconnect from www2.domain.com[xx.xx.xx.xx] Postfix is the messenger, the relay between the authenticating client and the SASL backend. It is only reporting what happened. BTW, unless you actually own domain.com (you surely do not) you should not use it as an example. Example.com (.net, .org) and others in gTLDs and many ccTLDs have been set aside for examples. snip Your posting provides no concrete symptoms (logging!) that would allow the list to help you towards a solution. It is not unusual for people to confuse authentication and encryption. http://www.postfix.org/DEBUG_README.html#mail. DO NOT TURN ON VERBOSE LOGGING until asked to do so. The default Postfix logging may look like useless garbage to you, but it provides a lot of detail that gets drowned out out when you open the firehose. I've enabled debug logging only for the affected hosts, so that my log files don't get overwhelmed with useless noise. Still useless and not going to help. Either the authentication succeeds or not. You won't find anything useful in Postfix verbose logs. And the logging you did share this time did not indicate a Postfix problem. Like I said, it's weird. If the affected clients could not send any mail it would be one thing, but why they seem to work fine for weeks and then once in a while simply refuse to authenticate properly, is beyond me. It must be a problem in the SASL backend and/or its data source. Could it have something to do with smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination which I have in my main.cf? No. The affected hosts are in my mynetworks list. As far as I understand it, this would mean that the hosts which are listed in mynetworks do not HAVE to authenticate. Correct. The phpmailer clients in this case are configured to try and authenticate with the proper username and password. If they attempted without authentication, and as you say, they are listed in mynetworks, they would succeed. Is there a possibility that there is a race condition of some sort? No, or at least not something relevant to this list, which is for Postfix support. We have 4 webservers. www1, www2, www3, www4. They all use the same username and password to authenticate and send mail via the same account. Could there be a problem if they try to authenticate simultaneously? Check the SASL documentation and logs. Or would it be better to remove the permit_mynetworks line, so that they are forced to authenticate properly? That is a policy decision for you to make. Whats weird is that the problem gets fixed by simply restarting the services. Try it without restarting Postfix next time, just your saslauthd and anything it needs for data (e.g., mysqld, postmaster, whatever.) You do not have a Postfix issue. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Strange SASL Authentication Issue
On Wednesday 11 January 2012 08:08:34 I wrote: On Wednesday 11 January 2012 07:45:46 Robert Krig wrote: Whats weird is that the problem gets fixed by simply restarting the services. Try it without restarting Postfix next time, just your saslauthd and anything it needs for data (e.g., mysqld, postmaster, whatever.) You do not have a Postfix issue. Forgot to mention Courier authdaemond, mentioned in the OP. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: dict_memcache_sequence log entries in 2.9-20120108
Confirm fixed in the 20120110 snapshot.
Thanks!
-- Noel Jones
On 1/10/2012 6:05 PM, Wietse Venema wrote:
Noel Jones:
I notice after installing postfix-2.9-20120108 I get thousands of
log entries such as (valid username redacted)
Jan 10 16:54:09 mgate3 postfix/verify[57527]:
dict_memcache_sequence: /etc/postfix/maps/memcache_verify.cf: key
u...@example.org = 0:0:1325186726:250 ok its for u...@example.org
and
Jan 10 14:58:46 mgate3 postfix/postscreen[33675]:
dict_memcache_sequence:
/etc/postfix/maps/memcache_postscreen_cache.cf: key 98.139.91.98
= 1325955071;1325872271;1;1;1;0
I didn't get these with the previous snapshot. Did I screw
something up or are these just left-over development messages?
There's a missing if (msg_verbose) before line 466. I didn't notice
this because cache scans happen only a few times a day.
Wietse
464 } else {
465 seq_res = backup-sequence(backup, function, key, value);
466 msg_info(%s: %s: key \%s\ = %s,
467 myname, dict_mc-dict.name, *key ? *key : (not
found),
468 *value ? *value : backup-error ? (backup error) :
469 (not found));
470 DICT_ERR_VAL_RETURN(dict, backup-error, seq_res);
471 }
Re: Strange SASL Authentication Issue
On Wednesday 11 January 2012 09:08:03 Wietse Venema wrote: Fortunately, the Postfix SMTP server is a short-lived process that runs for a few minutes at a time without ever changing the system configuration. Every new Postfix SMTP server process is like a new-born with a blank memory of its past. Therefore, if SASL logins fail, especially when they fail persistently, then either the SASL client has changed, or the SASL server infrastructure **outside POSTFIX** has changed. But thats just it, they don't fail persistently. I mean, it all works fine, until all of a sudden it doesn't anymore and only for these accounts. The other accounts continue to work fine. This would be a good time to provide configuration information about how Postfix interfaces to the SASL server infrastructure **outside POSTFIX**. There are two such possible infrastructures: Dovecot or Cyrus SASL. This choice is made with the smtpd_sasl_type parameter. Examine the output from: # postconf smtpd_sasl_type smtpd_sasl_type = cyrus If this is cyrus, you need to report what's in the smtpd.conf file, whose location depends on how your distributor has tweaked the details of the SASL server infrastructure **outside POSTFIX**. This file could be located in /usr/local/lib/sasl2, in /etc/postfix, or any number of other places. /usr/lib/sasl2/smtpd.conf ## pwcheck_method: saslauthd mech_list: plain login saslauthd_path: /var/run/saslauthd/mux log_level: 7 ## /etc/authlib/authmysqlrc ### MYSQL_SERVER localhost MYSQL_PORT 3306 MYSQL_USERNAME postfix_user MYSQL_PASSWORD postfixpassword MYSQL_DATABASE postfix_db MYSQL_USER_TABLEmailbox MYSQL_CRYPT_PWFIELD password MYSQL_UID_FIELD 5000 MYSQL_GID_FIELD 5000 MYSQL_LOGIN_FIELD username MYSQL_HOME_FIELD/home/vmail MYSQL_NAME_FIELDname MYSQL_MAILDIR_FIELD maildir MYSQL_QUOTA_FIELD quota ### /etc/authlib/authdaemonrc ### authmodulelist=authmysql authmodulelistorig=authuserdb authpam authpwd authshadow authpgsql authldap authmysql authcustom authpipe daemons=5 authdaemonvar=/var/spool/authdaemon DEBUG_LOGIN=2 DEFAULTOPTIONS= LOGGEROPTS= ### /etc/conf.d/saslauthd ### SASLAUTHD_OPTS=-m /var/run/saslauthd -r -a pam ### By the way, I'm running Arch Linux, in case thats relevant. (You never know)
Stan's List [was: free antivirus scanner ?]
I'm searching for a friend (who has very few money) an open source antivirus scanner for email server that works with Postfix. Any infos/links/advices welcome One link, Google, would have easily found clamav. Info/advice: with postscreen(8), sane HELO restrictions, and good DNSBLs, clamav is not going to get much use. http://www.postfix.org/POSTSCREEN_README.html -- Postfix 2.8 req'd http://readlist.com/lists/postfix.org/postfix-users/28/140973.html http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt http://www.spamhaus.org/zen/ -- worth the cost if not gratis for you http://www.spamhaus.org/whitepapers/effective_filtering.html http://barracudacentral.org/rbl -- gratis but registration req'd http://www.hardwarefreak.com/fqrdns.pcre -- Stan's big list I've been curious about Stan's list of pcres. It looks massive, and Stan seems to be a regular expert contributer here. But I'm reluctant to start using a text file from a web site with nothing on it and only a bit of documentation in the file itself (not saying it's not sufficiently clear to implement, just that I don't feel like I have enough info to judge if the list will continue to be supported, if it's supported by more than one person, if it's supported just as a hobby or not, whether or not many other administrators are making use of it..) So who is using Stan's list? What do people have to say about it? What should I consider in regard to possibly implementing it?
Re: Strange SASL Authentication Issue
Robert Krig: On Wednesday 11 January 2012 09:08:03 Wietse Venema wrote: Fortunately, the Postfix SMTP server is a short-lived process that runs for a few minutes at a time without ever changing the system configuration. Every new Postfix SMTP server process is like a new-born with a blank memory of its past. Therefore, if SASL logins fail, especially when they fail persistently, then either the SASL client has changed, or the SASL server infrastructure **outside POSTFIX** has changed. But thats just it, they don't fail persistently. I mean, it all works fine, until all of a sudden it doesn't anymore and only for these accounts. The other accounts continue to work fine. Some accounts fail persistently, if I recall correctly. This happens outside the non-persistent Postfix SMTP server, which maintains no memory of what has happened previously. This part is really simple. Now, let's look where errors can persist: /usr/lib/sasl2/smtpd.conf pwcheck_method: saslauthd The non-persistent Postfix SMTP server talks to the Cyrus SASL library, which talks to the persistent saslauthd process. /etc/conf.d/saslauthd SASLAUTHD_OPTS=-m /var/run/saslauthd -r -a pam The persistent saslauthd process talks to the PAM subsystem. /etc/authlib/authdaemonrc authmodulelist=authmysql And PAM talks to the persistent MySQL server. Somewhere in this chain, the information about some accounts gets messed up, and the corruption is persistent. I therefore suggest looking at any one of the PERSISTENT processes in this chain, instead of the non-persistent processes from Postfix. Wietse
TLS untrusted/trusted
Hello list,
I've set up clientside TLS with postfix 2.7.1 as follows:
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
/etc/postfix/tls_policy:
empty
When sending a message (sendmail u...@mydomain.com) I get these loglines:
postfix/smtp[7537]: setting up TLS connection to
mail.example.com[aaa.bbb.ccc.ddd]:25
postfix/smtp[7537]: Untrusted TLS connection established to
mail.example.com[aaa.bbb.ccc.ddd]:25: TLSv1 with cipher ADH-CAMELLIA256-SHA
(256/256 bits)
After overwriting the default policy
/etc/postfix/tls_policy:
[mail.example.com] verify
I get the following:
postfix/smtp[7567]: setting up TLS connection to
mail.example.com[aaa.bbb.ccc.ddd]:25
postfix/smtp[7567]: Verified TLS connection established to
mail.example.com[aaa.bbb.ccc.ddd]:25: TLSv1 with cipher
DHE-RSA-CAMELLIA256-SHA (256/256 bits)
And now the TLS connection is trusted and verified. Why isn't it verfied with
'smtp_tls_security_level = may'?
Thanks for your help.
Best regards
Stefan
Re: Stan's List [was: free antivirus scanner ?]
On 2012-01-11 10:12 AM, email builder emailbuilde...@yahoo.com wrote: So who is using Stan's list? What do people have to say about it? What should I consider in regard to possibly implementing it? I am using it (for a while now)... This isn't really like a DNSBL, it simply rejects hosts that are 'spammy', meaning, on dynamic IPs - ie, botnets... There really is very little worry about FPs (false positives) now, and it doesn't need a lot of maintenance... even if Stan never updated it again, it would continue to be useful and with little to no FPs probably for many years to come... Try it, you'll be glad you did... ;) -- Best regards, Charles
Re: Disable sending mails via telnet
On Wednesday, January 11, 2012, 08:58:40, James Day wrote: Just an idea, feel free to correct me. Is there some way within Postfix to implement a timeout on the SMTP conversation? there are numerous mumble_timeout parameters. Obviously a user typing HELO, MAIL FROM, RCPT TO etc will be a lot slower than a conversation between two computers. Of course this could break something else, like I said, just an idea. The suggested (i.e. SHOULD) SMTP timeouts are given in minutes. No human typing the commands is going to have any difficulty. -- r...@polylogics.com The avalanche has already started, it is too Rod Dorman late for the pebbles to vote. - Ambassador Kosh
Re: Stan's List [was: free antivirus scanner ?]
On 1/11/2012 9:12 AM, email builder wrote: I'm searching for a friend (who has very few money) an open source antivirus scanner for email server that works with Postfix. Any infos/links/advices welcome One link, Google, would have easily found clamav. Info/advice: with postscreen(8), sane HELO restrictions, and good DNSBLs, clamav is not going to get much use. http://www.postfix.org/POSTSCREEN_README.html -- Postfix 2.8 req'd http://readlist.com/lists/postfix.org/postfix-users/28/140973.html http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt http://www.spamhaus.org/zen/ -- worth the cost if not gratis for you http://www.spamhaus.org/whitepapers/effective_filtering.html http://barracudacentral.org/rbl -- gratis but registration req'd http://www.hardwarefreak.com/fqrdns.pcre -- Stan's big list I've been curious about Stan's list of pcres. It looks massive, and Stan seems to be a regular expert contributer here. But I'm reluctant to start using a text file from a web site with nothing on it and only a bit of documentation in the file itself (not saying it's not sufficiently clear to implement, just that I don't feel like I have enough info to judge if the list will continue to be supported, if it's supported by more than one person, if it's supported just as a hobby or not, whether or not many other administrators are making use of it..) So who is using Stan's list? What do people have to say about it? What should I consider in regard to possibly implementing it? I use it. Stan occasionally updates it based his experience and user feedback. I see the last update was 2011/08. Unlike a dnsbl, this list does not require much updating; a few times a year is adequate. I would consider the list a hobby like many other non-commercial free antispam services. If Stan decides to stop supporting and/or publishing it, it will still keep on working, and someone else might volunteer official maintenance. Since it's basically a text file, any user is free to add/remove entries as they see fit. I expect that even with zero updates the file would continue to be fairly effective for years. As stated elsewhere, the intent of the file is to reject consumer dynamic internet connections without the overhead of a DNS lookup. Connections from these hosts are almost always spambots doing direct-to-MX spamming. I would classify it as low risk of false positives, and fairly safe. (but not 100% safe; few rules are. YMMV and such.) I've had a couple of FP's from idiots that run their business mail servers on a cablemodem with a dynamic rDNS name (their IP is static, but the rDNS incorrectly says dynamic), so I added their IP to a local whitelist. You may or may not run into the same easily-fixed problem. Use it like: smtpd_client_restrictions = permit_mynetworks # uncomment next line if using SASL # permit_sasl_authenticated check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre For testing, you can prepend warn_if_reject like this: warn_if_reject reject_reverse_client... This causes postfix to log a warning: message without actually rejecting the mail. Then examine the log for anything interesting. It can alternately be used in smtpd_recipient_restrictions (or any smtpd_*_restrictions sections), but be sure it's after permit_mynetworks and permit_sasl_authenticated so you don't reject your own authorized users. If you have an old postfix version that doesn't have the check_reverse_client_hostname_access restriction, you'll need to use check_client_access instead. The check_client_access will be a little less effective, but doesn't affect safety. -- Noel Jones
Re: Strange SASL Authentication Issue
On Wednesday 11 January 2012 10:15:19 Wietse Venema wrote: Some accounts fail persistently, if I recall correctly. Sorry, I think you misunderstood me. Let me explain again. Our 4 webservers CONSTANTLY send registration emails to new users via a local php-mailer on each webserver instance which connects to our central postfix mail server. This works, except on rare occasions when it fails without explanation. This is what I find so puzzling. It's not consistent behaviour, and I haven't yet found what causes it, or been able to reproduce it. It seems to happen at random. Sometimes it can be weeks before it happens again. Once it happens, only THAT account is unable to authenticate until I restart all relevant daemons. So, a user registers on our website via one of our webservers. In this case www1, www2, www3 or www4. All our webservers use the same account to send a registration confirmation email to the new user. In this case nore...@example.com This happens via a local phpmailer instance on each webserver. The phpmailer simply sends the registration mail via smtp to our postfix server using the nore...@example.com account. Either way, I'll try what you suggested and see if I can't find anymore clues. On our postfix server, we have lots of other accounts and domains. But the weirdest thing is, when THAT account stops working, all others still continue to work as normal. That's what makes it so difficult to catch that there is a problem. If the mail server itself suddenly completely stopped working, we would notice this immediately. But as it is, it's only the webservers trying to send registration emails via that one account.
Re: Strange SASL Authentication Issue
Robert Krig: On Wednesday 11 January 2012 10:15:19 Wietse Venema wrote: Some accounts fail persistently, if I recall correctly. Sorry, I think you misunderstood me. Let me explain again. You have a problem that starts at some unpredictable moment, and that causes SOME ACCOUNTs to fail PERSISTENTLY after it starts. This is typical of one PERSISTENT process (like saslauthd or mysqld) having some corruption of some kind, that PERSISTS until you restart that PERSISTENT process. The Postfix SMTP server is not a persistent process. It is just the messenger of the bad news. I am done helping you. Good luck. Wietse
Re: Disable sending mails via telnet
On Wed, 11 Jan 2012, Rod Dorman wrote: The suggested (i.e. SHOULD) SMTP timeouts are given in minutes. No human typing the commands is going to have any difficulty. Never underestimate the power (or lack thereof) of a hunt-and-pecker unfamiliar with coputers tasked with doing this. =) -Dennis
Re: Disable sending mails via telnet
On Wed, 11 Jan 2012, Leslie León Sinclair wrote: I´m testing a server, so I need to unable people[users], to connect via telnet[smtp.mydomain.com:25] to the mail server. If you're testing it, your best bet is to either a) bring it up as long as you need to test it, and then shut it down when you don't (ONLY for the purpose of testing), or b) set configuration to only allow mail from localhost - so this way, a user on the machine the server resides on could, in theory, type 'telnet localhost 25', but this assumes that the telnet client is installed thereon Keep in mind, though, that there are people who keep the telnet client on machines that you don't have control of - and in my case, I keep it around to debug occasionally. You won't have control fo those machines, and direct telnet into a SMTP server is really not a security hole. -Dennis
Re: Strange SASL Authentication Issue
On Wednesday 11 January 2012 11:38:13 Wietse Venema wrote: You have a problem that starts at some unpredictable moment, and that causes SOME ACCOUNTs to fail PERSISTENTLY after it starts. This is typical of one PERSISTENT process (like saslauthd or mysqld) having some corruption of some kind, that PERSISTS until you restart that PERSISTENT process. The Postfix SMTP server is not a persistent process. It is just the messenger of the bad news. I am done helping you. Good luck. Wietse Sorry, didn't mean to sound rude or ungrateful. I think I simply misunderstood you the first time. Anyways, thanks you for help.
Global user delivery
Is it possible to use a global user address to manage the delivery to final destination. So delivery looks something like u...@myhost.tld glo...@myhost.tld u...@destination.tld If this is possible, could such scenario create any holes or overides the normal control of realy processing. And would it be transparent, meaning without rewriting or messing with the header. Some examples is appreciated, and where I can read more about this.
Re: Global user delivery
On 1/11/2012 11:02 AM, Andreas Berton wrote: Is it possible to use a global user address to manage the delivery to final destination. So delivery looks something like u...@myhost.tld glo...@myhost.tld u...@destination.tld If this is possible, could such scenario create any holes or overides the normal control of realy processing. And would it be transparent, meaning without rewriting or messing with the header. Some examples is appreciated, and where I can read more about this. Maybe I'm just dense, but I have no idea what you're asking for. Mail has a single envelope sender with one or more recipients. The From: header (which is what most mail clients display) can list a sender different from the envelope, or even multiple senders. Please take a couple steps back and describe the problem you're tying to solve rather than how to implement a possible solution. -- Noel Jones
Re: Whitelist only for child email account
On Wed, Jan 11, 2012 at 08:30:44PM +1100, Nick Urbanik wrote: Dear Folks, I am running postfix 2.3.3 with dovecot 2.1. Do you really use an ancient postfix with an not yet released dovecot, or is this a typo? I have a child for whom I want to make an email account to which mail can only be sent from email addresses in a whitelist hash file. Have a kook at http://www.postfix.org/RESTRICTION_CLASS_README.html. It would be something like this in main.cf: smtpd_restriction_classes = child child = check_recipient_access hash:/etc/postfix/childs_whitelist, reject # Probably you want this only on your submission port, or you # might become partly an open relay. To avoid this add '-o # smtpd_sender_restrictions=$submission_smtpd_sender_restrictions' # to your definition of submission in master.cf submission_smtpd_sender_restrictions check_sender_access hash:/etc/postfix/childs_access your childs email goes to childs_access: ch...@nicku.org child and the allowed recipients are collected in childs_whitelist: fri...@exmaple.org permit some...@example.net permit # allow every address with your domain nicku.org permit Don't forget to postmap the access tables: # postmap hash:/etc/postfix/childs_whitelist # postmap hash:/etc/postfix/childs_access This example is untestet but should work. But of course, you should not implement anything you do not fully understand. Dennis
Re: TLS untrusted/trusted
On Wed, Jan 11, 2012 at 04:15:17PM +0100, Stefan wrote: Hello list, mail.example.com[aaa.bbb.ccc.ddd]:25: TLSv1 with cipher ADH-CAMELLIA256-SHA This is an anonymous cipher. With smtpd_tls_mandatory_exclude_ciphers = aNULL or smtpd_tls_exclude_ciphers = aNULL you can disable the useage of anonymous ciphers. Take a look at http://www.postfix.org/TLS_README.html#server_cipher. Dennis
Re: Strange SASL Authentication Issue
Robert Krig: On Wednesday 11 January 2012 11:38:13 Wietse Venema wrote: You have a problem that starts at some unpredictable moment, and that causes SOME ACCOUNTs to fail PERSISTENTLY after it starts. This is typical of one PERSISTENT process (like saslauthd or mysqld) having some corruption of some kind, that PERSISTS until you restart that PERSISTENT process. The Postfix SMTP server is not a persistent process. It is just the messenger of the bad news. I am done helping you. Good luck. Wietse Sorry, didn't mean to sound rude or ungrateful. I think I simply misunderstood you the first time. Anyways, thanks you for help. No offense taken, you just appeared to be focused on the wrong part of the problem (the fact that it turns on at unpredicable times). I hope that the search for the culprit (saslauthd, mysqld or perhaps the NSCD daemon, that's one I forgot to mention) will get the problem resolved. Wietse
Re: TLS untrusted/trusted
On Wed, Jan 11, 2012 at 04:15:17PM +0100, Stefan wrote:
I've set up clientside TLS with postfix 2.7.1 as follows:
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_loglevel = 1
smtp_tls_security_level = may
For all destinations, except any listed in policy_maps at a security
level of verify, fingerprint or secure, you don't care about
the certificate of the server, and Postfix 2.9 will not waste your
time with warnings about trust chain verification failures.
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
/etc/postfix/tls_policy:
empty
You can save some CPU, I/O and RAM by not setting a policy table
at all, if the table is always going to remain empty.
When sending a message (sendmail u...@mydomain.com) I get these loglines:
postfix/smtp[7537]: setting up TLS connection to
mail.example.com[aaa.bbb.ccc.ddd]:25
postfix/smtp[7537]: Untrusted TLS connection established to
mail.example.com[aaa.bbb.ccc.ddd]:25: TLSv1 with cipher ADH-CAMELLIA256-SHA
(256/256 bits)
This is of no consequence. The connection did not negotiate any certs, so
so no trust information is available.
/etc/postfix/tls_policy:
[mail.example.com] verify
I get the following:
postfix/smtp[7567]: setting up TLS connection to
mail.example.com[aaa.bbb.ccc.ddd]:25
postfix/smtp[7567]: Verified TLS connection established to
mail.example.com[aaa.bbb.ccc.ddd]:25: TLSv1 with cipher
DHE-RSA-CAMELLIA256-SHA (256/256 bits)
Now certificates were obtained and verified.
And now the TLS connection is trusted and verified. Why isn't it verfied with
'smtp_tls_security_level = may'?
Because the verification with may is futile, you'll deliver even if it failed,
and even over a plaintext connection, so no verification takes place and no
certs are exchanged, saving CPU and bandwidth.
--
Viktor.
Re: TLS untrusted/trusted
On Wed, Jan 11, 2012 at 07:08:30PM +0100, Dennis Guhl wrote: On Wed, Jan 11, 2012 at 04:15:17PM +0100, Stefan wrote: Hello list, mail.example.com[aaa.bbb.ccc.ddd]:25: TLSv1 with cipher ADH-CAMELLIA256-SHA This is an anonymous cipher. With smtpd_tls_mandatory_exclude_ciphers = aNULL or smtpd_tls_exclude_ciphers = aNULL you can disable the useage of anonymous ciphers. Can, but SHOULD NOT. There is no need to restrict the cipher selection in this way or to waste CPU and bandwidth exchanging ignored certificates. -- Viktor.
Re: TLS untrusted/trusted
On Wed, Jan 11, 2012 at 06:14:35PM +, Viktor Dukhovni wrote: On Wed, Jan 11, 2012 at 07:08:30PM +0100, Dennis Guhl wrote: On Wed, Jan 11, 2012 at 04:15:17PM +0100, Stefan wrote: Hello list, mail.example.com[aaa.bbb.ccc.ddd]:25: TLSv1 with cipher ADH-CAMELLIA256-SHA This is an anonymous cipher. With [..] you can disable the useage of anonymous ciphers. Can, but SHOULD NOT. There is no need to restrict the cipher selection in this way or to waste CPU and bandwidth exchanging ignored certificates. I deliberately said nothing about smtp_tls_security_level = may or why it will be senseless to ask for a certificate to verify in this case. Dennis
Re: Stan's List [was: free antivirus scanner ?]
On Wed, 11 Jan 2012 10:19:36 -0600, Noel Jones njo...@megan.vbhcs.org wrote: I would classify it as low risk of false positives, and fairly safe. (but not 100% safe; few rules are. YMMV and such.) I've had a couple of FP's from idiots that run their business mail servers on a cablemodem with a dynamic rDNS name (their IP is static, but the rDNS incorrectly says dynamic), so I added their IP to a local whitelist. You may or may not run into the same easily-fixed problem. Use it like: smtpd_client_restrictions = permit_mynetworks # uncomment next line if using SASL # permit_sasl_authenticated check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre I would also be interesting to be able to use a similar mechanism earlier, from the postscreen_access_list (after permit_mynetworks but before going outside to fetch the postscreen_dnsbl_* stuff): postscreen_access_list = permit_mynetworks, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre But http://www.postfix.org/postconf.5.html#postscreen_access_list states: To discourage the use of hash, btree, etc. tables, there is no support for substring matching like smtpd(8). Use CIDR tables instead. M.
Re: Stan's List [was: free antivirus scanner ?]
On Wednesday 11 January 2012 12:52:42 Mark Alan wrote: I would also be interesting to be able to use a similar mechanism earlier, from the postscreen_access_list (after permit_mynetworks but before going outside to fetch the postscreen_dnsbl_* stuff): postscreen_access_list = permit_mynetworks, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre Not possible, because postscreen does not look up PTR. But http://www.postfix.org/postconf.5.html#postscreen_access_list states: (This link also lists all possible actions, and check_reverse_client_hostname_access is not among them.) To discourage the use of hash, btree, etc. tables, there is no support for substring matching like smtpd(8). Use CIDR tables instead. But this is merely a dumbed-down version of check_client_access, so you're out of luck on this one. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
RE: Strange SASL Authentication Issue
Restarting postfix, saslauthd and authdaemon seems to get it working again, at least for a while. Are you using pam_mysql by chance?
Including state information in Received fields
Hi, I'm co-authoring a draft that would add supplementary information to Received header fields indicating when a message enters some kind of administrative hold. This would be useful to people looking through trace data to figure out why a message sat on a machine for some time, if the reason is something other than a hop that took a long time to complete for connectivity reasons. The draft specification is here: https://datatracker.ietf.org/doc/draft-kucherawy-received-state/ Would postfix be willing to implement something like this? At a minimum, it might be useful to use this to indicate that a milter application requested that a message be quarantined until an operator released it. Thanks, -MSK
Re: Postfix cyrus-sasl 2.1.25 issues
--On Friday, January 06, 2012 11:05 AM +0200 Eray Aslan eray.as...@caf.com.tr wrote: There are reports of broken PLAIN and LOGIN mechs with cyrus-sasl 2.1.25. But I can't reproduce it. If you compile any auxprop plugins (like you have), you will never see it. It's a bug in the auxprop loader rewrite that is only triggered if one elects to have no auxprop plugins. https://bugzilla.cyrusimap.org/show_bug.cgi?id=3625 --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: Stan's List [was: free antivirus scanner ?]
On Wed, 11 Jan 2012 07:12:15 -0800 (PST), email builder wrote: So who is using Stan's list? its blowing in the wind What do people have to say about it? good What should I consider in regard to possibly implementing it? ask for paypal account to pay Stan
Re: Postfix cyrus-sasl 2.1.25 issues
--On Wednesday, January 11, 2012 1:13 PM -0800 Quanah Gibson-Mount qua...@zimbra.com wrote: --On Friday, January 06, 2012 11:05 AM +0200 Eray Aslan eray.as...@caf.com.tr wrote: There are reports of broken PLAIN and LOGIN mechs with cyrus-sasl 2.1.25. But I can't reproduce it. If you compile any auxprop plugins (like you have), you will never see it. It's a bug in the auxprop loader rewrite that is only triggered if one elects to have no auxprop plugins. https://bugzilla.cyrusimap.org/show_bug.cgi?id=3625 Better fix in: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3590 --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: Stan's List [was: free antivirus scanner ?]
http://www.hardwarefreak.com/fqrdns.pcre -- Stan's big list I've been curious about Stan's list of pcres. It looks massive, and Stan seems to be a regular expert contributer here. But I'm reluctant to start using a text file from a web site with nothing on it and only a bit of documentation in the file itself (not saying it's not sufficiently clear to implement, just that I don't feel like I have enough info to judge if the list will continue to be supported, if it's supported by more than one person, if it's supported just as a hobby or not, whether or not many other administrators are making use of it..) So who is using Stan's list? What do people have to say about it? What should I consider in regard to possibly implementing it? I use it. Stan occasionally updates it based his experience and user feedback. I see the last update was 2011/08. Unlike a dnsbl, this list does not require much updating; a few times a year is adequate. I would consider the list a hobby like many other non-commercial free antispam services. If Stan decides to stop supporting and/or publishing it, it will still keep on working, and someone else might volunteer official maintenance. Since it's basically a text file, any user is free to add/remove entries as they see fit. I expect that even with zero updates the file would continue to be fairly effective for years. As stated elsewhere, the intent of the file is to reject consumer dynamic internet connections without the overhead of a DNS lookup. Connections from these hosts are almost always spambots doing direct-to-MX spamming. I would classify it as low risk of false positives, and fairly safe. (but not 100% safe; few rules are. YMMV and such.) I've had a couple of FP's from idiots that run their business mail servers on a cablemodem with a dynamic rDNS name (their IP is static, but the rDNS incorrectly says dynamic), so I added their IP to a local whitelist. You may or may not run into the same easily-fixed problem. Use it like: smtpd_client_restrictions = permit_mynetworks # uncomment next line if using SASL # permit_sasl_authenticated check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre For testing, you can prepend warn_if_reject like this: warn_if_reject reject_reverse_client... This causes postfix to log a warning: message without actually rejecting the mail. Then examine the log for anything interesting. It can alternately be used in smtpd_recipient_restrictions (or any smtpd_*_restrictions sections), but be sure it's after permit_mynetworks and permit_sasl_authenticated so you don't reject your own authorized users. If you have an old postfix version that doesn't have the check_reverse_client_hostname_access restriction, you'll need to use check_client_access instead. The check_client_access will be a little less effective, but doesn't affect safety. Noel, thank you for the thorough response. Thanks also to all the other responders. I'm definitely convinced. :) And of course, thanks to Stan!
Re: Including state information in Received fields
Murray S. Kucherawy: Hi, I'm co-authoring a draft that would add supplementary information to Received header fields indicating when a message enters some kind of administrative hold. This would be useful to people looking through trace data to figure out why a message sat on a machine for some time, if the reason is something other than a hop that took a long time to complete for connectivity reasons. The draft specification is here: https://datatracker.ietf.org/doc/draft-kucherawy-received-state/ Would postfix be willing to implement something like this? At a minimum, it might be useful to use this to indicate that a milter application requested that a message be quarantined until an operator released it. The opportunities for doing this with Postfix are limited. Postfix writes the Received: header at message arrival time. The decision to add a Received: state field must be made before the 250 OK in response to end-of-data, after the message is frozen (*). Once Postfix sends 250 OK in response to end-of-data, there is no way that a Received: header can be replaced without violating the RFC requirement that mail not be lost due to frivolous causes. Postfix stores the MTA's own Received: header right before the message header and content. The stored header can be replaced via the queue file editing routines that support the Milter protocol. I recall that for Sendmail compatibility reasons, those routines do not allow Milters to manipulate the MTA's own Received: header, but I guess some checks could be moved around so that the edit routine can go to places where Milters cannot. Wietse (*) Recipients are deleted by in-place overwriting a status byte, which is assumed to be an atomic operation.
spam issues
Hi, For a while we ran Qmail. Qmail would accept all emails regardless, creating a very serious backscatter problem. Of course, switching to Postfix with it configured to only accept emails for our recipients fixed this problem. Still we seem to be losing the war with spam. I whitelisted any server that has a .forward set to mine. Any email from a server that is whitelisted gets delivered. This is unacceptable, so I started using procmail with some rules so that email from servers that are whitelisted just get delivered without any filtering. Could someone recommend some low resource way of rejecting more spam. I am considering policyd. I recently setup dovcot to replace uw-imap. It seems to work fine when I am telneting from localhost, but even though it lets me log in from another system, it will not allow me to download the mail. I can't figure out why, does anyone have any ideas? Thanks, Al
Re: Including state information in Received fields
On Thu, Jan 12, 2012 at 12:10 AM, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Wednesday, January 11, 2012 5:46 PM To: Postfix users Subject: Re: Including state information in Received fields But design issues aside, would you consider implementing it at some point? Indications of interest like that would be useful input to the IETF. In my sysadmin career it would have saved me a lot of work figuring out why something was delayed at one particular hop. Log analysis tools might also find it useful, but I haven't tried to sell them on the idea yet. I've found that people don't always want to have this made known. When tracking down why did mail take X hours to reach my friend's inbox issues, it would be quite the embarrassment to have the tracer headers show that my work was being rate limited by ISP X.
RE: Including state information in Received fields
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Peter Blair Sent: Wednesday, January 11, 2012 10:21 PM To: Postfix users Subject: Re: Including state information in Received fields I've found that people don't always want to have this made known. When tracking down why did mail take X hours to reach my friend's inbox issues, it would be quite the embarrassment to have the tracer headers show that my work was being rate limited by ISP X. The MTA being subjected to rate limiting would have to know it's being rate-limited in order to be able to log that in a state clause. If all it's getting is temp-fails, it doesn't know it's in such a state. The intent here is to enable an MTA to log that a message is in a particular state when the local MTA (or an adjacent local component like an MLM) is the one making that decision, not when some downstream MTA (i.e. the next hop) is doing so.
Re: Stan's List [was: free antivirus scanner ?]
On 1/11/2012 3:56 PM, email builder wrote: http://www.hardwarefreak.com/fqrdns.pcre -- Stan's big list Noel, thank you for the thorough response. Thanks also to all the other responders. I'm definitely convinced. :) And of course, thanks to Stan! Of all days for me to be away from the KB most of the day... ;) Others have already hit the high points (thanks guys) so I'll simply try to clarify a few points, confirm some things. It may be maintained and hosted in a hobby manner, but I'd say the file gets as much, if not more, professional use than hobby use. A small sample of hosts that download the file 'regularly'. Yes, the top two are Barracuda Networks, makers of anti-spam appliances. XS4ALL is a large ISP in the Netherlands. Xelerence is a Canadian manufacturer of DNSSEC security appliances, etc. 64.235.144.50: mail.ess.barracuda.com 64.235.150.204: mail.ess.barracuda.com 82.161.212.182: firehole.xs4all.nl 83.163.53.136: puzzled.xs4all.nl 193.110.157.188: mx.xelerance.com 83.139.103.70: dougie.bnet.hr 83.139.103.73: jimbo.bnet.hr 38.126.132.162: gateway.dclab.com 62.77.203.7: z.mx.invitel.net 67.217.170.17: ashburn1.wheelockweb.com 70.167.15.110: mailbox.dop.com 80.150.141.20: mail.ecka-granules.com 88.198.27.178: mx20.monline.it 173.220.103.45: oouser.polylogics.net 129.241.43.189: fender.itea.ntnu.no 147.215.1.189: cache.esiee.fr 147.32.9.2: nms.fjfi.cvut.cz 194.156.172.86: mail96.atlas.de 70.43.81.99: smtp.media-brokers.com 129.187.15.138: lxbsc02.ws.lrz.de 207.10.60.100: hide-inside.nemetschek.net Very little time goes into this. Maintenance simply consists of adding a expression to match a new or previously unknown rDNS string. This typically occurs when an ISP receives a new netblock from its RIR and puts it into service. Rarely, one ISP acquires another and renames their generic rDNS patterns to reflect the new company name. Adding or changing rDNS strings is typically a pretty major infrastructure change. Thus don't simply don't occur very often. It's akin to adding new area codes or prefixes to a telephone system. It primarily targets 'consumer' rDNS patterns, both dynamic and some static. Some static patterns are rejected, some have a prepend for use with SA and the like. Regarding Postscreen integration I don't see that as a win. Postscreen and the fqrdns.pcre table both target bot spam, but in different ways. Postscreen targets bot spam directly, fqrdns.pcre indirectly. Postscreen tends to stop most bot spam on it's own without need of dnsbls or this pcre table. Leaving fqrdns.prce in smtpd should kill any that make it through Postscreen, if any do. For those who don't know regular expressions, the table looks huge because we use fully qualified expressions in most cases, making them very long lines. And each expression has ISP specific optional rejection text, taking up even more space. As Noel mentioned you may get FPs if receiving mail from a host that sits on a residential or small biz line. If that occurs the proper way around it is to whitelist the client IP address, sending domain, or sender address, with an access table. See 'man 5 access'. Let us/me know how it works for you. Easiest way to check its performance is with something like: $ grep -i -c please relay /var/log/[your-mail-log-file] -- Stan
Re: spam issues
Am 12.01.2012 06:15, schrieb Al Zick: Hi, For a while we ran Qmail. Qmail would accept all emails regardless, creating a very serious backscatter problem. Of course, switching to Postfix with it configured to only accept emails for our recipients fixed this problem. Still we seem to be losing the war with spam. I whitelisted any server that has a .forward set to mine. Any email from a server that is whitelisted gets delivered. This is unacceptable, so I started using procmail with some rules so that email from servers that are whitelisted just get delivered without any filtering. Could someone recommend some low resource way of rejecting more spam. I am considering policyd. I recently setup dovcot to replace uw-imap. It seems to work fine when I am telneting from localhost, but even though it lets me log in from another system, it will not allow me to download the mail. I can't figure out why, does anyone have any ideas? Thanks, Al Hi Al, we cannot help you until we dont see your postfix conf logs etc and try to formulate more konkret tec questions also you may cross ask on the dovecot list for dovecot relate questions consider hire somebody to help you ,if you are in a hurry, after all, with the right setup spam should get a to smaller problem in your place -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: spam issues
On 1/11/2012 11:15 PM, Al Zick wrote: Hi, For a while we ran Qmail. Qmail would accept all emails regardless, creating a very serious backscatter problem. Of course, switching to Postfix with it configured to only accept emails for our recipients fixed this problem. Still we seem to be losing the war with spam. I whitelisted any server that has a .forward set to mine. Any email from a server that is whitelisted gets delivered. This is unacceptable, so I started using procmail with some rules so that email from servers that are whitelisted just get delivered without any filtering. Could someone recommend some low resource way of rejecting more spam. I am considering policyd. http://www.postfix.org/docs.html See section UCE/Virus Apparently you missed the discussion Yesterday, Wednesday 12 Jan, of an anti spam tool called fqrdns.pcre. It will stop most bot spam. Postscreen will as well, requires Postfix 2.8+. I recently setup dovcot to replace uw-imap. It seems to work fine when I am telneting from localhost, but even though it lets me log in from another system, it will not allow me to download the mail. I can't figure out why, does anyone have any ideas? You need to inquire on the Dovecot mailing list, this is the Postfix list. -- Stan
