Re: how to protect against directory attack?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 22/6/10 0:01, mouss wrote: motty.cruz a écrit : Hello all, What is the best way to protect against directory attack? [snip] how about: don't care? # postlog.pl Recipient unknown..: 58.35 % ... it's been so since a long time and the world didn't collapse here. If you manage to cut them before they hit any real address you avoid crud entering your user's mailboxes. We have a testing list with a funny familiar Spanish name (that is in dictionaries for sure) but it is not published anywhere and sends nothing to the outside world, and we are getting spam in the moderation queue of the thing! - -- Victoriano Giralt Systems Manager Central ICT Services University of Malaga SPAIN -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMIFXIV6+mDjj1PTgRAxAWAKDIHRH5xP//ggjgPOm3E2+To84G3QCgqZYS zpelRamPnD7mQCSYlQC79W4= =wS31 -END PGP SIGNATURE-
Interface aliases and sending mail from postfix
I'm using chroot environments as a form of virtualization of two mail systems. The main system has a basic ethernet interface eth0 with IP0 and two aliases: eth0:1 and eth0:2 with IP1 and IP2. Each chrooted system is running its own postfix with IPx configured in /etc/postfix/master.cf. The problem shows up when postfix sends a message. Although it's configured to use either IP1 or IP2, the receiving server sees it as IP0. IP0 is not resolved as a valid domain address, hence many servers reject my mail. The question is probably more about setting up Linux to use aliases instead of basic IP0. Any suggestions? -- ToMasz
Re: Interface aliases and sending mail from postfix
Am 22.06.2010 10:40, schrieb nunatarsuaq: I'm using chroot environments as a form of virtualization of two mail systems. The main system has a basic ethernet interface eth0 with IP0 and two aliases: eth0:1 and eth0:2 with IP1 and IP2. Each chrooted system is running its own postfix with IPx configured in /etc/postfix/master.cf. The problem shows up when postfix sends a message. Although it's configured to use either IP1 or IP2, the receiving server sees it as IP0. IP0 is not resolved as a valid domain address, hence many servers reject my mail. The question is probably more about setting up Linux to use aliases instead of basic IP0. Any suggestions? use smtp_bind_address= to bind outgoing mail to an ip -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Large incoming queues
On my central postfix server I do typically 100k mail transactions per hour. Postfix 2.7 on a Dual Quadcore Xeon 4 GB Ram RHEL5 box. Sometimes this happens that mails move very slowly from incoming queue to the active queue. I think I got the basic hygiene right: This server has absolutely no header-checks , no content-checks , transport file ( hash) has less than 2k lines and syslog is not an issue too. ( I dev-nulled the mail and tested that ) I suspect that the machine is starving on I/O , but iostat shows an iowait of only 10% From the qshape readme http://www.postfix.com/QSHAPE_README.html If the problem is I/O starvation, consider striping the queue over more disks Does that mean I can have them over different partitions on different disks. I had initially assumed all the postfix spool must be on the same partition Thanks Ram
Re: Interface aliases and sending mail from postfix
I didnt' mention that but there's an extra interface in this system connected to the local network. When smtp_bind_address is set to the public IP and I'm trying to send something from LAN I get the log message: Jun 22 11:44:32 server emaster_postfix/smtp[6940]: D6AC76802D: to=exam...@example.com, relay=192.168.1.10[192.168.1.10]:10024, delay=0.12, delays=0.12/0/0/0, dsn=4.4.2, status=deferred (lost connection with 192.168.1.10[192.168.1.10] while receiving the initial server greeting) smtp_bind_address doesn't accept two IPs, local and public. Is there any other solution? 2010/6/22 Robert Schetterer rob...@schetterer.org: Am 22.06.2010 10:40, schrieb nunatarsuaq: I'm using chroot environments as a form of virtualization of two mail systems. The main system has a basic ethernet interface eth0 with IP0 and two aliases: eth0:1 and eth0:2 with IP1 and IP2. Each chrooted system is running its own postfix with IPx configured in /etc/postfix/master.cf. The problem shows up when postfix sends a message. Although it's configured to use either IP1 or IP2, the receiving server sees it as IP0. IP0 is not resolved as a valid domain address, hence many servers reject my mail. The question is probably more about setting up Linux to use aliases instead of basic IP0. Any suggestions? use smtp_bind_address= to bind outgoing mail to an ip -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria -- ToMasz http://skocz.pl/przystanekGL - wspomnienia coraz bardziej odległe...
Routing (relaying) an unknown Domain
Seems strange but I need to route a local and unknown to DNS domain, to
an internal SMTP server.
Here the situation: I have an internal mail server running postfix 2.3.8
and Courier Imap. The server is the official MX record for our company
domains.
I have also a fax server and we implemented the email2fax feature. The
fax server has his own SMTP server (Exim) and if I send an email
directly to it, the email is processed and sent as a fax.
Now, I'd like to send my email(2fax) to the official SMTP server
(postfix) and I need this email routed to the fax server SMTP.
The email(2fax) RCPT-TO is like u...@dest-fax-number.fax, es.
managem...@0123456789.fax. Right now the postfix reject this destination
because Host or domain name not found. Name service error for
name=123456789.fax type=A: Host not found.
I'm not a postfix guru but I'm reading the docs. I configured a
/etc/postfix/transport file like this:
.faxsmtp:[192.168.0.1]
where 192.168.0.1 is the IP address of the faxserver..
I tried some permission/restriction on main.cf but I can't selectively
accept email for the domain 0123456789.fax, thinking also that the
number part always change. I think email is bounced before to be ready
for the transport instructions. It's ok for me to trust my local
network but also I don't want to transform our SMTP in an open relay for
the outside world.
Can someone point me in the right direction on how to solve this dilemma?
Here my postconf -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
anvil_rate_time_unit = 5
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
home_mailbox = Maildir/
inet_interfaces = all
local_transport = virtual
mailbox_size_limit = 0
message_size_limit = 5120
mydestination = example1.com, localhost, example2.com
myhostname = mail.example1.com
mynetworks = 127.0.0.0/8, 192.168.0.0/24, 192.168.100.0/24
myorigin = /etc/mailname
recipient_delimiter = +
relay_domains = $mydestination
relayhost =
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_sender_restrictions = reject_non_fqdn_sender
reject_unknown_sender_domain
smtpd_tls_cert_file = /etc/courier/imapd.pem
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_domains = example1.com, example2.com
virtual_gid_maps = static:5000
virtual_mailbox_base = /home
virtual_mailbox_limit = 0
virtual_mailbox_maps = ldap:mastermail
virtual_uid_maps = static:5000
Thanks!
Re: Interface aliases and sending mail from postfix
Am 22.06.2010 11:48, schrieb nunatarsuaq: I didnt' mention that but there's an extra interface in this system connected to the local network. When smtp_bind_address is set to the public IP and I'm trying to send something from LAN I get the log message: Jun 22 11:44:32 server emaster_postfix/smtp[6940]: D6AC76802D: to=exam...@example.com, relay=192.168.1.10[192.168.1.10]:10024, delay=0.12, delays=0.12/0/0/0, dsn=4.4.2, status=deferred (lost connection with 192.168.1.10[192.168.1.10] while receiving the initial server greeting) smtp_bind_address doesn't accept two IPs, local and public. Is there any other solution? i am sure this can be fixed, but for now you send to less info about your setup, what are you trying to goal with running 2 instances of postfix? 2010/6/22 Robert Schetterer rob...@schetterer.org: Am 22.06.2010 10:40, schrieb nunatarsuaq: I'm using chroot environments as a form of virtualization of two mail systems. The main system has a basic ethernet interface eth0 with IP0 and two aliases: eth0:1 and eth0:2 with IP1 and IP2. Each chrooted system is running its own postfix with IPx configured in /etc/postfix/master.cf. The problem shows up when postfix sends a message. Although it's configured to use either IP1 or IP2, the receiving server sees it as IP0. IP0 is not resolved as a valid domain address, hence many servers reject my mail. The question is probably more about setting up Linux to use aliases instead of basic IP0. Any suggestions? use smtp_bind_address= to bind outgoing mail to an ip -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: (SOLVED) Routing (relaying) an unknown Domain
Ok...I wasn't seeing it but it was simple.
The /etc/postfix/transport is correctly configured. I just needed to add
in main.cf this:
transport_maps = hash:/etc/postfix/transport
because by default the value is empty.
Thanks!
On 06/22/2010 11:59 AM, Daniele Davolio wrote:
Seems strange but I need to route a local and unknown to DNS domain, to
an internal SMTP server.
Here the situation: I have an internal mail server running postfix 2.3.8
and Courier Imap. The server is the official MX record for our company
domains.
I have also a fax server and we implemented the email2fax feature. The
fax server has his own SMTP server (Exim) and if I send an email
directly to it, the email is processed and sent as a fax.
Now, I'd like to send my email(2fax) to the official SMTP server
(postfix) and I need this email routed to the fax server SMTP.
The email(2fax) RCPT-TO is like u...@dest-fax-number.fax, es.
managem...@0123456789.fax. Right now the postfix reject this destination
because Host or domain name not found. Name service error for
name=123456789.fax type=A: Host not found.
I'm not a postfix guru but I'm reading the docs. I configured a
/etc/postfix/transport file like this:
.fax smtp:[192.168.0.1]
where 192.168.0.1 is the IP address of the faxserver..
I tried some permission/restriction on main.cf but I can't selectively
accept email for the domain 0123456789.fax, thinking also that the
number part always change. I think email is bounced before to be ready
for the transport instructions. It's ok for me to trust my local
network but also I don't want to transform our SMTP in an open relay for
the outside world.
Can someone point me in the right direction on how to solve this dilemma?
Here my postconf -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
anvil_rate_time_unit = 5
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
home_mailbox = Maildir/
inet_interfaces = all
local_transport = virtual
mailbox_size_limit = 0
message_size_limit = 5120
mydestination = example1.com, localhost, example2.com
myhostname = mail.example1.com
mynetworks = 127.0.0.0/8, 192.168.0.0/24, 192.168.100.0/24
myorigin = /etc/mailname
recipient_delimiter = +
relay_domains = $mydestination
relayhost =
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_sender_restrictions = reject_non_fqdn_sender
reject_unknown_sender_domain
smtpd_tls_cert_file = /etc/courier/imapd.pem
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_domains = example1.com, example2.com
virtual_gid_maps = static:5000
virtual_mailbox_base = /home
virtual_mailbox_limit = 0
virtual_mailbox_maps = ldap:mastermail
virtual_uid_maps = static:5000
Thanks!
--
Distinti saluti
--
Daniele Davolio
Information Technology Department
tel: +39 0522 268059
fax: +39 0522 331673
e-mail: d.davo...@mastertraining.it
web: www.mastertraining.it
Master Training S.r.l.
Sede Legale: via Timolini, 18 - Correggio (RE) - Italy
Sede Operativa: via Sani, 15 - Reggio Emilia - Italy
Sede Commerciale: via Sani, 9 - Reggio Emilia - Italy
Le informazioni contenute in questa e-mail sono da considerarsi
confidenziali e esclusivamente per uso personale dei destinatari sopra
indicati. Questo messaggio può includere dati personali o sensibili.
Qualora questo messaggio fosse da Voi ricevuto per errore vogliate
cortesemente darcene notizia a mezzo e-mail e distruggere il messaggio
ricevuto erroneamente. Quanto precede ai fini del rispetto del Decreto
Legislativo 196/2003 sulla tutela dei dati personali e sensibili.
This e-mail and any file transmitted with it is intended only for the
person or entity to which is addressed and may contain information that
is privileged, confidential or otherwise protected from
disclosure.Copying, dissemination or use of this e-mail or the
information herein by anyone other than the intended recipient is
prohibited. If you have received this e-mail by mistake, please notify
us immediately by telephone or fax.
Re: how to protect against directory attack?
On 2010-06-22 2:18 AM, Victoriano Giralt wrote: If you manage to cut them before they hit any real address you avoid crud entering your user's mailboxes. It's called recipient validation, and if you aren't doing it, you're doing it wrong. We have a testing list with a funny familiar Spanish name (that is in dictionaries for sure) but it is not published anywhere and sends nothing to the outside world, and we are getting spam in the moderation queue of the thing! So add a spam filter. Just because an address isn't published anywhere doesn't mean it won't be targeted.
Re: Interface aliases and sending mail from postfix
Actually I have two mail/www/ftp systems for two different domains on a single piece of hardware. Instead of using a virtualization I chose chroot as a more efficient method of using system resources and a way to separate two independent servers. The hardware has two network interfaces, one connected to the internet and another connected to the LAN. It allows to limit external bandwidth and allow for high-speed connections between work stations and mail servers. 2010/6/22 Robert Schetterer rob...@schetterer.org: Am 22.06.2010 10:40, schrieb nunatarsuaq: I'm using chroot environments as a form of virtualization of two mail systems. The main system has a basic ethernet interface eth0 with IP0 and two aliases: eth0:1 and eth0:2 with IP1 and IP2. Each chrooted system is running its own postfix with IPx configured in /etc/postfix/master.cf. The problem shows up when postfix sends a message. Although it's configured to use either IP1 or IP2, the receiving server sees it as IP0. IP0 is not resolved as a valid domain address, hence many servers reject my mail. The question is probably more about setting up Linux to use aliases instead of basic IP0. Any suggestions? use smtp_bind_address= to bind outgoing mail to an ip -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria -- ToMasz http://skocz.pl/przystanekGL - wspomnienia coraz bardziej odległe...
Re: customizing received: headers
Keld Simonsen: [ Charset ISO-8859-1 unsupported, converting... ] On Fri, May 28, 2010 at 08:52:04PM -0400, Wietse Venema wrote: Keld Simonsen: Hi I am running majordomo with postfix for a number of email list, and I have some trouble tracking down bounces. I thought that if I could have some customized Received: headers with the envelope receiver logged eg by for user then I would be able to track some mutating adressees. Seems like some postfixes do that, but mine does not. I could not find something on it in the documentation or via google. Postfix logs Received..for recipient only if there is exactly one recipient. Otherwise there would be a privacy violation of BCC recipients, including the addresses of mailing list members. is there a way to customize the received: header? That would be a mistake with multi-recipient mail. Are there other best practices for tracking down bounces for majordomo with postfix? Maybe having separate message ids per individual recepient? It's trivial with MTAs that implement standardized RFC 3462 style delivery status notifications. That's Postfix, Sendmail, and many other systems. With non-standard MTAs such as exim and qmail, it takes a bit of creative scripting. Another approach is to use VERP which sends one message per recipient and encodes the recipent in the bounce address. See http://www.postfix.org/VERP_README.html I am trying the VERP way, and have a little difficulty to understand what to do. I understand that there are two phases in the setup: 1. have sendmail generate an extended reply address, with the recipient added to the reply address, after a delimiter, which by default is + . the recepient address is added with the Where does VERP_README say that SENDMAIL must generate a specially-formatted sender address? Wietse
Re: Large incoming queues
Zitat von Ram r...@netcore.co.in: On my central postfix server I do typically 100k mail transactions per hour. Postfix 2.7 on a Dual Quadcore Xeon 4 GB Ram RHEL5 box. Sometimes this happens that mails move very slowly from incoming queue to the active queue. I think I got the basic hygiene right: This server has absolutely no header-checks , no content-checks , transport file ( hash) has less than 2k lines and syslog is not an issue too. ( I dev-nulled the mail and tested that ) I guess you have read http://www.postfix.org/QSHAPE_README.html#incoming_queue I suspect that the machine is starving on I/O , but iostat shows an iowait of only 10% From my point of view 10% can be quite a lot taken into account that it is for all processes on the machine. As there is only one qmgr but many smtpd it is possible that qmgr is limited by I/O on your machine. For possible band-aid have a look at in_flow_delay. Also check that mail is leaving fast, otherwise the active queue will max-out by default at 2 mails. From the qshape readme http://www.postfix.com/QSHAPE_README.html If the problem is I/O starvation, consider striping the queue over more disks Does that mean I can have them over different partitions on different disks. I had initially assumed all the postfix spool must be on the same partition From my understanding the spool must be on the same partition. The different disks is meant to be RAID 0/1/10 whatever or a seperate disk for the spool. Regards Andreas
Re: customizing received: headers
On Tue, Jun 22, 2010 at 07:34:17AM -0400, Wietse Venema wrote: Keld Simonsen: [ Charset ISO-8859-1 unsupported, converting... ] On Fri, May 28, 2010 at 08:52:04PM -0400, Wietse Venema wrote: Keld Simonsen: Hi I am running majordomo with postfix for a number of email list, and I have some trouble tracking down bounces. I thought that if I could have some customized Received: headers with the envelope receiver logged eg by for user then I would be able to track some mutating adressees. Seems like some postfixes do that, but mine does not. I could not find something on it in the documentation or via google. Postfix logs Received..for recipient only if there is exactly one recipient. Otherwise there would be a privacy violation of BCC recipients, including the addresses of mailing list members. is there a way to customize the received: header? That would be a mistake with multi-recipient mail. Are there other best practices for tracking down bounces for majordomo with postfix? Maybe having separate message ids per individual recepient? It's trivial with MTAs that implement standardized RFC 3462 style delivery status notifications. That's Postfix, Sendmail, and many other systems. With non-standard MTAs such as exim and qmail, it takes a bit of creative scripting. Another approach is to use VERP which sends one message per recipient and encodes the recipent in the bounce address. See http://www.postfix.org/VERP_README.html I am trying the VERP way, and have a little difficulty to understand what to do. I understand that there are two phases in the setup: 1. have sendmail generate an extended reply address, with the recipient added to the reply address, after a delimiter, which by default is + . the recepient address is added with the Where does VERP_README say that SENDMAIL must generate a specially-formatted sender address? I don't know. It was just my understanding that this was the way it worked. Or: that the bounce address was specifically generated per message - and that the -XV option to sendmail was the mechanism for triggering this behaviour. The VERP_README says: In order to make VERP useful with majordomo etc. mailing lists, you would configure the list manager to submit mail according to one of the following two forms: Postfix 2.3 and later: % sendmail -XV -f owner-listname other-arguments... Can I use VERP without specifically generated bounce addresses? How do I then identify the problem adressee - which possibly has a mutated address? Best regards keld
Re: customizing received: headers
Keld Simonsen: Another approach is to use VERP which sends one message per recipient and encodes the recipent in the bounce address. See http://www.postfix.org/VERP_README.html I am trying the VERP way, and have a little difficulty to understand what to do. I understand that there are two phases in the setup: 1. have sendmail generate an extended reply address, with the recipient added to the reply address, after a delimiter, which by default is + . the recepient address is added with the Where does VERP_README say that SENDMAIL must generate a specially-formatted sender address? I don't know. It was just my understanding that this was the way it worked. Or: that the bounce address was specifically generated per message - and that the -XV option to sendmail was the mechanism for triggering this behaviour. The VERP_README says: In order to make VERP useful with majordomo etc. mailing lists, you would configure the list manager to submit mail according to one of the following two forms: Postfix 2.3 and later: % sendmail -XV -f owner-listname other-arguments... Yes. When the documentation says this, then that is what you are supposed to do. Can I use VERP without specifically generated bounce addresses? How do I then identify the problem adressee - which possibly has a mutated address? If you could scroll down a few lines from the sendmail -XV example, then you will find all this spelled out in detail. Including the part that says how the failed recipient address comes back: With this set up, undeliverable mail for u...@domain will be returned to the following address: owner-listname+user=dom...@your.domain I can lead the horse to the water but I can't force it to drink. Wietse
Re: how to protect against directory attack?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 22/6/10 12:54, Charles Marcus wrote: On 2010-06-22 2:18 AM, Victoriano Giralt wrote: If you manage to cut them before they hit any real address you avoid crud entering your user's mailboxes. It's called recipient validation, and if you aren't doing it, you're doing it wrong. We DO recipient validation. I'm talking about cutting off the client before they hit a good one. The point I was making is that if you use something like fail2ban that detect an IP address that is doing a dictionary attack, and block the connection you reduce the probability of finding a recipient that will get validated. So add a spam filter. Just because an address isn't published anywhere doesn't mean it won't be targeted. I know that, been doing email since '85. We are not allowed to filter mail (except viruses) by policy. So we need other anti spam meassures, once we accept mail we MUST deliver it (except for viruses). - -- Victoriano Giralt Systems Manager Central ICT Services University of Malaga SPAIN -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMILDEV6+mDjj1PTgRA7z+AJ9im1gf2OjB8QAc04d1E75KeYy81gCfQYK4 bcEK8CuxTp5Vn2tVMIEHvPg= =Ueyp -END PGP SIGNATURE-
Re: Limiting .forward file processing
On Tue, Jun 22, 2010 at 11:53:37AM +0200, Mariusz Kie?pi?ski wrote: allow_mail_to_commands and allow_mail_to_files according to http://www.postfix.org/postconf.5.html are global for all users. I have a need do disallow processing of .forward for most user (default behavior) however some of them should still have a possibility of usage .forward file. In the other words is this possible to block processing .forward file for some users ? Yes, by using multiple copies of the local transport in master.cf, and using transport_maps to route mail for selected users to an alternate local transport, (with -o foo=bar overrides in master.cf). local2unix - n n - - local -o ... -- Viktor.
Re: how to protect against directory attack?
On 2010-06-22 8:47 AM, Victoriano Giralt wrote: On 22/6/10 12:54, Charles Marcus wrote: On 2010-06-22 2:18 AM, Victoriano Giralt wrote: If you manage to cut them before they hit any real address you avoid crud entering your user's mailboxes. We DO recipient validation. I'm talking about cutting off the client before they hit a good one. The point I was making is that if you use something like fail2ban that detect an IP address that is doing a dictionary attack, and block the connection you reduce the probability of finding a recipient that will get validated. Ahh... you are attempting to hide your valid recipients. Security through obscurity is a waste of time and resources imo. I use fail2ban, but only to block hack attempts... I don't care much about someone finding out who the valid recipients are, I'm much more concerned with someone trying to crack a password... We are not allowed to filter mail (except viruses) by policy. So we need other anti spam meassures, once we accept mail we MUST deliver it (except for viruses). That's what I meant - add an after-queue filter and TAG+Deliver it. Use sieve to deliver it to a Spam folder if desired. -- Best regards, Charles
Re: how to protect against directory attack?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 22/6/10 16:47, Charles Marcus wrote: We DO recipient validation. I'm talking about cutting off the client before they hit a good one. The point I was making is that if you use something like fail2ban that detect an IP address that is doing a dictionary attack, and block the connection you reduce the probability of finding a recipient that will get validated. Ahh... you are attempting to hide your valid recipients. Security through obscurity is a waste of time and resources imo. No. I think I'm not making the point through. It is cler we are in the same boat, I also despise security by obscrity. I use fail2ban, but only to block hack attempts... I don't care much about someone finding out who the valid recipients are, I'm much more concerned with someone trying to crack a password... Sure! But, once we have fail2ban in place, and watching over the logs, it cost nothing to stop someone running a list trying to deliver some crud. I compare this to the SSH attacks: nowadays is not safe to have passwords for SSH authentication, but that does not preclude cutting access of list attackers with the likes of fail2ban so they do not lock resources like TCP sockets or CPU cycles, or generate too much noise in the logs. That's what I meant - add an after-queue filter and TAG+Deliver it. Use sieve to deliver it to a Spam folder if desired. Agreed. Deciding on content should be on the hands of users, but, please, do not start a flame over this. It will depart from the OP question. - -- Victoriano Giralt Systems Manager Central ICT Services University of Malaga SPAIN -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMINCWV6+mDjj1PTgRAy8ZAJ4iV4chx6byB5BUd8ieho/yIBTLPACcDuu6 8YZzJL71nzV1A1WfFmlCaGE= =kTnF -END PGP SIGNATURE-
Re: customizing received: headers
On Tue, Jun 22, 2010 at 08:39:31AM -0400, Wietse Venema wrote: Keld Simonsen: Another approach is to use VERP which sends one message per recipient and encodes the recipent in the bounce address. See http://www.postfix.org/VERP_README.html I am trying the VERP way, and have a little difficulty to understand what to do. I understand that there are two phases in the setup: 1. have sendmail generate an extended reply address, with the recipient added to the reply address, after a delimiter, which by default is + . the recepient address is added with the Where does VERP_README say that SENDMAIL must generate a specially-formatted sender address? I don't know. It was just my understanding that this was the way it worked. Or: that the bounce address was specifically generated per message - and that the -XV option to sendmail was the mechanism for triggering this behaviour. The VERP_README says: In order to make VERP useful with majordomo etc. mailing lists, you would configure the list manager to submit mail according to one of the following two forms: Postfix 2.3 and later: % sendmail -XV -f owner-listname other-arguments... Yes. When the documentation says this, then that is what you are supposed to do. yes, but where? Can I use VERP without specifically generated bounce addresses? How do I then identify the problem adressee - which possibly has a mutated address? If you could scroll down a few lines from the sendmail -XV example, then you will find all this spelled out in detail. Including the part that says how the failed recipient address comes back: With this set up, undeliverable mail for u...@domain will be returned to the following address: owner-listname+user=dom...@your.domain I can lead the horse to the water but I can't force it to drink. Thanks for spelling it out to me. I think I allready had understood most of this. I am interpreting your answer above that I cannot use VERP without the specially generated return address: owner-listname+user=dom...@your.domain I then have some questions on things that are unclear to me: Where do I set up the -XV option to sendmail? I sometimes just use an include in the alias file for a bigger list, and sometimes I use majordomo. For majordomo I am using wrapper in the alias file. majordomo has a number of instances in diverse files in /home/majordomo that either invoke /usr/sbin/sendmail or /usr/lib/sendmail. On which one(s) should I add -XV? Is -XV a reasonable option to /usr/lib/sendmail, or does it only work with /usr/sbin/sendmail ? For the non-majordomo lists - where do I invoke sendmail -XV ? It looks like this is not doable in the alias file. I did not see any obvious place in postfix main.cf nor master.cf either. Thanks for your help. best regards keld
Re: customizing received: headers
Keld Simonsen: The VERP_README says: In order to make VERP useful with majordomo etc. mailing lists, you would configure the list manager to submit mail according to one of the following two forms: Postfix 2.3 and later: % sendmail -XV -f owner-listname other-arguments... Yes. When the documentation says this, then that is what you are supposed to do. yes, but where? You configre the program that invokes the Postfix sendmail command, so that it invokes the command like so: sendmail -XV -f owner-listname other-arguments... With Majordomo the sendmail command line is in a config file, buried in Perl syntax. Other list managers should have equivalent configuration mechanisms. DO NOT feed a specially-formatted sender address into the Postfix sendmail command. Just follow the d*mned instructions. With this set up, undeliverable mail for u...@domain will be returned to the following address: owner-listname+user=dom...@your.domain And that is all. Again, DO NOT feed a specially-formatted sender address into the Postfix sendmail command. Just do what the instructins say. Wietse
Re: Limiting .forward file processing
Victor Duchovni wrote: On Tue, Jun 22, 2010 at 11:53:37AM +0200, Mariusz Kie?pi?ski wrote: allow_mail_to_commands and allow_mail_to_files according to http://www.postfix.org/postconf.5.html are global for all users. I have a need do disallow processing of .forward for most user (default behavior) however some of them should still have a possibility of usage .forward file. In the other words is this possible to block processing .forward file for some users ? Yes, by using multiple copies of the local transport in master.cf, and using transport_maps to route mail for selected users to an alternate local transport, (with -o foo=bar overrides in master.cf). local2unix - n n - - local -o ... Ok. So I added in master.cf local_no_forwardunix - n n - - local -o allow_mail_to_commands=alias -o allow_mail_to_files=alias I also created transport_maps /u...@.*/ local_no_forward: and postmap-ed it To main.cf I added transport_maps = pcre:/etc/postfix/transport_maps It seems that maps works because DF82C8B2E8: to=u...@xxx, relay=local_no_forward, delay=0.12, delays=0.06/0.01/0/0.05, dsn=2.0.0, status=sent (forwarded as EFDC48B2E6) However .forward file in home directory of user still works What is wrong ?
Spooling mail Question
I am running postfix as a SMTP front-end to my Exchange 2007 system. When Exchange goes down, email is bounced back to the sender as undeliverable. How can I setup postfix to 'spool' email until the backend SMTP server is online? I have enclosed my main.cf, master.cf, and transport configs (at least the non-default ones). Main.cf: default_process_limit = 600 minimal_backoff_time = 60 maximal_backoff_time = 240 queue_minfree = 8000 smtp_helo_timeout = 20s smtp_quit_timeout = 30s smtp_mail_timeout = 20s smtp_rcpt_timeout = 20s smtpd_helo_required = yes biff=no disable_vrfy_command = yes smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, # reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining, check_recipient_access pcre:/usr/local/etc/postfix/recipient_checks.pcre, check_sender_access hash:/usr/local/etc/postfix/sender_checks, check_client_access hash:/usr/local/etc/postfix/client_checks, check_policy_service inet:127.0.0.1:12525, # check_policy_service inet:127.0.0.1:10023, permit smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_error_sleep_time = 5 smtpd_soft_error_limit = 5 smtpd_hard_error_limit = 10 smtpd_junk_command_limit = 10 smtpd_recipient_overshoot_limit = 100 maximal_queue_lifetime = 10d # # Spam Transport # transport_maps = hash:/usr/local/etc/postfix/transport #relay_recipient_maps = hash:/usr/local/etc/postfix/exchange_recipients Master.cf: smtp inet n - n - - smtpd -o smtpd_proxy_filter=127.0.0.1:10024 -o smtpd_proxy_timeout=200 127.0.0.1:24 unix - - - - 2 smtp -o smtp_data_done_timeout=1200 -o disable_dns_lookups=yes 127.0.0.1:10025 inet n - - - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions=permit_mynetworks -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o maximal_queue_lifetime=10d -o strict_rfc821_envelopes=yes transport: ## # Exchange Config ## #company.com smtp:[mail.company.local] acme.net smtp:[10.10.10.50]
Re: Spooling mail Question
* Chris kingpinofdi...@yahoo.com: I am running postfix as a SMTP front-end to my Exchange 2007 system. When Exchange goes down, email is bounced back to the sender as undeliverable. Why? Show some logs for such a case How can I setup postfix to 'spool' email until the backend SMTP server is online? That's the default :) I have enclosed my main.cf, master.cf, and transport configs (at least the non-default ones). postconf -n is very much preferred. The config looks OK so far -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Accept mail only from certain domains for one of many domains.
Hello all, I have a some what convoluted setup that I'd like to make a modification to, and was looking for some pointers. The Long-winded situation: I run a small host that servers as a mail server for multiple domains (about 25). All but one of these is a fairly standard setup using virtual_alias_domains + virtual_alias_maps + --- smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/helo_client_exceptions, check_sender_access hash:/etc/postfix/sender_checks, reject_invalid_hostname, permit_sasl_authenticated, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, # Check with sqlgrey. check_policy_service inet:127.0.0.1:2501 check_client_access hash:/etc/postfix/rbl_client_exceptions, reject_rbl_client cbl.abuseat.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rhsbl_sender dns.rfc-ignorant.org mynetworks = 192.168.0.0/16 127.0.0.0/8 64.18.0.0/20 # Note: 64.18.0.0/20 is Postini. --- The one odd-ball domain, however, pays Postini to filter their mail, which is included in mynetworks. The Postini domain's MX records all point to Postini servers. The QUESTION: Is there a way to get just this domain to only accept messages from Postini + other virtual domains on this server (I guess this is likely just mynetworks), while all the others continue to accept valid messages from anyone (as above)? Thanks! -- Philippe Chaintreuil
Re: Limiting .forward file processing
On Tue, Jun 22, 2010 at 06:04:37PM +0200, Mariusz Kie?pi?ski wrote: Victor Duchovni wrote: On Tue, Jun 22, 2010 at 11:53:37AM +0200, Mariusz Kie?pi?ski wrote: allow_mail_to_commands and allow_mail_to_files according to http://www.postfix.org/postconf.5.html are global for all users. I have a need do disallow processing of .forward for most user (default behavior) however some of them should still have a possibility of usage .forward file. In the other words is this possible to block processing .forward file for some users ? Yes, by using multiple copies of the local transport in master.cf, and using transport_maps to route mail for selected users to an alternate local transport, (with -o foo=bar overrides in master.cf). local2unix - n n - - local -o ... Ok. So I added in master.cf local_no_forwardunix - n n - - local -o allow_mail_to_commands=alias -o allow_mail_to_files=alias I also created transport_maps /u...@.*/ local_no_forward: and postmap-ed it You don't postmap regexp tables. More importantly you are aliasing this address local-part in all remote domains to be local. That's wrong. You must list the local domains one by one in the transport table u...@a.example.com local_no_forward u...@b.example.com local_no_forward u...@c.example.com local_no_forward and use a non-regexp transport table. To main.cf I added transport_maps = pcre:/etc/postfix/transport_maps It seems that maps works because DF82C8B2E8: to=u...@xxx, relay=local_no_forward, delay=0.12, delays=0.06/0.01/0/0.05, dsn=2.0.0, status=sent (forwarded as EFDC48B2E6) However .forward file in home directory of user still works The mail did not get piped to a command, it got forwarded to an address listed in .forward, the allow_mail_to... disable command processing. -- Viktor.
Re: customizing received: headers
On Tue, Jun 22, 2010 at 11:48:11AM -0400, Wietse Venema wrote: Keld Simonsen: The VERP_README says: In order to make VERP useful with majordomo etc. mailing lists, you would configure the list manager to submit mail according to one of the following two forms: Postfix 2.3 and later: % sendmail -XV -f owner-listname other-arguments... Yes. When the documentation says this, then that is what you are supposed to do. yes, but where? You configre the program that invokes the Postfix sendmail command, so that it invokes the command like so: sendmail -XV -f owner-listname other-arguments... With Majordomo the sendmail command line is in a config file, buried in Perl syntax. Other list managers should have equivalent configuration mechanisms. yes, there are a number of sendmail invocations in the majordomo perl scripts. I am just wondering which ones to change. A word count on the perl scripts in /home/majordomo says that there are 113 occurrances of sendmail. I probably should not change them all. And I am not that familiar with the intrinsics of majordomo scripts. I am probably not the first to do VERP with postfix and majordomo, so I hope others could help me before I do something hopelessly stupid, and which I will only discover many moons from now. DO NOT feed a specially-formatted sender address into the Postfix sendmail command. Just follow the d*mned instructions. With this set up, undeliverable mail for u...@domain will be returned to the following address: owner-listname+user=dom...@your.domain And that is all. Again, DO NOT feed a specially-formatted sender address into the Postfix sendmail command. Just do what the instructins say. I was intending to add -XV to a sendmail line somewhere - nothing else. For postfix proper, does postfix invoke the postfix sendmail command somewhere in the process as an MTA to deliver a mail, - for aliases expansion? I would have thought that this was governed by postfix/master.cf . That is postfix would receive a message on port 25 and then forward it to some queue for deliverance. I would then think I could employ postfix sendmail -XV to generate bounce mails with the recipients address in the bounce field somewhere. BTW, I got the delivery part to work as documented, so mail to user+sen...@domain gets delivered to u...@domain. So far, so good. best regards keld
fail2ban for spamtraps
I saw fail2ban discussed in another thread. I was wondering if anyone here have used it to block based on spamtraps. I want to set up a number of dummy users and splatter their email addresses where spammers would get at them (e.g. white on white text on web pages, etc). Then ban the IPs that try to send to N or more of those addresses, where N is relatively low, like 2.
Re: fail2ban for spamtraps
On 06/22/2010 02:30 PM, Phil Howard wrote: I saw fail2ban discussed in another thread. I was wondering if anyone here have used it to block based on spamtraps. I want to set up a number of dummy users and splatter their email addresses where spammers would get at them (e.g. white on white text on web pages, etc). Then ban the IPs that try to send to N or more of those addresses, where N is relatively low, like 2. This doesn't do exactly what you want; it only allows one attempt on a spamtrap address. Add more regexen and increase maxretry to taste. A word of caution: don't assume that everyone browses the web using a graphical web browser. People still browse from the command line, and more importantly, screen readers for the disabled. If you're going to hide an address, make sure that there is some indication (for humans) that the address should not be contacted under any circumstances. # jail.conf [spamtrap-iptables] # Be extra mean to these hosts. The bantime is 28 days. enabled = true bantime = 2419200 findtime = 86400 maxretry = 1 filter = spamtrap action = iptables[name=spamtrap, port=smtp, protocol=tcp] logpath = /var/log/mail/mail.log # filter.d/spamtrap.conf [Definition] failregex = reject: RCPT from (.*)\[HOST\]: 550 5\.1\.1 addr...@example\.com You will probably also need to configure the 'iptables' action, and some part of your iptables config. Snippets from mine won't help you much, but basically, I append banned addresses to a new fail2ban-name table, and then insert this table into my standard chain at a particular position during actionstart. (I also mail myself the output of iptables -L -n, so that I can verify that nothing has gone haywire.)
Re: how to protect against directory attack?
Victoriano Giralt a écrit : On 22/6/10 12:54, Charles Marcus wrote: On 2010-06-22 2:18 AM, Victoriano Giralt wrote: If you manage to cut them before they hit any real address you avoid crud entering your user's mailboxes. It's called recipient validation, and if you aren't doing it, you're doing it wrong. We DO recipient validation. I'm talking about cutting off the client before they hit a good one. The point I was making is that if you use something like fail2ban that detect an IP address that is doing a dictionary attack, and block the connection you reduce the probability of finding a recipient that will get validated. I don't believe in that. a motivated spammer can get around fail2ban and the like. such a spammer has enough IPs, networks, ... not only can they try different addresses from different IPs, but they can even do advanced analysis, which we can't. here is what I've seen: - spam from random places to random addresses. - snowshoe spam to _valid_ addresses. So add a spam filter. Just because an address isn't published anywhere doesn't mean it won't be targeted. I know that, been doing email since '85. We are not allowed to filter mail (except viruses) by policy. So we need other anti spam meassures, once we accept mail we MUST deliver it (except for viruses). we agree on the result: while I am allowed to filter mail, I prefer to block it as soon as possible (and I'm not a member of the plan for spam religion :)
Re: Accept mail only from certain domains for one of many domains.
Philippe Chaintreuil a écrit : Hello all, I have a some what convoluted setup that I'd like to make a modification to, and was looking for some pointers. The Long-winded situation: I run a small host that servers as a mail server for multiple domains (about 25). All but one of these is a fairly standard setup using virtual_alias_domains + virtual_alias_maps + --- smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/helo_client_exceptions, check_sender_access hash:/etc/postfix/sender_checks, reject_invalid_hostname, permit_sasl_authenticated, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, # Check with sqlgrey. check_policy_service inet:127.0.0.1:2501 check_client_access hash:/etc/postfix/rbl_client_exceptions, reject_rbl_client cbl.abuseat.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rhsbl_sender dns.rfc-ignorant.org mynetworks = 192.168.0.0/16 127.0.0.0/8 64.18.0.0/20 # Note: 64.18.0.0/20 is Postini. --- The one odd-ball domain, however, pays Postini to filter their mail, which is included in mynetworks. not the best you can do. mynetworks can relay, which postini don't need to. use a check_client_access instead... see below. The Postini domain's MX records all point to Postini servers. The QUESTION: Is there a way to get just this domain to only accept messages from Postini + other virtual domains on this server (I guess this is likely just mynetworks), while all the others continue to accept valid messages from anyone (as above)? you can use smtpd_restriction_classes. smtpd_restriction_classes = ... postini_protected smtpd_client_restrictions = check_recipient_access hash:/etc/postfix/postini_domains.hash postini_protected = check_client_access cidr:/etc/postfix/postini.cidr reject == postini_domains.hash example.com postini_protected == postini.cidr 10.1.2.0/24 OK ...
Re: Large incoming queues
lst_ho...@kwsoft.de put forth on 6/22/2010 6:50 AM: Zitat von Ram r...@netcore.co.in: Does that mean I can have them over different partitions on different disks. I had initially assumed all the postfix spool must be on the same partition From my understanding the spool must be on the same partition. The different disks is meant to be RAID 0/1/10 whatever or a seperate disk for the spool. This isn't even fully correct. Replace the word partition with filesystem. Postfix has no knowledge of disk provisioning, whether partitions, or logical volumes created by some like LVM, etc. Postfix reads from and writes to a filesystem, period. The suggestion in the documentation assumes the reader is educated with respect to *nix disk subsystems and filesystems. The suggestion is to create a filesystem on a partition or logical volume on a disk subsystem comprised of multiple disks and some form of striping to increase read/write throughput. Striping allows read/write to multiple disk simultaneously. One would put the postfix spool directory on the resulting filesystem. In order of maximal performance the preferred striping RAID level would be: 1. RAID 0 2. RAID 10 3. RAID 5 4. RAID 50 5. RAID 6 RAID 0 decreases reliability but has vastly superior performance. If one disk fails, both fail, from the OS's perspective. 2-5 all offer increased reliability but 3-5 have decreased performance due to parity calculations, especially so for RAID 6 which calculates parity _twice_. My advice would be to only use 3-5 on a good hardware RAID controller with 256MB or more of cache. Due to performance vs reliability factors, my recommendation would be to use 4 drives in a software or hardware RAID 10, preferably 10k or 15k RPM drives of the SCSI or SAS flavor. SATA will work also but will be 30% to 100% slower. From what the OP states, I'd say he'd probably do best with at least 73GB drives, which would yield 146GB of RAID 10 storage for the spool. This will yield twice the throughput of a single disk with double or more the reliability. RAID 10 can suffer two disk failures simultaneously, but they must be the right two disks because of the way the striping and mirroring is performed. Normally one would simply count on RAID 10 to gracefully suffer one disk failure, just like a mirrored set. -- Stan
smtpd soft_bounce
I was attempting to set soft_bounce=yes on the smtpd service in master.cf only to find that it didnt work. This was unexpected as the man pages indicate otherwise. 'man 8 smtpd' lists soft_bounce under 'trouble shooting controls'. But I've found that instead it works when placed on the 'smtp' service in master.cf (or in main.cf). My question is why? I mean it makes sense as its a delivery option, but still the mange pages indicate its an option of smtpd and the smtp man page mentions nothing about it.
Spam filtering
I am using postfix with Virtualmin and am trying to follow numerous
tutorials on spam prevention/handling. I have tried to apply the following
to the postfix main.cf file.
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
permit
#check_helo_access hash:/usr/local/etc/postfix/helo_access,
smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unauth_destination,
permit
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
permit
#check_policy_service unix:postgrey/socket,
#check_policy_service unix:private/spfpolicy
#check_policy_service inet:127.0.0.1:10023
#reject_rbl_client relays.ordb.org,
#reject_rbl_client list.dsbl.org,
#reject_rbl_client sbl-xbl.spamhaus.org,
#check_sender_access hash:/etc/postfix/sender_access,
#check_recipient_access hash:/etc/postfix/recipient_access,
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client dnsbl.sorbs.net,
permit
The items that are commented out are of concern. I cannot figure out how to
set them right. I have the rbl in the client_restrictions but online the
examples show in the recipient. Which is it? client or recipient?
Also, is there a good tutorial on configuring the HELO access file? I am
migrating from Eudora Internet Mail Server and have some nice HELO rules set
up there to catch a bunch of spam. I'd like to incorporate them into the
postfix setup.
For the HELO:
does not contain .
starts with [
contains .dynamic.
contains .adsl.
ends with .airtelbroadband.in
is speedtouch.lan
is gmail.com
contains .pool.
starts with adsl-
is dsldevice.lan
contains .dsl.
Expressions for a few of the top expressions:
Typical names for household connections contain a name followed by an ip
(dashed or dotted)
[a-zA-Z_-][0-9]{1,3}-[0-9]{1,3}-[0-9]{1,3}-[0-9]{1,3}.
[a-zA-Z_-][0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.
Plain IP number without [ ]:
[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}
With the spf handling, I keep seeing mention of a file that I am supposed to
have but it was not included in the install of CentOS 5. smtpd-policy.pl is
the file that everyone mentions I need for the SPF but it's no where to be
found and I did not see anywhere online to download this. In one spot, I saw
mention that it is not needed. Which is it? Is it worth it?
I have postgrey installed via yum. Does anyone know how to make all this
work? It seems it would be optimal setup for spam prevention.
It's a long post. Sorry.
Thanks
Steffan
---
T E L 6 0 2 . 7 9 3 . 0 0 1 4 | F A X 6 0 2 . 9 7 1 . 1 6 9 4
Steffan A. Cline
stef...@execuchoice.net Phoenix, Az
http://www.ExecuChoice.net USA
AIM : SteffanC ICQ : 57234309
YAHOO : Steffan_Cline MSN : stef...@hldns.com
GOOGLE: Steffan.Cline Lasso Partner Alliance Member
---
Re: smtpd soft_bounce
On Tue, Jun 22, 2010 at 07:00:56PM -0600, Patrick H. wrote: I was attempting to set soft_bounce=yes on the smtpd service in master.cf only to find that it didnt work. This was unexpected as the man pages indicate otherwise. 'man 8 smtpd' lists soft_bounce under 'trouble shooting controls'. But I've found that instead it works when placed on the 'smtp' service in master.cf (or in main.cf). My question is why? I mean it makes sense as its a delivery option, but still the mange pages indicate its an option of smtpd and the smtp man page mentions nothing about it. Both services implement the option. In the SMTP server, it causes 5XX replies TO SMTP CLIENTS to be downgraded to 4XX. This is a safety net for server configuration errors. In the SMTP client, it causes 5XX responses FROM SMTP SERVERS to be treated as 4XX responses. This is a safety-net for client or transport configuration errors. -- Viktor.
Outbound mail, relaying, Hotmail
Hello all, This question has probably been asked before in some form or another, but I can't seem to find a post that is exactly like the issue I'm struggling with (maybe I'm just blind). In any event, I hope that at least one of you might be able to help me. I've got two SLES 11 mail servers I manage. Both run Postfix 2.5.6. Both relay outbound mail through their respective ISP's mail system, as required by those same ISPs (inbound is unrestricted, outbound is only allowed through a designated relay host). The problem is, both have problems delivering mail to some hosts. Hotmail is a particular one (although there are a few others that belong to businesses we frequently work with). That has me wondering if something I have done (or have not done, perhaps) is to blame. Unfortunately, I'm only getting generic delivery failures from a few of the hosts and none at all with Hotmail and Yahoo (one drops the mail entirely and the other marks it as junk but delivers it). (Note: I do have to disclose one piece of information. Recently our server was automatically blacklisted by our ISP for spam that was being relayed through our system from a series of external sources. I've tested both servers against online open relay tests and performed my own internal tests at times to prevent relay of spam, so I can't say why they were able to relay. I ended up basically rewriting the smtpd_client_restrictions, smtpd_receipient_restrictions and smtpd_sender_restrictions lists. The relayed spam stopped and our ISP finally removed us from their blacklist) I've check log entries, but they all show outbound mail was successfully relayed through the ISP's SMTP server. My setup, for the most part, is pretty typical. I have a Postfix + Amavis (SpamAssassin + ClamAV) + Cyrus IMAP configuration. Amavis works on the basis of TCP ports, and delivery to Cyrus is via a LMTP socket. All mailboxes (in both Cyrus and Postfix) are virtual and are in no way tied to the system users/accounts. DNS is such that the MX for mydomain.com is mail.mydomain.com.The IP address resolves correctly on every DNS server I can bounce queries off of. I have *not* set up TXT records for SPF on any of my domains. Since I have to relay outbound mail through my ISP, and since things have worked fine until recently, I suppose it has been out of sight and out of mind. It's something I realize I need to do to satisfy those that use it. Here's postconf -n from one of the servers: alias_maps = hash:/etc/aliases always_bcc = archi...@mydomain.com broken_sasl_auth_clients = yes canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/lib/postfix debug_peer_level = 2 defer_transports = disable_dns_lookups = no disable_vrfy_command = yes header_checks = pcre:/etc/postfix/header_filter.pcre html_directory = /usr/share/doc/packages/postfix/html inet_interfaces = all mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = mailbox_size_limit = 0 mailbox_transport = mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_exceptions = root message_size_limit = 26214400 mime_header_checks = pcre:/etc/postfix/mime_filter.pcre mydestination = $myorigin myhostname = mydomain.com mynetworks = 127.0.0.0/8 [::1]/128 10.0.0.0/24 newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES relay_domains = relayhost = send.isp.net relocated_maps = hash:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix/samples sender_canonical_maps = hash:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_enforce_tls = no smtp_helo_name = mydomain.com smtp_sasl_security_options = noanonymous smtp_tls_enforce_peername = yes smtp_use_tls = no smtpd_banner = $myhostname ESMTP $mail_name smtpd_client_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/client_access.hash, permit_sasl_authenticated, reject_rbl_client zen.spamhaus.org, permit smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_delay_reject = yes smtpd_hard_error_limit = 10 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/etc/postfix/helo_filter.hash, check_helo_access pcre:/etc/postfix/helo_filter.pcre, reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, check_recipient_access hash:/etc/postfix/recip_filter.hash, check_recipient_access pcre:/etc/postfix/recip_filter.pcre, reject_unauth_destination,
Re: Spam filtering
Steffan A. Cline put forth on 6/22/2010 8:01 PM: It's a long post. Sorry. Yeah, it was long, and probably overly ambitious for a single thread topic. Instead of addressing your questions about individual main.cf parameter settings and policy services, I'm going to make a few suggestions which should give you a good start on rejecting most spam. 1. Keep your configuration as streamlined and simple as possible 2. Put all your restrictions under smtpd_recipient_restrictions 3. Use the regexp table I'm providing at the link far below 4. Use dnsbl queries selectively (why they're at the bottom) 5. Use only selective greylisting with postgrey (why it's last) Here's a sample smtpd_recipient_restrictions section you could start with, good with IIRC Postfix 2.3 and later. But first: smtpd_delay_reject = yes (unneeded as it's the default behavior) smtpd_helo_required = yes (you need this) smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination permit_sasl_authenticated reject_unknown_reverse_client_hostname reject_non_fqdn_sender reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unknown_helo_hostname reject_unlisted_recipient check_client_access regexp:/etc/postfix/fqrdns.regexp reject_rbl_client zen.spamhaus.org reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org check_policy_service inet:127.0.0.1:6 This should be all you need for now. You will improve this configuration over time. It appears in your example that you're querying postgrey twice, once via UNIX socket and once via inet. Pick one method, don't use both. I use the inet method (last line in main.cf above). You will need to configure that one method per the postgrey instructions. The Postgrey daemon config file on Debian is at the following location. On CentOS it may be located in a different directory. I don't use any Red Hat products so I'm unsure. You'll have to find it. cat /etc/default/postgrey # postgrey startup options, created for Debian # (c)2004 Adrian von Bidder avbid...@fortytwo.ch # Distribute and/or modify at will. # you may want to set # --delay=N how long to greylist, seconds (default: 300) # --max-age=N delete old entries after N days (default: 35) # see also the postgrey(8) manpage POSTGREY_OPTS=--inet=127.0.0.1:6 # the --greylist-text commandline argument can not be easily passed through # POSTGREY_OPTS when it contains spaces. So, insert your text here: #POSTGREY_TEXT=Your customized rejection message here If you run into problems, man 8 postgrey SPF and DKIM checks are pretty much useless for killing spam. You will already kill bot spam with other methods. Many snowshoe spammers are keen on using SPF records and to a lesser extent DKIM sigs. There really aren't any other large classes of spammers than bot and snowshoe, so again, trying to kill spam with SPF and DKIM checks is mostly an exercise in futility, and it adds unneeded complexity to your configuration. This has been discussed ad naseam on many spam fighting lists over the years. Regarding helo checks, it seems you're merely wanting to save effort expended on a previous mail server platform on which they worked well. Wrong logic. Helo checks won't kill much more spam than other checks, and the helo checks above are typically sufficient without getting into table checks against them. Don't worry about dragging the old helo stuff over to Postfix, as it will be wasted effort for the most part. Maybe keep them around for a rainy day down the road and convert them over _IF_ you find you _need_ them. Again, think streamline. Try to keep the configuration _simple_. The more complicated you make main.cf now the harder to troubleshoot is becomes later. Notice how short and simple my restriction list is? And don't think for a minute I created that overnight. I've been using Postfix since 2005 and have been refining it for 5 years. It became really streamlines after I took the advice of members of this list. Noel, mouss, and many others have helped me tremendously in streamlining my Postfix config, along with the excellent documentation, which can at times be a bit intimidating to the novice. This magic regexp table will kill a lot of bot and other spam coming from various ISPs' mostly dynamic space and will do it quicker than a dnsbl lookup. Another advantage is that it cuts down on your lookup queries, so if you're on that 300k Spamhaus borderline limit between paid and free service, this should drop those queries to the point you could likely use the free service. Even if you're not borderline, it's always better to kill spam with local filters before querying any outside service, dnsbl or otherwise. Download this http://www.hardwarefreak.com/fqrdns.regexp and save it in /etc/postfix/fqrdns.regexp as root.
Re: Outbound mail, relaying, Hotmail
Jason Bailey, Sun Advocate Webmaster put forth on 6/22/2010 10:32 PM: (Note: I do have to disclose one piece of information. Recently our server was automatically blacklisted by our ISP for spam that was being relayed through our system from a series of external sources. I've tested both servers against online open relay tests and performed my own internal tests at times to prevent relay of spam, so I can't say why they were able to relay. I ended up basically rewriting the smtpd_client_restrictions, smtpd_receipient_restrictions and smtpd_sender_restrictions lists. The relayed spam stopped and our ISP finally removed us from their blacklist) If the problem you describe started after this blacklisting, and you had none of these delivery problems before said blacklisting occurred, doesn't it seem pretty obvious that what you are seeing are residual effects of said blacklisting? Apparently the recipient domains in question have added you to their own internal black lists or other filter database categories (i.e. manual spam scoring of your domain in SA). You need to contact them--all of them--directly. -- Stan
