Backscatter email
Hello, I just want to check up on something ... I run my own mail servers, using postfix and a few years ago I use to get quite a lot of backscatter due to spam messages being sent out with forged from addresses. Today I still run my own mail server but I don't see any of this backscatter anymore, not that I'm complaining but I just wondered why? At first I thought it was the network that my server was on doing something funny but I have recently added a new server on a different network and this server doesn't see any backscatter either. Interestingly I still see legit bounce messages when I have got an address wrong or something. Does anybody know what happened? Have servers just been reconfigured to not send backscatter from spam? Cheers, Matt. signature.asc Description: OpenPGP digital signature
Re: Backscatter email
Zitat von Wietse Venema wie...@porcupine.org: Matt Richards: Hello, I just want to check up on something ... I run my own mail servers, using postfix and a few years ago I use to get quite a lot of backscatter due to spam messages being sent out with forged from addresses. Today I still run my own mail server but I don't see any of this backscatter anymore, not that I'm complaining but I just wondered why? At first I thought it was the network that my server was on doing something funny but I have recently added a new server on a different network and this server doesn't see any backscatter either. Interestingly I still see legit bounce messages when I have got an address wrong or something. Does anybody know what happened? Have servers just been reconfigured to not send backscatter from spam? On my little domain, I see less backscatter. Wietse Backscatter is far less common than years before because most of the spam today is spewed out by queue-less bots and not open relays with real MTAs as it was some time ago. The receiving end does recipient verification most of the time, so at that end bounces are not created either. With this, the amount of backscatter is declining more and more IMHO. Regards Andreas
Charset error
ÿóÿýIÿóÿýE-Version: 1.0 NAÿóÿýE OPEN_ÿóÿýODE - -- The mail start from a AIX server and send to relay with telnet on the smtp port. But the mail arrive with wrong character. The problem is of the script or of the postfix server? Thanks, Jacopo -- Linux, Windows Xp ed MS-DOS (anche conosciuti come il Bello, il Brutto ed il Cattivo). -- Matt Welsh
Re: Backscatter email
On Fri, Oct 30, 2009 at 08:51:08AM +, Matt Richards wrote: Does anybody know what happened? Have servers just been reconfigured to not send backscatter from spam? Here in the YMMV department ... My little server hosts a few small Free Software community projects, one of which is a small (mostly inactive) local Linux user group. The subdomain that receives mail is list.example.org. ... the parent is used for Web service only. But, the MX for the parent exists and is pointed at my little server. Roughly 90% of all connections I get are backscatter for this one little domain. 554 5.7.1 ... Relay access denied. And yet they keep coming back again and again. When I did some quick statistical analysis, however, I saw that many of these were repeat abusers. So it's a relatively small number overall, that I am seeing. And note, I have no way to distinguish backscatter abuse from SAV abuse. I bet if this was running on a home ADSL or cable connection, it would cause a DoS. As it is at a good colocation provider, I only have to deal with big log files. I can't say that my experiences invalidate your observations, but for sure, the problem has not gone away. Fortunately, people who consider accept-then-bounce a valid way to handle email are now a small and thoroughly discredited minority. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Charset error
Jacopo Cappelli: IE-Version: 1.0 NAE OPEN_ODE - -- What is that? The mail start from a AIX server and send to relay with telnet on the smtp port. But the mail arrive with wrong character. The problem is of the script or of the postfix server? According to specified in RFC 2046 section 4.1.2: A critical parameter that may be specified in the Content-Type field for text/plain data is the character set. This is specified with a charset parameter, as in: Content-type: text/plain; charset=iso-8859-1 Unlike some other parameter values, the values of the charset parameter are NOT case sensitive. The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII. Wietse
Re: Reverse DNS Rejection Problem
Thanks. I owe you one. That seems to have fixed it. On Oct 29, 2009, at 2:41 PM, Victor Duchovni wrote: On Thu, Oct 29, 2009 at 02:35:56PM -0400, Dennis Putnam wrote: That is a relief when I get to the new version. In the mean time I am still having trouble with the workaround. My config now says: smtpd_helo_restrictions = check_client_access cidr:/etc/postfix/heloaccept.cidr That got rid of the dictionary error however it does not work as I expected. Perhaps I am misunderstanding what this is doing. The last entry in heloaccept.cdir is: 0.0.0.0/0 REJECT The behavior seems to be that anything not listed in the cdir file is getting rejected (actually it says 'access denied'). The behavior I am looking is the same as reject_unknown_client unless the IP or network is listed in the cdir file with OK before the above entry. What do I have wrong? Change that to: 0.0.0.0/0 reject_unknown_client -- 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. Dennis Putnam Sr. IT Systems Administrator AIM Systems, Inc. 11675 Rainwater Dr., Suite 200 Alpharetta, GA 30009 Phone: 678-240-4112 Main Phone: 678-297-0700 FAX: 678-297-2666 or 770-576-1000 The information contained in this e-mail and any attachments is strictly confidential. If you are not the intended recipient, any use, dissemination, distribution, or duplication of any part of this e-mail or any attachment is prohibited. If you are not the intended recipient, please notify the sender by return e-mail and delete all copies, including the attachments.
smtpd_recipient_restrictions evaluation question
Hello folks, I've got some checks setup like that : smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access pcre:/etc/postfix/helo_checks.pcre, check_sender_access hash:/etc/postfix/white_senders, check_client_access hash:/etc/postfix/white_clients, check_recipient_access hash:/etc/postfix/white_recipients, reject_rbl_client sbl-xbl.spamhaus.org, reject_rhsbl_sender dsn.rfc-ignorant.org, check_policy_service inet:10.18.0.100:6, I notice that event if the recipient address doesn't exists, the check_policy_service (greylist) got evaluated, causing higher load than needed. Isn't reject_unauth_destination there to block inexistent recipients ? Thanks in advance ! -- Simon.
Re: smtpd_recipient_restrictions evaluation question
Simon Morvan: I notice that event if the recipient address doesn't exists, the check_policy_service (greylist) got evaluated, causing higher load than needed. Isn't reject_unauth_destination there to block inexistent recipients ? No, that's what reject_unlisted_recipient is for. -- Regards mks
Re: smtpd_recipient_restrictions evaluation question
On Friday 30 October 2009 09:52:44 Simon Morvan wrote: Hello folks, I've got some checks setup like that : smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access pcre:/etc/postfix/helo_checks.pcre, check_sender_access hash:/etc/postfix/white_senders, check_client_access hash:/etc/postfix/white_clients, check_recipient_access hash:/etc/postfix/white_recipients, reject_rbl_client sbl-xbl.spamhaus.org, Consider Zen here. It also incorporates the (not-quite-so) new PBL, which has been very effective here. reject_rhsbl_sender dsn.rfc-ignorant.org, check_policy_service inet:10.18.0.100:6, I notice that event if the recipient address doesn't exists, the check_policy_service (greylist) got evaluated, causing higher load than needed. Isn't reject_unauth_destination there to block inexistent recipients ? If the load of a policy service is a problem for you, you should consider increasing your resources, i.e., throw more money at it. :) That notwithstanding, I know that's not your real question, which appears to be confusion of reject_unauth_destination with reject_unlisted_recipient; see: http://www.postfix.org/postconf.5.html#reject_unlisted_recipient -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Postfix-SASL-GSSAPI question
Viktor, Hi Thanks for your guidance. Would please keep an eye on this thread? I am going to test the configuration using a properly configured GSSAPI client. Possibly, there will be much more questions to ask ;) Thank you so much. Kind Regards Ali Majdzadeh Kohbanani 2009/10/29 Victor Duchovni victor.ducho...@morganstanley.com On Thu, Oct 29, 2009 at 07:11:54PM +0330, Ali Majdzadeh wrote: Thanks for your mail. Among your experiences with Postfix, GSSAPI and probably SASL, have you ever tested your configuration using telnet? If it is so, would you please describe the procedure? According to your previous mail, I figured out that since I use telnet to test the configuration, I should know about the exact handshake process. The GSSAPI handshake is too complex for hand-tests with telnet. Use a real GSSAPI client, e.g. a suitably configured Postfix client. -- 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.
Postfix and clamav-milter stopped working after update to clamav-0.95.3
System: FreeBSD-7.2 I just updated to clamav-0.95.3 on my system. I then realized that clamav-milter and Postfix were no longer connecting. /usr/local/etc/postfix/main.cf # Enable clamav-milter milter_default_action = accept smtpd_milters = unix:/var/run/clamav/clmilter.sock /var/run/clamav/clmilter.sock srwxr-xr-x 1 clamav wheel 0B Oct 30 10:22 clmilter.sock= /var/log/maillog Oct 30 10:23:26 scorpio postfix/smtpd[1339]: warning: connect to Milter service unix:/var/run/clamav/clmilter.sock: Permission denied /tmp/clamav-milter.log Fri Oct 30 10:22:16 2009 - +++ Started at Fri Oct 30 10:22:16 2009 I tried doing a complete reboot of the system; however, the problem continues. I have confirmed that the milter is running. Everything was working perfectly under version 0.95.2 of clamav. I made absolutely no other changes. -- -- Jerry postfix.u...@yahoo.com TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html After years of research, scientists recently reported that there is, indeed, arroz in Spanish Harlem.
Re: Postfix and clamav-milter stopped working after update to clamav-0.95.3
Jerry a écrit : System: FreeBSD-7.2 I just updated to clamav-0.95.3 on my system. I then realized that clamav-milter and Postfix were no longer connecting. /usr/local/etc/postfix/main.cf # Enable clamav-milter milter_default_action = accept smtpd_milters = unix:/var/run/clamav/clmilter.sock /var/run/clamav/clmilter.sock srwxr-xr-x 1 clamav wheel 0B Oct 30 10:22 clmilter.sock= /var/log/maillog Oct 30 10:23:26 scorpio postfix/smtpd[1339]: warning: connect to Milter service unix:/var/run/clamav/clmilter.sock: Permission denied /tmp/clamav-milter.log Fri Oct 30 10:22:16 2009 - +++ Started at Fri Oct 30 10:22:16 2009 I tried doing a complete reboot of the system; however, the problem continues. I have confirmed that the milter is running. Everything was working perfectly under version 0.95.2 of clamav. I made absolutely no other changes. For me restarting clamav-milter did the trick. Check your milter setting, the permissions on the socket must be changed by the starting script for use with postfix. The port does this well provided it is configured to do so. -- Erwan David
Re: smtpd_recipient_restrictions evaluation question
Le 30/10/2009 16:05, /dev/rob0 a écrit : On Friday 30 October 2009 09:52:44 Simon Morvan wrote: Hello folks, I've got some checks setup like that : smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access pcre:/etc/postfix/helo_checks.pcre, check_sender_access hash:/etc/postfix/white_senders, check_client_access hash:/etc/postfix/white_clients, check_recipient_access hash:/etc/postfix/white_recipients, reject_rbl_client sbl-xbl.spamhaus.org, Consider Zen here. It also incorporates the (not-quite-so) new PBL, which has been very effective here. The last time I tried it, Zen included too many legitimate users behind ADSL lines. The Policy behind PBL is a bit too restrictive. Maybe it changed, I'll give it another try. reject_rhsbl_sender dsn.rfc-ignorant.org, check_policy_service inet:10.18.0.100:6, I notice that event if the recipient address doesn't exists, the check_policy_service (greylist) got evaluated, causing higher load than needed. Isn't reject_unauth_destination there to block inexistent recipients ? If the load of a policy service is a problem for you, you should consider increasing your resources, i.e., throw more money at it. :) That notwithstanding, I know that's not your real question, which appears to be confusion of reject_unauth_destination with reject_unlisted_recipient; see: http://www.postfix.org/postconf.5.html#reject_unlisted_recipient Thanks to all repliers abount reject_unlisted_recipient, i'll try to search the F** manual a bit deeper the next time :). Btw, I was telling load for human load :). There is no point of greylisting mail for unexistant recipients. It increase the greylist pending database and make it harder for me to find the legitimate servers I should whitelist. -- Simon.
Re: Postfix and clamav-milter stopped working after update to clamav-0.95.3
On Fri, 30 Oct 2009 16:26:10 +0100 Erwan David er...@rail.eu.org replied: Jerry a écrit : System: FreeBSD-7.2 I just updated to clamav-0.95.3 on my system. I then realized that clamav-milter and Postfix were no longer connecting. /usr/local/etc/postfix/main.cf # Enable clamav-milter milter_default_action = accept smtpd_milters = unix:/var/run/clamav/clmilter.sock /var/run/clamav/clmilter.sock srwxr-xr-x 1 clamav wheel 0B Oct 30 10:22 clmilter.sock= /var/log/maillog Oct 30 10:23:26 scorpio postfix/smtpd[1339]: warning: connect to Milter service unix:/var/run/clamav/clmilter.sock: Permission denied /tmp/clamav-milter.log Fri Oct 30 10:22:16 2009 - +++ Started at Fri Oct 30 10:22:16 2009 I tried doing a complete reboot of the system; however, the problem continues. I have confirmed that the milter is running. Everything was working perfectly under version 0.95.2 of clamav. I made absolutely no other changes. For me restarting clamav-milter did the trick. Check your milter setting, the permissions on the socket must be changed by the starting script for use with postfix. The port does this well provided it is configured to do so. OK, but what permissions does it need? I have posted what it currently is in my original post. -- Jerry postfix.u...@yahoo.com TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Love is like the measles; we all have to go through it. Jerome K. Jerome
Re: Postfix and clamav-milter stopped working after update to clamav-0.95.3
Jerry wrote: On Fri, 30 Oct 2009 16:26:10 +0100 Erwan David er...@rail.eu.org replied: Jerry a écrit : System: FreeBSD-7.2 I just updated to clamav-0.95.3 on my system. I then realized that clamav-milter and Postfix were no longer connecting. /usr/local/etc/postfix/main.cf # Enable clamav-milter milter_default_action = accept smtpd_milters = unix:/var/run/clamav/clmilter.sock /var/run/clamav/clmilter.sock srwxr-xr-x 1 clamav wheel 0B Oct 30 10:22 clmilter.sock= /var/log/maillog Oct 30 10:23:26 scorpio postfix/smtpd[1339]: warning: connect to Milter service unix:/var/run/clamav/clmilter.sock: Permission denied /tmp/clamav-milter.log Fri Oct 30 10:22:16 2009 - +++ Started at Fri Oct 30 10:22:16 2009 I tried doing a complete reboot of the system; however, the problem continues. I have confirmed that the milter is running. Everything was working perfectly under version 0.95.2 of clamav. I made absolutely no other changes. For me restarting clamav-milter did the trick. Check your milter setting, the permissions on the socket must be changed by the starting script for use with postfix. The port does this well provided it is configured to do so. OK, but what permissions does it need? I have posted what it currently is in my original post. Mine is srwxr-xr-x 1 postfix clamav - 0 Oct 30 15:15 /var/run/clamav/clmilter.sock In the port this is controlled by clamav_milter_socket_user=postfix -- Erwan
Re: Postfix and clamav-milter stopped working after update to clamav-0.95.3
On Fri, 30 Oct 2009 17:12:40 +0100 Erwan David er...@rail.eu.org replied: [snip] Mine is srwxr-xr-x 1 postfix clamav - 0 Oct 30 15:15 /var/run/clamav/clmilter.sock In the port this is controlled by clamav_milter_socket_user=postfix I changed the permissions on mine to: 0777. I figured it was easier than finding that something else had stopped working. -- Jerry postfix.u...@yahoo.com TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Leibowitz's Rule: When hammering a nail, you will never hit your finger if you hold the hammer with both hands.
Re: SMTP-AUTH *without* SASL/PAM?
Barney Desmond wrote: 2009/10/30 Seth Mattinen se...@rollernet.us: Keith Palmer wrote: OK, thanks... but that doesn't answer my question. Is it possible to configure Postfix for SMTP-AUTH *without* using SASL/PAM? I'd like to *not run SASL at all* rather than have it do the lookups. Use the dovecot auth method. In spite of the name in the docs, no SASL is involved whatsoever. I run dovecot on a few servers with all the pop3/imap parts disabled just for auth. Uh, it *is* still SASL, unless I've misunderstood that. To clarify: there is no way to avoid using SASL. SASL is the protocol that Postfix uses to ask Someone Else for authentication. Postfix supports no other authentication mechanisms. (the fact that the only SASL backends in existence (basically) are POP/IMAP servers is what usually confuses people). If you have no particular requirements or existing configuration, installing Dovecot and using it as your SASL backend is the easiest way to go. Well sure, but my point was that Dovecot auth doesn't have the normal hassle of cyrus sasl so one shouldn't think of it as the same potential evil. ~Seth
Please evaluate my understanding wrt access files
I would like to confirm my understanding about access files.
Please let me know if any of this is not correct...
The man (5) access description describes a prototype file, where that
file could be a single file describing any host names, network
addresses, envelope senders or recipient addresses.
The file could also be a set of files all following the same format
rules.
Where such files might be
recipient_checks, helo_checks, sender_checks, client_checks, etc.
The usefulness of the content of an access file is dependent upon the
parameter that selects a routine that reads the file.
If check_client_access causes a read of the file it will only be
looking for IP addresses of a client server that sent the email or a
fully qualified domain name that successfully reverse maps to the IP
address of a client server that sent the email.
If check_sender_access causes a read of the file it will only be
looking for an email SMTP MAIL FROM address or a pattern which could
be a part that email address to the left of the @ sign.
If check_helo_access causes a read of the file it will only be looking
for the HELO or EHLO hostname or any valid parent domain of that
hostname that is in the SMTP HELO.
The routines executed vi the parameters such as check_client_access,
check_sender_access, check_helo_access, etc. return the value the
check to the routine that called for the check where the calling
routine would be instigated by any of these parameters:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictions
It is possible to have all the lookups done on a single
.../postfix/access.db file but that could mean the file gets confusing
so in practice multiple access files with names like client_access,
helo_access, sender_access, etc.
A single parameter such as check_client_access may be called multiple
times in a situation like this:
smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/greylist
check_sender_access hash:/etc/postfix/sender_access
permit_mynetworks
However if the above causes a pattern to be found more than once then
only the last pattern match is used. (I think that is what When the
same parameter is defined multiple times, only the last instance is
remembered. means.)
This is how I am putting this in practice on a new virtual server
where I hope to fix some problems on current production servers:
r...@mg0x:/etc/postfix# postconf -d mail_version
mail_version = 2.5.5
I am using 2.5.5 because that is the latest from Ubuntu.
r...@mg0x:/etc/postfix# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = yes
biff = no
bounce_size_limit = 1
config_directory = /etc/postfix
default_process_limit = 400
header_checks = regexp:/etc/postfix/header_checks
inet_interfaces = all
mailbox_size_limit = 0
masquerade_domains = $mydomain, cnm.edu, nmvc.org, nmvirtualcollege.org
max_use = 100
message_size_limit = 16777216
mydestination = $myhostname, $mydomain, localhost.localdomain,
cnm.edu, mail.cnm.edu, mg0x.cnm.edu, mg04.cnm.edu, mg05.cnm.edu,
nmvc.org, mail.nmvc.org, mg0x.nmvc.org, mg04.nmvc.org, mg05.nmvc.org,
mg06.nmvc, nmvirtualcollege.org, mail.nmvirtualcollege.org,
mg0x.nmvirtualcollege.org, mg04.nmvirtualcollege.org,
mg05.nmvirtualcollege.org, mg04.nmvirtualcollege.org, nmln.net,
ideal-nm.org, ideal-nm.net, idealnm.org, idealnm.net
myhostname = mg0x.cnm.edu
mynetworks = 198.133.182.0/24, 198.133.181.0/24, 198.133.180.0/24,
172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8, 127.0.0.0/8
[:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
notify_classes = resource, software
readme_directory = no
recipient_delimiter = +
relay_domains = $mydestination
relayhost =
smtp_host_lookup = dns, native
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = cnm.edu
smtpd_client_restrictions = permit_mynetworks check_client_access
hash:/etc/postfix/accessreject_rbl_client
zen.spamhaus.orgreject_rbl_client bl.spamcop.net
reject_rbl_client
dnsbl.njabl.org permit
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_hostname
smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/overquota reject_non_fqdn_sender
reject_unknown_sender_domainreject_non_fqdn_recipient
reject_unknown_recipient_domain reject_unlisted_recipient
permit_mynetworks reject_unauth_destination
reject_unauth_pipeliningreject_invalid_helo_hostname
reject_non_fqdn_helo_hostname reject_rbl_client zen.spamhaus.org
smtpd_sender_restrictions = check_sender_access
hash:/etc/postfix/greylist check_sender_access
hash:/etc/postfix/sender_access permit_mynetworks
reject_unknown_sender_domain
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd compile problem (tls)
Hi, If I compile with TLS Support I get following errror, ssl.h is in /usr/local/openssl and libsslo/libcyrpto.o are in /usr/lib. compile options are: SYSTYPE = LINUX2 AR = ar ARFL= rv RANLIB = ranlib SYSLIBS = -lldap -llber -lpcre -lsasl2 -lssl -lcrypto -ldb -lnsl -lresolv -ldb -lnsl -lresolv CC = gcc $(WARN) -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl OPT = -O DEBUG = -g AWK = awk STRCASE = EXPORT = AUXLIBS='-lldap -llber -lpcre -lsasl2 -lssl -lcrypto -ldb -lnsl -lresolv' CCARGS='-DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl' OPT='-O' DEBUG='-g' WARN= -Wall -Wno-comment -Wformat -Wimplicit -Wmissing-prototypes \ -Wparentheses -Wstrict-prototypes -Wswitch -Wuninitialized \ -Wunused -Wno-missing-braces versions: postfix 2.6.5 openssl 0.9.8k [...] [src/smtpd] gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_token.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_check.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_chat.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_state.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_peer.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_sasl_proto.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_sasl_glue.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_proxy.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_xforward.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_dsn_fix.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_milter.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -c smtpd_resolve.c gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl -g -O -I. -I../../include -DLINUX2 -o smtpd smtpd.o smtpd_token.o smtpd_check.o smtpd_chat.o smtpd_state.o smtpd_peer.o smtpd_sasl_proto.o smtpd_sasl_glue.o smtpd_proxy.o smtpd_xforward.o smtpd_dsn_fix.o smtpd_milter.o smtpd_resolve.o ../../lib/libmaster.a ../../lib/libtls.a ../../lib/libdns.a ../../lib/libxsasl.a ../../lib/libmilter.a ../../lib/libglobal.a ../../lib/libutil.a -lldap -llber -lpcre -lsasl2 -lssl -lcrypto -ldb -lnsl -lresolv -ldb -lnsl -lresolv ../../lib/libtls.a(tls_server.o): In function `tls_server_start': /home/xa/packages/postfix/postfix/src/tls/tls_server.c:647: undefined reference to `BIO_set_callback' /home/xa/packages/postfix/postfix/src/tls/tls_server.c:666: undefined reference to `BIO_set_callback' ../../lib/libtls.a(tls_server.o): In function `tls_server_init': /home/xa/packages/postfix/postfix/src/tls/tls_server.c:318: undefined reference to `EVP_MD_size' /home/xa/packages/postfix/postfix/src/tls/tls_server.c:376: undefined reference to `SSL_CTX_set_info_callback' /home/xa/packages/postfix/postfix/src/tls/tls_server.c:525: undefined reference to `SSL_CTX_sess_set_get_cb' /home/xa/packages/postfix/postfix/src/tls/tls_server.c:526: undefined reference to `SSL_CTX_sess_set_new_cb' collect2: ld returned 1 exit status make: *** [smtpd] Error 1 make: *** [update] Error 1 I'm at the
Re: smtpd compile problem (tls)
On Fri, Oct 30, 2009 at 07:15:11PM +0100, Carnac wrote: If I compile with TLS Support I get following errror, ssl.h is in /usr/local/openssl and libsslo/libcyrpto.o are in /usr/lib. That's libcrypto.a, not libcyrto.o of course. And if you find headers in /usr/local/openssl but libraries in /usr/lib, something is dreadfully wrong, these are very unlikely to be from the same sofware. Perhaps you have GnuTLS, rather than OpenSSL in /usr/include and /usr/lib? In any case, either use /usr/include/openssl/ and /usr/lib or /usr/local/openssl/include/ and /usr/local/openssl/lib/. Don't mix and match. EXPORT = AUXLIBS='-lldap -llber -lpcre -lsasl2 -lssl -lcrypto -ldb -lnsl -lresolv' CCARGS='-DHAS_LDAP -DHAS_PCRE -DUSE_CYRUS_SASL -DUSE_SASL_AUTH -DUSE_TLS -I/usr/include/sasl -I/usr/include/openssl' OPT='-O' DEBUG='-g' Either: - add -L/usr/local/openssl/lib near the front of AUXLIBS OR - Use the system ssl headers, provided of course these are openssl and not GnuTLS. -- 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: smtpd_recipient_restrictions evaluation question
Simon Morvan wrote: Consider Zen here. It also incorporates the (not-quite-so) new PBL, which has been very effective here. The last time I tried it, Zen included too many legitimate users behind ADSL lines. The Policy behind PBL is a bit too restrictive. Maybe it changed, I'll give it another try. Can you please tell me why an ADSL user would send legitimate email without using the ISP's SMTP server? More and more ISP even blocks outbound access to port 25, which may not be popular, but it's very effective in stoping spam at its source. Mikael
smtpd_recipient_restrictions evaluation question
Markus Schönhaber put forth on 10/30/2009 10:05 AM: Simon Morvan: I notice that event if the recipient address doesn't exists, the check_policy_service (greylist) got evaluated, causing higher load than needed. Isn't reject_unauth_destination there to block inexistent recipients ? No, that's what reject_unlisted_recipient is for. I only have reject_unauth_destination on my relay-only server, and sending to an invalid recipient address returns: 550 5.1.1 inva...@domain.tld: Recipient address rejected: User unknown in relay recipient table I don't have reject_unauth_destination. I guess which parameter one needs to implement depends on whether one uses local deliver? -- Stan
smtpd_recipient_restrictions evaluation question
Stan Hoeppner put forth on 10/30/2009 2:23 PM: I don't have reject_unauth_destination. I guess which parameter one needs to implement depends on whether one uses local deliver? Should have proofread that... I meant I do not have reject_unlisted_recipient defined. However, the docs say it's turned on by default, which would explain why my rejections work properly. http://www.postfix.org/postconf.5.html#reject_unlisted_recipient smtpd_reject_unlisted_recipient (default: yes) Request that the Postfix SMTP server rejects mail for unknown recipient addresses, even when no explicit reject_unlisted_recipient access restriction is specified. This prevents the Postfix queue from filling up with undeliverable MAILER-DAEMON messages. -- Stan
Re: smtpd_recipient_restrictions evaluation question
Stan Hoeppner: I only have reject_unauth_destination on my relay-only server, and sending to an invalid recipient address returns: 550 5.1.1 inva...@domain.tld: Recipient address rejected: User unknown in relay recipient table I don't have reject_unauth_destination. I guess which parameter one needs to implement depends on whether one uses local deliver? You probably have smtpd_reject_unlisted_recipient at it's default value: yes. -- Regards mks
Re: smtpd_recipient_restrictions evaluation question
On 10/30/2009 2:28 PM, Stan Hoeppner wrote: Stan Hoeppner put forth on 10/30/2009 2:23 PM: I don't have reject_unauth_destination. I guess which parameter one needs to implement depends on whether one uses local deliver? Should have proofread that... I meant I do not have reject_unlisted_recipient defined. However, the docs say it's turned on by default, which would explain why my rejections work properly. http://www.postfix.org/postconf.5.html#reject_unlisted_recipient smtpd_reject_unlisted_recipient (default: yes) Request that the Postfix SMTP server rejects mail for unknown recipient addresses, even when no explicit reject_unlisted_recipient access restriction is specified. This prevents the Postfix queue from filling up with undeliverable MAILER-DAEMON messages. -- Stan You can use reject_unlisted_recipient in your smtpd_*_restrictions to ask postfix to reject unknown recipients earlier in the process, eg. before RBL or greylist checks. The default smtpd_reject_unlisted_recipient basically tacks reject_unlisted_recipient at the very end of smtpd_recipient_restrictions. -- Noel Jones
smtpd_recipient_restrictions evaluation question
Simon Morvan put forth on 10/30/2009 10:39 AM: The last time I tried it, Zen included too many legitimate users behind ADSL lines. The Policy behind PBL is a bit too restrictive. Maybe it changed, I'll give it another try. Would you please elaborate a bit on this? Most of the listings in PBL are created by the ISPs who own the IP address space listed in PBL. THEY are the ones saying mail should not originate from this IP (or IP block). Spamhaus creates some PBL entries when lazy bot infested ISPs fail to do so. In lieu of the Spamhaus created entries, anyone else sending mail from a PBL listed IP is violating their ISP's TOS by doing so. I hope you're not an ISP and are checking your users' mail submission against dnsbls. This is a recipe for disaster, and may explain why you're having problems when using Zen. Never check your own users' mail against dnsbls. Zen is the most widely used dnsbl on the planet, considered by most to be the safest dnsbl, and very very few people ever report false positives with Zen. Something seems amiss in your situation. -- Stan
Re: smtpd_recipient_restrictions evaluation question
On Fri, 30 Oct 2009, Mikael Bak wrote: Simon Morvan wrote: The last time I tried it, Zen included too many legitimate users behind ADSL lines. The Policy behind PBL is a bit too restrictive. Maybe it changed, I'll give it another try. Can you please tell me why an ADSL user would send legitimate email without using the ISP's SMTP server? At ths risk of this moving too far away from Postfix, let me just ask if you're thinking ADSL means dynamic IP address? There are many legitimate mail servers on static IP ADSL lines (including mine) provided by ISPs with servers permitted policies. Typically these are business-class services but not always (my ISP does not distinguish between residential and business but their services are not priced for the mass-market residential user). Why handle the outgoing mail myself? Better control. If there's a problem, it sits on my system where I can see it and deal with it, not on my ISP's server where it's invisible to me. -- Larry Stone lston...@stonejongleux.com
Re: smtpd_recipient_restrictions evaluation question
Larry Stone wrote: On Fri, 30 Oct 2009, Mikael Bak wrote: Simon Morvan wrote: The last time I tried it, Zen included too many legitimate users behind ADSL lines. The Policy behind PBL is a bit too restrictive. Maybe it changed, I'll give it another try. Can you please tell me why an ADSL user would send legitimate email without using the ISP's SMTP server? At ths risk of this moving too far away from Postfix, let me just ask if you're thinking ADSL means dynamic IP address? There are many legitimate mail servers on static IP ADSL lines (including mine) provided by ISPs with servers permitted policies. Typically these are business-class services but not always (my ISP does not distinguish between residential and business but their services are not priced for the mass-market residential user). Why handle the outgoing mail myself? Better control. If there's a problem, it sits on my system where I can see it and deal with it, not on my ISP's server where it's invisible to me. You are of course right. I ment home ADSL, not static IP business ADSL. And yes. We're moving away from postfix :-) Mikael
Re: Please evaluate my understanding wrt access files
On Fri, Oct 30, 2009 at 1:26 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 10/30/2009 12:55 PM, Robert Lopez wrote: I would like to confirm my understanding about access files. Please let me know if any of this is not correct... The man (5) access description describes a prototype file, where that file could be a single file describing any host names, network addresses, envelope senders or recipient addresses. The file could also be a set of files all following the same format rules. Where such files might be recipient_checks, helo_checks, sender_checks, client_checks, etc. The usefulness of the content of an access file is dependent upon the parameter that selects a routine that reads the file. If check_client_access causes a read of the file it will only be looking for IP addresses of a client server that sent the email or a fully qualified domain name that successfully reverse maps to the IP address of a client server that sent the email. If check_sender_access causes a read of the file it will only be looking for an email SMTP MAIL FROM address or a pattern which could be a part that email address to the left of the @ sign. If check_helo_access causes a read of the file it will only be looking for the HELO or EHLO hostname or any valid parent domain of that hostname that is in the SMTP HELO. The routines executed vi the parameters such as check_client_access, check_sender_access, check_helo_access, etc. return the value the check to the routine that called for the check where the calling routine would be instigated by any of these parameters: smtpd_client_restrictions smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_data_restrictions It is possible to have all the lookups done on a single .../postfix/access.db file but that could mean the file gets confusing so in practice multiple access files with names like client_access, helo_access, sender_access, etc. so far so good... A single parameter such as check_client_access may be called multiple times in a situation like this: smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/greylist check_sender_access hash:/etc/postfix/sender_access permit_mynetworks However if the above causes a pattern to be found more than once then only the last pattern match is used. (I think that is what When the same parameter is defined multiple times, only the last instance is remembered. means.) No, the last parameter is used rule refers to when indexing a single map -- when the map is indexed with postmap, a duplicate key will overwrite the previous identical key. With multiple maps -- or multiple restrictions of any type -- in smtpd_*_restrictions, the first match wins. Ah! Good. That now makes more sense. Postfix places no limit on how many maps you can use, but there is system overhead with each map. Rule of thumb is to combine maps wherever possible -- don't use two check_sender_access statements if you can do it with one. The smart way to do this is use a Makefile to build a single map from multiple similar input files. That is interesting. What is the advantage of that over directly editing a single file? I can see having unique names that pair with the parameters that cause them to be read. It is not clear to me what the benefit of multiple files is beyond this association. We do something similar with the virtualaliases table. There is a table that has all college employees who use an Exchange server, another that has all customers (students) who use Sungard Luminis, and a third that has Mailman lists. So email is delivered to one of those three systems based on that file. We build that single file from three separate files. This is how I am putting this in practice on a new virtual server where I hope to fix some problems on current production servers: r...@mg0x:/etc/postfix# postconf -d mail_version mail_version = 2.5.5 I am using 2.5.5 because that is the latest from Ubuntu. r...@mg0x:/etc/postfix# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = yes biff = no bounce_size_limit = 1 config_directory = /etc/postfix default_process_limit = 400 header_checks = regexp:/etc/postfix/header_checks inet_interfaces = all mailbox_size_limit = 0 masquerade_domains = $mydomain, cnm.edu, nmvc.org, nmvirtualcollege.org max_use = 100 message_size_limit = 16777216 mydestination = $myhostname, $mydomain, localhost.localdomain, cnm.edu, mail.cnm.edu, mg0x.cnm.edu, mg04.cnm.edu, mg05.cnm.edu, nmvc.org, mail.nmvc.org, mg0x.nmvc.org, mg04.nmvc.org, mg05.nmvc.org, mg06.nmvc, nmvirtualcollege.org, mail.nmvirtualcollege.org, mg0x.nmvirtualcollege.org, mg04.nmvirtualcollege.org, mg05.nmvirtualcollege.org, mg04.nmvirtualcollege.org, nmln.net, ideal-nm.org, ideal-nm.net, idealnm.org, idealnm.net Lots of domains in mydestination... Are you sure
Re: Backscatter email
Matt Richards さんは書きました: Hello, I just want to check up on something ... I run my own mail servers, using postfix and a few years ago I use to get quite a lot of backscatter due to spam messages being sent out with forged from addresses. Today I still run my own mail server but I don't see any of this backscatter anymore, not that I'm complaining but I just wondered why? Interesting that you are seeing bounce messages. Unless they are from your own server. I haven't seen any in the very recent past. I think the last one I received was in June, from a qmail server. The last round of backscatter was from servers bouncing variations of my addresses altered for the target domains and virtually all were qmail servers. Perhaps qmail defaults to accept all mail then bounce have changed lately and getting listed on rfc-ignorant, etc., has got the mail admins' attention. I would suppose it sucks a little when outgoing mail can't be delivered because of being a backscatterer. Spammers are still trying to send mail to variations of whatever they use as a From: address but they are being blocked. -- jd
Please evaluate my understanding wrt access files
Robert Lopez put forth on 10/30/2009 6:57 PM: It is not clear to me what the benefit of multiple files is beyond this association. Organization and ease of management for one. For example: smtpd_client_restrictions = check_recipient_access hash:/etc/postfix/access check_client_access hash:/etc/postfix/access pcre:/etc/postfix/check_client_fqdn.pcre hash:/etc/postfix/coolsavings.access hash:/etc/postfix/richk-1.access cidr:/etc/postfix/cidr_files/china.cidr cidr:/etc/postfix/cidr_files/korea.cidr cidr:/etc/postfix/cidr_files/russia.cidr cidr:/etc/postfix/cidr_files/ukraine.cidr cidr:/etc/postfix/cidr_files/malaysia.cidr cidr:/etc/postfix/cidr_files/belarus.cidr cidr:/etc/postfix/cidr_files/indonesia.cidr cidr:/etc/postfix/cidr_files/hongkong.cidr cidr:/etc/postfix/cidr_files/africa.cidr cidr:/etc/postfix/cidr_files/romania.cidr cidr:/etc/postfix/cidr_files/thailand.cidr cidr:/etc/postfix/cidr_files/poland.cidr cidr:/etc/postfix/cidr_files/spammer.cidr cidr:/etc/postfix/cidr_files/hurricane-electric.cidr cidr:/etc/postfix/cidr_files/richk-1.cidr pcre:/etc/postfix/access.pcre My access file contains some whitelist email addresses, some whitelist domains, some blacklist domains, and some whitelist and blacklist IP addresses, so I do have some consolidation in the one file and I use it in multiple restriction classes. However, it's by far my smallest table file. Some of my cidr files are pretty large. Note that I'm using the IPdeny (http://www.ipdeny.com) data and rejecting entire countries' smtp connections. Some of those files have thousands of entries. Note also that I'm using multiple table types, hash, cidr, and pcre. It's better to use multiple files in this kind of setup. This may be another point where I am confused. I am thinking relay is when a postfix server accepts email for u...@cnm.edu and then rewrites that address to what is found in a table for the user where the email is then sent to u...@other.domain. I may have to read that a few times to get it all straight. No, relay strictly means Postfix is not the final destination for a given domain, thus Postfix relays the email to the appropriate server, or rejects the email if Postfix is not configured to relay for a given domain. See: http://www.postfix.org/postconf.5.html#relay_domains Is that cnm.edu ESMTP or default? It's a simple banner message displayed to a remote host when it connects to deliver mail to your MX. You don't need to define it. Postfix does it for you. Just delete that line from main.cf. Humans never see it anyway, unless they telnet to your port TCP 25 for testing or something. Here's an example of the Postfix default banner (mine): 220 greer.hardwarefreak.com ESMTP Postfix Here's the banner on Wietse's server. Wietse is the creator of Postfix. 220 spike.porcupine.org ESMTP Postfix (2.7-20091023) IMHO, there's really no good reason to change the default banner. -- Stan
Re: Please evaluate my understanding wrt access files
On 10/30/2009 9:05 PM, Stan Hoeppner wrote: Robert Lopez put forth on 10/30/2009 6:57 PM: It is not clear to me what the benefit of multiple files is beyond this association. Organization and ease of management for one. For example: smtpd_client_restrictions = check_recipient_access hash:/etc/postfix/access check_client_access hash:/etc/postfix/access pcre:/etc/postfix/check_client_fqdn.pcre hash:/etc/postfix/coolsavings.access hash:/etc/postfix/richk-1.access cidr:/etc/postfix/cidr_files/china.cidr cidr:/etc/postfix/cidr_files/korea.cidr cidr:/etc/postfix/cidr_files/russia.cidr cidr:/etc/postfix/cidr_files/ukraine.cidr cidr:/etc/postfix/cidr_files/malaysia.cidr cidr:/etc/postfix/cidr_files/belarus.cidr cidr:/etc/postfix/cidr_files/indonesia.cidr cidr:/etc/postfix/cidr_files/hongkong.cidr cidr:/etc/postfix/cidr_files/africa.cidr cidr:/etc/postfix/cidr_files/romania.cidr cidr:/etc/postfix/cidr_files/thailand.cidr cidr:/etc/postfix/cidr_files/poland.cidr cidr:/etc/postfix/cidr_files/spammer.cidr cidr:/etc/postfix/cidr_files/hurricane-electric.cidr cidr:/etc/postfix/cidr_files/richk-1.cidr pcre:/etc/postfix/access.pcre It's poor form to omit the check_client_access in front of each map name. All these cidr maps are a great example of separate tables that should be combined into a single table with a Makefile. Maintain the separate input files from different sources for easy management, then combine them into one table for postfix to use. My access file contains some whitelist email addresses, some whitelist domains, some blacklist domains, and some whitelist and blacklist IP addresses, so I do have some consolidation in the one file and I use it in multiple restriction classes.However, it's by far my smallest table file. Some of my cidr files are pretty large. Note that I'm using the IPdeny (http://www.ipdeny.com) data and rejecting entire countries' smtp connections. Some of those files have thousands of entries. Note also that I'm using multiple table types, hash, cidr, and pcre. It's better to use multiple files in this kind of setup. large cidr tables can use huge amounts of memory. If you really feel you need these, 1) consolidate them into one table, and 2) use proxymap to open the table once per postfix instance rather than once per smtpd process. If the data is available in multiple forms, hash: or cdb: tables scale much better than cidr, and a local DNSBL running rbldnsd scales even better. http://www.corpit.ru/mjt/rbldnsd.html -- Noel Jones
Re: Please evaluate my understanding wrt access files
On 10/30/2009 6:57 PM, Robert Lopez wrote: Postfix places no limit on how many maps you can use, but there is system overhead with each map. Rule of thumb is to combine maps wherever possible -- don't use two check_sender_access statements if you can do it with one. The smart way to do this is use a Makefile to build a single map from multiple similar input files. That is interesting. What is the advantage of that over directly editing a single file? I can see having unique names that pair with the parameters that cause them to be read. It is not clear to me what the benefit of multiple files is beyond this association. We do something similar with the virtualaliases table. There is a table that has all college employees who use an Exchange server, another that has all customers (students) who use Sungard Luminis, and a third that has Mailman lists. So email is delivered to one of those three systems based on that file. We build that single file from three separate files. That's a good example of files that can be automated with a Makefile. Maintain the separate files for clear management separation, then just type make to build a single postfix file. General example here: http://www.postfix.org/DATABASE_README.html#safe_db message_size_limit = 16777216 mydestination = $myhostname, $mydomain, localhost.localdomain, cnm.edu, mail.cnm.edu, mg0x.cnm.edu, mg04.cnm.edu, mg05.cnm.edu, nmvc.org, mail.nmvc.org, mg0x.nmvc.org, mg04.nmvc.org, mg05.nmvc.org, mg06.nmvc, nmvirtualcollege.org, mail.nmvirtualcollege.org, mg0x.nmvirtualcollege.org, mg04.nmvirtualcollege.org, mg05.nmvirtualcollege.org, mg04.nmvirtualcollege.org, nmln.net, ideal-nm.org, ideal-nm.net, idealnm.org, idealnm.net Lots of domains in mydestination... Are you sure these don't belong in relay_domains instead? http://www.postfix.org/BASIC_CONFIGURATION_README.html http://www.postfix.org/STANDARD_CONFIGURATION_README.html http://www.postfix.org/ADDRESS_CLASS_README.html No, I am not sure. All email going students and employees are sent to either Sungard Luminis servers or to Microsoft Exchange servers. At the most basic definition, relay_domains are domains that are accepted by postfix and sent to the same address on another box for final delivery. Sounds as if these are all relay_domains. Valid recipients for relay_domains should be listed in relay_recipient_maps, but it sounds as if you list them in virtual_alias_maps. Better to work with the system rather than against it. relay_domains = $mydestination relay_domains should be set explicitly, and generally should not include $mydestination. If there are no relay_domains, it should be set empty. http://www.postfix.org/ADDRESS_CLASS_README.html This may be another point where I am confused. I am thinking relay is when a postfix server accepts email for u...@cnm.edu and then rewrites that address to what is found in a table for the user where the email is then sent to u...@other.domain. Postfix would call those virtual_alias_domains -- domains that are accepted and rewritten to another domain for either local or remote delivery. Your domains are relay_domains. smtpd_banner = cnm.edu Should be cnm.edu ESTMP, or better, just leave it at the default. Is that cnm.edu ESMTP or default? The ESTMP is required to signal other mail servers that your server accepts enhanced command syntax. But there's usually no reason to change this setting from the default $myhostname ESTMP $mail_name, so just remove the parameter from your main.cf. You can't hide the fact you're running postfix, so don't worry too much about the $mail_name in there. smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/greylist check_sender_access hash:/etc/postfix/sender_access permit_mynetworks reject_unknown_sender_domain Seems like permit_mynetworks should come before greylist or other sender access checks. Seems like? :-) This greylist program reads the tail of the mail log and looks for bursts of email in a short period of time. The program adds the bursting account to the map which causes the email to be deferred. OK, you're using that as a outgoing quota control. There are policy servers that do similar and more, particularly policyd. http://www.postfix.org/addon.html#policy -- Noel Jones
Please evaluate my understanding wrt access files
Noel Jones put forth on 10/30/2009 11:50 PM: On 10/30/2009 9:05 PM, Stan Hoeppner wrote: Robert Lopez put forth on 10/30/2009 6:57 PM: It is not clear to me what the benefit of multiple files is beyond this association. Organization and ease of management for one. For example: smtpd_client_restrictions = check_recipient_access hash:/etc/postfix/access check_client_access hash:/etc/postfix/access pcre:/etc/postfix/check_client_fqdn.pcre hash:/etc/postfix/coolsavings.access hash:/etc/postfix/richk-1.access cidr:/etc/postfix/cidr_files/china.cidr cidr:/etc/postfix/cidr_files/korea.cidr cidr:/etc/postfix/cidr_files/russia.cidr cidr:/etc/postfix/cidr_files/ukraine.cidr cidr:/etc/postfix/cidr_files/malaysia.cidr cidr:/etc/postfix/cidr_files/belarus.cidr cidr:/etc/postfix/cidr_files/indonesia.cidr cidr:/etc/postfix/cidr_files/hongkong.cidr cidr:/etc/postfix/cidr_files/africa.cidr cidr:/etc/postfix/cidr_files/romania.cidr cidr:/etc/postfix/cidr_files/thailand.cidr cidr:/etc/postfix/cidr_files/poland.cidr cidr:/etc/postfix/cidr_files/spammer.cidr cidr:/etc/postfix/cidr_files/hurricane-electric.cidr cidr:/etc/postfix/cidr_files/richk-1.cidr pcre:/etc/postfix/access.pcre It's poor form to omit the check_client_access in front of each map name. It may be poor form, but it's legal, gives the same result, and main.cf doesn't look nearly as busy/cluttered by omitting it. If/when it becomes mandatory, I'll add it. I hope it doesn't. All these cidr maps are a great example of separate tables that should be combined into a single table with a Makefile. Interesting. I may take a look into Makefile some time. I was unaware of it until today. Just out of curiosity, how does putting it all in one file make the resulting single file smaller than the sum of the individual files' contents? Does Makefile compress the contents in some way, such as postmap indexes hash files? I ask as the only overlapping data in my CIDR files is the REJECT + custom error within each CIDR file. Maintain the separate input files from different sources for easy management, then combine them into one table for postfix to use. Again, why does a single large map file consume less memory than a bunch of smaller map files, given there is no overlap but some of the custom error message text? My access file contains some whitelist email addresses, some whitelist domains, some blacklist domains, and some whitelist and blacklist IP addresses, so I do have some consolidation in the one file and I use it in multiple restriction classes.However, it's by far my smallest table file. Some of my cidr files are pretty large. Note that I'm using the IPdeny (http://www.ipdeny.com) data and rejecting entire countries' smtp connections. Some of those files have thousands of entries. Note also that I'm using multiple table types, hash, cidr, and pcre. It's better to use multiple files in this kind of setup. large cidr tables can use huge amounts of memory. If you really feel you need these, 1) consolidate them into one table, and 2) use proxymap to open the table once per postfix instance rather than once per smtpd process. If the data is available in multiple forms, hash: or cdb: tables scale much better than cidr, and a local DNSBL running rbldnsd scales even better. http://www.corpit.ru/mjt/rbldnsd.html This is moot in a low volume environment serving around 1000 connections a day, with no concurrency, is it not? My smptd's currently use 8MB VIRT and 4MB RES, and IIRC the max I've ever seen were two smtpd processes running simultaneously. Now, should I start hitting 25 to 50K connections per day, then I should probably look at optimizing my map files a bit, no? Thanks for the hints Noel. I may need them down the road, although not at the moment. Though I am curious and may play around with Makefile just to learn something. -- Stan
