Re: Advice on filtering setup
Aggelos put forth on 2/2/2011 10:49 PM: on 02/03/2011 05:24 AM Aggelos wrote the following: With that setup, if I wanted to accept mail from a specific Internet IP, which would otherwise be filtered out, how would I do it? I meant clients that are rejected like so: Feb 3 06:46:59 viper postfix/smtpd[3924]: NOQUEUE: reject: RCPT from unknown[62.1.42.20]: 450 4.7.1 Client host rejected: cannot find your hostname, [62.1.42.20]; from=www-d...@insomnia.gr to=a...@vergina.dyndns.org proto=ESMTP helo=mail.insomnia.gr One possible method, using a cidr table: smtpd_recipient_restrictions = check_client_access cidr:/etc/postfix/whitelist.cidr reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unknown_client, reject_unknown_hostname, permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/client_checks, check_client_access pcre:/etc/postfix/client_checks.pcre, reject_rbl_client zen.spamhaus.org, permit /etc/postfix/whitelist.cidr 62.1.42.20 permit_auth_destination -- Stan
Re: Selective Relaying
Dominik Schulz: I'm currently planning to migrate an Exim mailserver to Postfix due to performance issues and security concerns. The Exim mailserver is configured to handle several virtual domains. If a recipient is not found in the virtual table, before rejecting this recipient, exim checks an MS Exchange mailserver via SMTP if the it would accept this recipient. If it does the mail is accepted and relayed to the Exchange server. If it does not the mail is rejected. Postfix uses a deterministic routing model, where mail for domain X is routed via a fixed path. You can make per-user overrides with virtual_alias_maps or transport_maps, and use reject_unverified_recipient to find out if a recipient address accepts mail. But this gets messy and results either in rejecting mail (user unknown) or accepting too much, causing you to become a backscatter source. The following is the simplest example that uses virtual_alias_maps to deflect unknown users to the MS Exchange mailserver, and that uses reject_unverified_recipient to find out if those users exist. Postfix 2.7 and later automatically cache the reject_unverified_recipient result. /etc/postfix/main.cf: virtual_alias_domains = a.example virtual_alias_maps = hash:/etc/postfix/virtual_alias smtpd_recipient_restrictions = reject_unauth_destination reject_unverified_recipient /etc/postfix/virtual_alias: user1@a.example user1@localhost user2@a.example user2@localhost @a.example@ms-exchange-mailserver It is also possible to marry this to virtual_mailbox_domains, but you didn't say that you were using those. Wietse You're right. I'm using virtual_mailbox_domains, virtual_mailbox_maps and virtual_alias_maps to retrieve the information about the domains and recipients from a MySQL database. I'm sorry for the long delay but I first wanted to look into the solutions suggested. I've tried Victors suggestion using check_recipient_access backend by a longish MySQL query and empty relay_recipient_maps, but I'm still unsure wheter this'd be the best solution. Best Regards, Dominik Schulz
Re: recipient_bcc_maps not working
l...@ds.gauner.org:
I've configured recipient_bcc_maps to capture outgoing mail to some
domains to debug delivery issues, i.e. some senders can't send mails to
yahoo and yahoo wants the full body. So I thought I could just capture
these mails using recipient_bcc_maps and later forward them to yahoo.
I've double checked the path and type of the maps and ran postmap after
each modicication.
The problem is that recipient_bcc_maps seems to have no effect on the
system under investigation. On other mailservers it does work very
well.
The most notable difference between this mailserver and other I have
tested is that this one uses several outgoing IPs via multiple
transports
in the master.cf and a FILTER transportX: rule in
check_recipient_access. Maybe this interferes with recipient_bcc_maps
or I've forgot something else.
Please follow instructions in the mailing list welcome message:
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
I'm sorry. Below is the information you requested. I've seen no traces in
the logs, so I've omited them for now. If you like I can supply them
later.
We are using Postfix 2.7.1 from Debian squeeze.
Below is the output from postconf -n, 'egrep -v ^#
/etc/postfix/master.cf | egrep -v ^$' and the relevant maps.
--- main.cf: ---
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
debug_peer_list = 127.0.0.1
header_checks = pcre:/etc/postfix/header-checks.pcre
inet_interfaces = all
mydestination = mailout-X, mailout-X.domain.tld, localhost
myhostname = mailout-X.domain.tld
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.0.0/16
myorigin = /etc/mailname
readme_directory = no
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_recipient_restrictions = check_recipient_access
pcre:/etc/postfix/random-recipient.pcre, check_sender_access
pcre:/etc/postfix/random-sender.pcre,
permit_mynetworks,reject_unauth_destination
smtpd_use_tls = no
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
--- end of main.cf ---
--- /etc/postfix/recipient_bcc ---
@yahoo.com archive@mailout-X
@yahoo.co.ukarchive@mailout-X
@yahoo.de archive@mailout-X
--- end of /etc/postfix/recipient_bcc ---
--- /etc/postfix/random-recipient.pcre ---
/^([a-z0-9])(.*)@(.*)/ FILTER smtpout$1:
--- end of /etc/postfix/random-recipient.pcre ---
/etc/postfix/random-sender.pcre is currently empty.
--- master.cf: ---
egrep -v ^# master.cf | egrep -v ^$
smtp inet n - - - - smtpd
pickupfifo n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgrunix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounceunix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verifyunix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
-o smtp_helo_name=HOSTNAME.DOMAIN.TLD
-o smtp_bind_address=DDD.DDD.DDD.DDD
smtpout0 unix - - - - - smtp
-o smtp_helo_name=HOSTNAME.DOMAIN.TLD
-o smtp_bind_address=DDD.DDD.DDD.DDD
[smtpout1 .. smtpout9, smtpouta ... smtpoutz with a number of diffent IPs
and helo names]
relay unix - - - - - smtp
-o smtp_fallback_relay=
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scacheunix - - - - 1 scache
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
--- end of master.cf ---
Best Regards,
Dominik Schulz
Re: Advice on filtering setup
on 02/03/2011 10:05 AM Stan Hoeppner wrote the following: Aggelos put forth on 2/2/2011 10:49 PM: on 02/03/2011 05:24 AM Aggelos wrote the following: With that setup, if I wanted to accept mail from a specific Internet IP, which would otherwise be filtered out, how would I do it? I meant clients that are rejected like so: Feb 3 06:46:59 viper postfix/smtpd[3924]: NOQUEUE: reject: RCPT from unknown[62.1.42.20]: 450 4.7.1 Client host rejected: cannot find your hostname, [62.1.42.20]; from=www-d...@insomnia.gr to=a...@vergina.dyndns.org proto=ESMTP helo=mail.insomnia.gr One possible method, using a cidr table: smtpd_recipient_restrictions = check_client_access cidr:/etc/postfix/whitelist.cidr reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unknown_client, reject_unknown_hostname, permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/client_checks, check_client_access pcre:/etc/postfix/client_checks.pcre, reject_rbl_client zen.spamhaus.org, permit /etc/postfix/whitelist.cidr 62.1.42.20permit_auth_destination Thanks. 1) Where should this be placed? Should it be first in smtpd_recipient_restrictions ? I tried it and it worked when placed just after reject_unknown_recipient_domain (before reject_unknown_client). 2) Also tried 62.1.42.20 OK in /etc/postfix/client_checks and moving check_client_access hash:/etc/postfix/client_checks as above (before reject_unknown_client) which also worked. Which one of the two is more safe?
Vacation with maildir format ?
Hello I'm migrating my mailhub. on the fly I'm converting the mailboxes format from MBOX to Maildir and I wonder how to use the vacation program ( or equivalent ) with Maiidir format ? Thanks for any infos , links ... etc.
Re: Vacation with maildir format ?
Am 03.02.2011 10:24, schrieb Frank Bonnet: Hello I'm migrating my mailhub. on the fly I'm converting the mailboxes format from MBOX to Maildir and I wonder how to use the vacation program ( or equivalent ) with Maiidir format ? Thanks for any infos , links ... etc. Hi take a look at dovecot and sieve. I think that is the most appropriate way of how to do vacation. http://wiki.dovecot.org/LDA/Sieve John
Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]
On 02/02/2011 11:54 PM, Steve Jenkins wrote: On Wed, Feb 2, 2011 at 2:33 PM, Stan Hoeppner s...@hardwarefreak.com wrote: In the mean time, maybe give this a go. 1600+ expressions matching rDNS patterns of many millions of broadband IPs worldwide that shouldn't be sending direct SMTP. Catches quite a bit that PBL/CBL/SORBS-DYNA/etc don't and with less delay, reduced load on dnsbl servers and your own network. Potential FPs will be SOHO and Linux weenie MTAs on consumer IPs. Usage instructions are comments at the top of the file. Insert the restriction above/before any greylisting daemons in main.cf, obviously. Some on this list and many on the Dovecot list can testify to its effectiveness. http://www.hardwarefreak.com/fqrdns.pcre I can attest to the awesomeness of Stan's pcre file. I run it on all 5 of our Postfix servers, and it catches a LOT of stuff. From my logs, what it seems to do best is block zombie mailers on dynamic IPs. And I updated to your latest version today, Stan. Thanks :) SteveJ Its a good idea, but this would limit a user from using a server on his residential ADSL from being an Email server, and force them to use their ISPs relay. Else they might have to upgrade to a business package or spend more money for a static IP address that they can amend the reverse lookup record for. Pros and cons.
Re: spammers getting better? help with filtering this one
On 02/03/2011 10:36 AM, Daniel Bromberg wrote: The following spam got past all my filters. They're constantly evolving :-( I can't find the IP in any RBLs. Some meta-RBLs claim it's listed, but when I follow up to the actual RBL, it's clean. I use zen.spamhaus spamcop. SpamAssassin was helpless as seen below. Those who can block this, how did you do it? I hope whatever technique(s) also help block many more like it. (We have the quoting problem. This will probably go into the junk folder of all those who are doing filtering better than I :-( ) Thanks, -Daniel Return-Path:faceb...@elgarden.pl Delivered-To: dan...@example.com Received: by smtp.EXAMPLE.com (Postfix, from userid 503) id 30AE66FC0B2; Thu, 3 Feb 2011 04:20:18 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.3.1_01 (2010-03-31) on EXAMPLE.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.8 tests=BAYES_20,HTML_MESSAGE, MIME_HTML_MOSTLY,MIME_QP_LONG_LINE,MPART_ALT_DIFF,SPF_PASS autolearn=no version=3.3.1_01 X-Greylist: delayed 00:08:22 by SQLgrey-1.8.0-rc2 Received: from s44-mail.ogicom.net (s44-mail.ogicom.net [93.157.100.68]) by smtp.EXAMPLE.com (Postfix) with ESMTP id 6727D6FC065 fordan...@example.com; Thu, 3 Feb 2011 04:20:16 -0500 (EST) Received: from s44-mail (localhost [127.0.0.1]) by s44-mail.ogicom.net (Postfix) with ESMTP id AC2699054 fordan...@example.com; Thu, 3 Feb 2011 10:11:52 +0100 (CET) Received: from uzytkown-620180 (095160093006.siedlce.vectranet.pl [95.160.93.6]) (Authenticated sender: faceb...@elgarden.pl) by s44-mail.ogicom.net (Postfix) with ESMTPA id 83248917F fordan...@example.com; Thu, 3 Feb 2011 10:11:52 +0100 (CET) Received: from rcjbmfk ([192.176.150.45]) by dblfmn (8.13.4/8.13.4) with SMTP id r50120237277724d3Hh017194 fordan...@example.com; Thu, 03 Feb 2011 10:11:52 +0100 (CDT) (envelope-from madisonlfhr...@skaharockclimbing.com) Message-ID:026c01cbc382$65762f00$065da05f@rcjbmfk From: madisonlfhr...@skaharockclimbing.commadisonlfhr...@skaharockclimbing.com To: danieldan...@example.com Subject: Hey You! kita Date: Thu, 03 Feb 2011 13:10:01 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary==_NextPart_000_0269_01CBC38A.C7150DA0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. --=_NextPart_000_0269_01CBC38A.C7150DA0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable uvqti --=_NextPart_000_0269_01CBC38A.C7150DA0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=3DContent-Type content=3Dtext/html; charset=3Dus-ascii META content=3DMSHTML 6.00.6000.15867 name=3DGENERATOR /HEAD BODY hi there!! br long time no speak ... how have you been? I am FINALLY moving right near you this weekend! Heres my info babe - brbrheres my screen names below..br AIM - ardisbelvabr MSN - cleverto...@hotmail.combr YAHOO - bestaHEWbrbr I am waiting there now! PS - dont email me back my email keeps freezing, use messenger font color=3Dwhite great purifier if we would cleanse the foulrights and duties of citizenship revwhile onehalf are still political slavesdesire the ballot this is by no means certain it canwas minister of public instruction in 1867 life for mankind our two great nations are as guides whoto go in search of him it wasi went to him and told himface full of amazement and wonder that is theat great cost and gave it to the nation it seemed to young jolyon a special peepshow ofthe other side of the fire the one really easy chairthose that open to the waist and are/font /BODY/HTML --=_NextPart_000_0269_01CBC38A.C7150DA0-- It probably evaded the spam filters because its not spam, but complete gibberish :)
Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]
On 2/3/2011 4:44 AM, J4K wrote: [snip] I can attest to the awesomeness of Stan's pcre file. I run it on all 5 of our Postfix servers, and it catches a LOT of stuff. From my logs, what it seems to do best is block zombie mailers on dynamic IPs. And I updated to your latest version today, Stan. Thanks :) SteveJ Its a good idea, but this would limit a user from using a server on his residential ADSL from being an Email server, and force them to use their ISPs relay. Good. Else they might have to upgrade to a business package or spend more money for a static IP address Even better. that they can amend the reverse lookup record for. Yes, they should be at the level where they have the right to do this. Pros and cons. No.
Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]
On 02/03/2011 10:56 AM, Daniel Bromberg wrote: On 2/3/2011 4:44 AM, J4K wrote: [snip] I can attest to the awesomeness of Stan's pcre file. I run it on all 5 of our Postfix servers, and it catches a LOT of stuff. From my logs, what it seems to do best is block zombie mailers on dynamic IPs. And I updated to your latest version today, Stan. Thanks :) SteveJ Its a good idea, but this would limit a user from using a server on his residential ADSL from being an Email server, and force them to use their ISPs relay. Good. Else they might have to upgrade to a business package or spend more money for a static IP address Even better. that they can amend the reverse lookup record for. Yes, they should be at the level where they have the right to do this. Pros and cons. No. True. Some of the matches don't reject, but prepend this header: X-GenericStaticHELO What is this header used for?
Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]
On Wed, 02 Feb 2011 18:44:46 -0600 Stan Hoeppner s...@hardwarefreak.com articulated: Jeroen Geilman put forth on 2/2/2011 2:56 PM: Debian won't have 2.8 in stable until at least 2013, although you may be able to get it as a backport later this year: http://packages.debian.org/search?keywords=postfix They lag behind something awful. You're smoke'n crack. ;) 2.7.1 was Wietse's latest stable when Debian froze the testing code base in prep for the release, which should occur within a month or so. Historically Debian has suffered from many stale packages, no argument there. But now that the backports project is an official part of Debian, this situation has become much better. BTW, I'm running backport 2.7.1. How is that lagging behind WRT to a distro package? Wietse just released 2.8 as stable a few weeks ago. Do you expect distro maintainers to have packages ready the next day? ;) FreeBSD had the 2.8 release in its ports system a few days after it was officially released. The 2.9(beta) release will be released into the ports system shortly. The original 2.8(beta) was available almost from its inception. The speed with which a package is made available to a system is directly proportionate to the amount of time and effort a maintainer wished to invest. CentOS 5.5, their latest, ships with Postfix 2.3.3, which hasn't been supported by Wietse for quite some time. A new install of CentOS 5.5 gives you an officially unsupported Postfix, thought I'm sure CentOS will support it. Now _that_ is lagging behind something awful. CentOS's support for current software is an abomination. I wonder why anyone takes it seriously. -- Jerry ✌ postfix-u...@seibercom.net _ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html 1 + 1 = 3, for large values of 1.
Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]
On Thu, 03 Feb 2011 10:44:13 +0100 J4K ju...@klunky.co.uk wrote: On 02/02/2011 11:54 PM, Steve Jenkins wrote: On Wed, Feb 2, 2011 at 2:33 PM, Stan Hoeppner s...@hardwarefreak.com wrote: In the mean time, maybe give this a go. 1600+ expressions matching rDNS patterns of many millions of broadband IPs worldwide that shouldn't be sending direct SMTP. Catches quite a bit that PBL/CBL/SORBS-DYNA/etc don't and with less delay, reduced load on dnsbl servers and your own network. Potential FPs will be SOHO and Linux weenie MTAs on consumer IPs. Usage instructions are comments at the top of the file. Insert the restriction above/before any greylisting daemons in main.cf, obviously. Some on this list and many on the Dovecot list can testify to its effectiveness. http://www.hardwarefreak.com/fqrdns.pcre I can attest to the awesomeness of Stan's pcre file. I run it on all 5 of our Postfix servers, and it catches a LOT of stuff. From my logs, what it seems to do best is block zombie mailers on dynamic IPs. And I updated to your latest version today, Stan. Thanks :) SteveJ Its a good idea, but this would limit a user from using a server on his residential ADSL from being an Email server, and force them to use their ISPs relay. Else they might have to upgrade to a business package or spend more money for a static IP address that they can amend the reverse lookup record for. Pros and cons. No cons that I can see.
Re: spammers getting better? help with filtering this one
On Thu, 03 Feb 2011 04:36:26 -0500, Daniel Bromberg dan...@basezen.com wrote: Those who can block this, how did you do it? I hope whatever technique(s) also help block many more like it. Blocked here with bogofilter (bayesian header+body filter). M.
Re: Advice on filtering setup
On 2/3/2011 3:34 AM, Aggelos wrote: on 02/03/2011 10:05 AM Stan Hoeppner wrote the following: Aggelos put forth on 2/2/2011 10:49 PM: on 02/03/2011 05:24 AM Aggelos wrote the following: With that setup, if I wanted to accept mail from a specific Internet IP, which would otherwise be filtered out, how would I do it? I meant clients that are rejected like so: Feb 3 06:46:59 viper postfix/smtpd[3924]: NOQUEUE: reject: RCPT from unknown[62.1.42.20]: 450 4.7.1 Client host rejected: cannot find your hostname, [62.1.42.20]; from=www-d...@insomnia.gr to=a...@vergina.dyndns.org proto=ESMTP helo=mail.insomnia.gr One possible method, using a cidr table: smtpd_recipient_restrictions = check_client_access cidr:/etc/postfix/whitelist.cidr reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unknown_client, reject_unknown_hostname, permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/client_checks, check_client_access pcre:/etc/postfix/client_checks.pcre, reject_rbl_client zen.spamhaus.org, permit /etc/postfix/whitelist.cidr 62.1.42.20 permit_auth_destination Thanks. 1) Where should this be placed? Should it be first in smtpd_recipient_restrictions ? I tried it and it worked when placed just after reject_unknown_recipient_domain (before reject_unknown_client). 2) Also tried 62.1.42.20OK in /etc/postfix/client_checks and moving check_client_access hash:/etc/postfix/client_checks as above (before reject_unknown_client) which also worked. Which one of the two is more safe? OK makes you an open relay for mail from that IP. It is better to use permit_auth_destination since it comes before reject_unauth_destination unless you trust that source.
multiple ssl certificates for multiple domains but just one IP
Hi, I have a server which accepts eMails for multiple Domains. And I wanna provide for each Domain a SSL certificate. How can I use SNI (Server Name Indication) with postfix or is there another way to solve this problem? Regards, alokat
Postscreen is great !
Hello Just few words to say how postscreen is great ! Thanks for that !!!
Re: multiple ssl certificates for multiple domains but just one IP
Alokat: Hi, I have a server which accepts eMails for multiple Domains. And I wanna provide for each Domain a SSL certificate. How can I use SNI (Server Name Indication) with postfix or is there another way to solve this problem? This is not yet implemented in Postfix. One option is to use nginx as a proxy. It supports multiple SSL and non-SSL server names on one IP address (http://wiki.nginx.org/HttpSslModule). Wietse
Re: Selective Relaying
On Thu, Feb 03, 2011 at 09:16:27AM +0100, l...@ds.gauner.org wrote: I've tried Victor's suggestion using check_recipient_access backend by a longish MySQL query and empty relay_recipient_maps, but I'm still unsure wheter this'd be the best solution. Using an access map instead of relay_recipient_maps, is a more flexible way of achieving the same goal. The underlying set of lookup keys is a bit different, since domains are queried without a leading @ and parent domain queries are also issued. This gives you more power and flexibility. There is nothing wrong with using access tables when your requirements are more complex. -- Viktor.
Re: multiple ssl certificates for multiple domains but just one IP
On Thu, Feb 03, 2011 at 10:30:33AM -0500, Wietse Venema wrote: Alokat: Hi, I have a server which accepts eMails for multiple Domains. And I wanna provide for each Domain a SSL certificate. How can I use SNI (Server Name Indication) with postfix or is there another way to solve this problem? This is not yet implemented in Postfix. One option is to use nginx as a proxy. It supports multiple SSL and non-SSL server names on one IP address (http://wiki.nginx.org/HttpSslModule). Are there any MUAs that send the SNI extension? Even if a server supports SNI, it does no good if none of the clients join the club. I am not aware of any MTAs that send SNI extensions, nor with all the complexities of MX records, recipient domains, flexible matching rules, ... is it at all clear which name an SMTP client (MTA) should request. For MUAs reaching a submission server, the picture is much more simple, so this is perhaps viable, but which MUAs are SNI enabled? -- Viktor.
Re: multiple ssl certificates for multiple domains but just one IP
On 02/03/2011 05:03 PM, Victor Duchovni wrote: On Thu, Feb 03, 2011 at 10:30:33AM -0500, Wietse Venema wrote: Alokat: Hi, I have a server which accepts eMails for multiple Domains. And I wanna provide for each Domain a SSL certificate. How can I use SNI (Server Name Indication) with postfix or is there another way to solve this problem? This is not yet implemented in Postfix. One option is to use nginx as a proxy. It supports multiple SSL and non-SSL server names on one IP address (http://wiki.nginx.org/HttpSslModule). Are there any MUAs that send the SNI extension? Even if a server supports SNI, it does no good if none of the clients join the club. I am not aware of any MTAs that send SNI extensions, nor with all the complexities of MX records, recipient domains, flexible matching rules, ... is it at all clear which name an SMTP client (MTA) should request. For MUAs reaching a submission server, the picture is much more simple, so this is perhaps viable, but which MUAs are SNI enabled? Okay ... thanks for all your comments. So how would you solve my problem? Multiple Instances? Regards, Alokat
Re: multiple ssl certificates for multiple domains but just one IP
On Thu, Feb 03, 2011 at 05:16:58PM +0100, Alokat wrote: For MUAs reaching a submission server, the picture is much more simple, so this is perhaps viable, but which MUAs are SNI enabled? Okay ... thanks for all your comments. So how would you solve my problem? Multiple Instances? Ideally, for an MUA, you give it a single logical name that all the submission users use. Then a single certificate is sufficient. Otherwise, you can use certificates with a subjectAltName extension that lists multiple DNS names. This works when the set of domains is stable enough to not require changes much more frequent than the typical certificate lifetime. Are the SSL certificates you want to provision in support of MUAs or peer MTAs? If MUAs, do you know whether the MUAs in fact support SNI? -- Viktor.
Re: multiple ssl certificates for multiple domains but just one IP
Am 03.02.2011 17:16, schrieb Alokat: Okay ... thanks for all your comments. So how would you solve my problem? Multiple Instances? Regards, Alokat * One Servername * One Certificate I see really no reason why not mail.yourcompany.tld using in all MX-records and client-configs, nobody needs mail.hisdomain.tld signature.asc Description: OpenPGP digital signature
Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]
On Thu, Feb 3, 2011 at 1:44 AM, J4K ju...@klunky.co.uk wrote: Its a good idea, but this would limit a user from using a server on his residential ADSL from being an Email server, and force them to use their ISPs relay. Else they might have to upgrade to a business package or spend more money for a static IP address that they can amend the reverse lookup record for. Pros and cons. It's a GREAT idea. I don't want/need email from users with ADSL or cable modem servers that refuse to use their ISP's relay. If enough of us stand firm on our mail acceptance policies to the point where we force SOHO and Linux Weenies to use their ISP's relay (which shouldn't cost them any money), then SPAMmers would take a huge hit. SteveJ
Re: Postscreen is great !
On Thu, Feb 03, 2011 at 03:31:07PM +0100, Frank Bonnet wrote: Just few words to say how postscreen is great ! Thanks for that !!! Indeed, but I'd like to add some content to this thread and ask the list as a whole: 1. What are you using for dnsbl sites and threshold? 2. Have you enabled deep protocol tests, and if so, is it as painful as greylisting? Mine's still in testing mode, but I'm impressed with results thus far. I've got these: postscreen_dnsbl_sites = zen.spamhaus.org*3 b.barracudacentral.org*2 dnsbl.njabl.org*2 bl.spameatingmonkey.net*2 bl.spamcop.net dnsbl.sorbs.net dnsbl.ahbl.org postscreen_dnsbl_threshold = 3 PREGREET is detected in lots of cases, which pretty much always end up in smtpd rejections for bad HELO. And the weighted DNSBL lookups appear to be more effective than, and probably as safe as, Zen used alone. The only drawback, which is minor from our point of view, but maybe major for the DNSBL operators, is that every connection means a hit on every DNSBL. Many of those were being blocked without any DNS lookups at all, such as the non-FQDN or non-alpha HELO. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Advice on filtering setup
on 02/03/2011 04:13 PM Brian Evans - Postfix List wrote the following: On 2/3/2011 3:34 AM, Aggelos wrote: on 02/03/2011 10:05 AM Stan Hoeppner wrote the following: Aggelos put forth on 2/2/2011 10:49 PM: on 02/03/2011 05:24 AM Aggelos wrote the following: With that setup, if I wanted to accept mail from a specific Internet IP, which would otherwise be filtered out, how would I do it? I meant clients that are rejected like so: Feb 3 06:46:59 viper postfix/smtpd[3924]: NOQUEUE: reject: RCPT from unknown[62.1.42.20]: 450 4.7.1 Client host rejected: cannot find your hostname, [62.1.42.20]; from=www-d...@insomnia.gr to=... proto=ESMTP helo=mail.insomnia.gr One possible method, using a cidr table: smtpd_recipient_restrictions = check_client_access cidr:/etc/postfix/whitelist.cidr reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unknown_client, reject_unknown_hostname, permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/client_checks, check_client_access pcre:/etc/postfix/client_checks.pcre, reject_rbl_client zen.spamhaus.org, permit /etc/postfix/whitelist.cidr 62.1.42.20 permit_auth_destination Thanks. 1) Where should this be placed? Should it be first in smtpd_recipient_restrictions ? I tried it and it worked when placed just after reject_unknown_recipient_domain (before reject_unknown_client). 2) Also tried 62.1.42.20 OK in /etc/postfix/client_checks and moving check_client_access hash:/etc/postfix/client_checks as above (before reject_unknown_client) which also worked. Which one of the two is more safe? OK makes you an open relay for mail from that IP. It is better to use permit_auth_destination since it comes before reject_unauth_destination unless you trust that source. Thanks a lot! I don't trust any external source. So I had better use the permit_auth_destination as suggested by Stan in the first place.
Re: Postfix with virtual domains and the username
On 03.02.2011 00:27, wrote Matt: On Wed, Feb 2, 2011 at 5:31 PM, Mauricio Tavares raubvo...@gmail.com wrote: On Wed, Feb 2, 2011 at 5:10 PM, Matt mhop...@gmail.com wrote: I'm working on replacing an ageing Posfix install with a new server. On the old and new server we use virtual domains. On the old server we login with: username.domain.com On the new server Postfix is configured to allow login as: usern...@domain.com I'd actually rather prefer the new format, however, for ease of transition is there a way I can configure Postfix to allow the . and even better yet, to allow either? What are you using to do the authentication? And, when you mean logging in do you mean to check mail (IMAP/POP3) or to send mail (SMTP AUTH)? I am using dovecot. I mean IMAP/POP3 and SMTP. It's really not a big deal if I need to use the @ sign, I just figured if I could do both it would ease the transition. Maybe this helps: http://wiki1.dovecot.org/MainConfig?highlight=(auth_username_translation)
Re: Postscreen is great !
On 2/3/2011 11:53 AM, /dev/rob0 wrote: On Thu, Feb 03, 2011 at 03:31:07PM +0100, Frank Bonnet wrote: Just few words to say how postscreen is great ! Thanks for that !!! Indeed, but I'd like to add some content to this thread and ask the list as a whole: 1. What are you using for dnsbl sites and threshold? 2. Have you enabled deep protocol tests, and if so, is it as painful as greylisting? Mine's still in testing mode, but I'm impressed with results thus far. I've got these: postscreen_dnsbl_sites = zen.spamhaus.org*3 b.barracudacentral.org*2 dnsbl.njabl.org*2 bl.spameatingmonkey.net*2 bl.spamcop.net dnsbl.sorbs.net dnsbl.ahbl.org list.dnswl.org*-5 hostkarma.junkemailfilter.com=127.0.0.1*-5 postscreen_dnsbl_threshold = 3 PREGREET is detected in lots of cases, which pretty much always end up in smtpd rejections for bad HELO. And the weighted DNSBL lookups appear to be more effective than, and probably as safe as, Zen used alone. The only drawback, which is minor from our point of view, but maybe major for the DNSBL operators, is that every connection means a hit on every DNSBL. Many of those were being blocked without any DNS lookups at all, such as the non-FQDN or non-alpha HELO.
Re: recipient_bcc_maps not working
On 2/3/11 9:18 AM, l...@ds.gauner.org wrote: l...@ds.gauner.org: I've configured recipient_bcc_maps to capture outgoing mail to some domains to debug delivery issues, i.e. some senders can't send mails to yahoo and yahoo wants the full body. So I thought I could just capture these mails using recipient_bcc_maps and later forward them to yahoo. I've double checked the path and type of the maps and ran postmap after each modicication. The problem is that recipient_bcc_maps seems to have no effect on the system under investigation. On other mailservers it does work very well. The most notable difference between this mailserver and other I have tested is that this one uses several outgoing IPs via multiple transports in the master.cf and a FILTER transportX: rule in check_recipient_access. Maybe this interferes with recipient_bcc_maps or I've forgot something else. Please follow instructions in the mailing list welcome message: TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail I'm sorry. Below is the information you requested. I've seen no traces in the logs, so I've omited them for now. Sadly, the LOGS are the most essential part of the information you could provide. Be sure to include as much of one or two messages as possible, from the point they enter the postfix system until they exit. If you like I can supply them later. We are using Postfix 2.7.1 from Debian squeeze. Below is the output from postconf -n, 'egrep -v ^# /etc/postfix/master.cf | egrep -v ^$' and the relevant maps. --- main.cf: --- alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no config_directory = /etc/postfix debug_peer_list = 127.0.0.1 header_checks = pcre:/etc/postfix/header-checks.pcre inet_interfaces = all mydestination = mailout-X, mailout-X.domain.tld, localhost myhostname = mailout-X.domain.tld mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.0.0/16 myorigin = /etc/mailname readme_directory = no smtpd_banner = $myhostname ESMTP $mail_name smtpd_recipient_restrictions = check_recipient_access pcre:/etc/postfix/random-recipient.pcre, check_sender_access pcre:/etc/postfix/random-sender.pcre, permit_mynetworks,reject_unauth_destination smtpd_use_tls = no recipient_bcc_maps = hash:/etc/postfix/recipient_bcc --- end of main.cf --- --- /etc/postfix/recipient_bcc --- @yahoo.com archive@mailout-X @yahoo.co.ukarchive@mailout-X @yahoo.de archive@mailout-X --- end of /etc/postfix/recipient_bcc --- --- /etc/postfix/random-recipient.pcre --- /^([a-z0-9])(.*)@(.*)/ FILTER smtpout$1: This seems unfortunate. Dividing work over multiple files/directories/processes usually works best when you start at the most-significant end of the data, but email addresses aren't divided evenly across the possibilities. The first letter of email addresses will follow the normal incidence of letter occurence, with a strong bias towards e, r, s, n etc (in English, anyway). A number as the first character of an address will be rare verging on non-occurring; this means up to 25% of these outputs will be used less than 1% of the time, making it an unbalanced load balancing mechanism. I would look into some sort of hashing method instead. -- J.
Postscreen + SenderBase
Did anyone have tips to integrate PostScreen with SenderBase DNSBL has the Cisco IronMail blacklist ? Bestr regards
Re: multiple ssl certificates for multiple domains but just one IP
On Thu, 03 Feb 2011 08:16:58 -0800, Alokat mail...@alokat.org wrote: On 02/03/2011 05:03 PM, Victor Duchovni wrote: On Thu, Feb 03, 2011 at 10:30:33AM -0500, Wietse Venema wrote: Alokat: Hi, I have a server which accepts eMails for multiple Domains. And I wanna provide for each Domain a SSL certificate. How can I use SNI (Server Name Indication) with postfix or is there another way to solve this problem? This is not yet implemented in Postfix. One option is to use nginx as a proxy. It supports multiple SSL and non-SSL server names on one IP address (http://wiki.nginx.org/HttpSslModule). Are there any MUAs that send the SNI extension? Even if a server supports SNI, it does no good if none of the clients join the club. I am not aware of any MTAs that send SNI extensions, nor with all the complexities of MX records, recipient domains, flexible matching rules, ... is it at all clear which name an SMTP client (MTA) should request. For MUAs reaching a submission server, the picture is much more simple, so this is perhaps viable, but which MUAs are SNI enabled? Okay ... thanks for all your comments. So how would you solve my problem? Multiple Instances? Regards, Alokat You can get a multi-domain SSL certificate. It is one certificate that lists all the domains for which it is valid. -- Chris
Re: multiple ssl certificates for multiple domains but just one IP
Am 03.02.2011 20:05, schrieb Chris Tandiono: You can get a multi-domain SSL certificate. It is one certificate that lists all the domains for which it is valid. in theory xes but this is not scaleable If you get 3 new customers with their own domains you cert does not include them and you need a workaround using mail.yourcompany.tld So why not simply use mail.yourcompany.tld as the only MX and smtp/imap/pop3 in the clients configuration? AFAIK this is a problem that does not exist in the real world We are hosting 200 mail domains and there is one hostname and one certificate for all of them signature.asc Description: OpenPGP digital signature
Delivering Mail with priority based on domain
Hi, I have been reading about prioritizing mail in Postfix on this list. It seems that the answer is, there is a shared queue and mail is not prioritized. I want to make sure that I fully understand if this applies to my situation. All of our servers that send mail go through our Postfix gateways. I don't want to manage our exchange server as a relay. I find that when we send out a lot of email and there is mail queued, internal mail is delayed. I'm assuming the short term solution to this is: postqueue -s domain.com Is there another way to prioritize internal mail delivery based on domain? Postfix-2.3.3-2.1.el5_2 running on CentOS 5.5 x64 Thanks, James
Re: Delivering Mail with priority based on domain
On 02/03/2011 11:24 AM, James R. Marcus wrote: Hi, I have been reading about prioritizing mail in Postfix on this list. It seems that the answer is, there is a shared queue and mail is not prioritized. I want to make sure that I fully understand if this applies to my situation. All of our servers that send mail go through our Postfix gateways. I don't want to manage our exchange server as a relay. I find that when we send out a lot of email and there is mail queued, internal mail is delayed. I'm assuming the short term solution to this is: postqueue -s domain.com Is there another way to prioritize internal mail delivery based on domain? Postfix-2.3.3-2.1.el5_2 running on CentOS 5.5 x64 One huge improvement you can make is to specify the relay transport for incoming mail. That will create a separate queue from the outgoing mail which is using the smtp transport, and will greatly lesses the impact of a large outgoing queue on incoming mail. You can expand upon this theme as appropriate. BTW there are postfix-2.7 and 2.8 rpms available for Centos - 2.3.3 is ancient and lacking in all of the useful features added since 2003 or so, you'd be doing yourself a big favor to bring your postfix up to date. Joe
Re: Postscreen is great !
On 2/3/2011 11:53 AM, /dev/rob0 wrote: On Thu, Feb 03, 2011 at 03:31:07PM +0100, Frank Bonnet wrote: Just few words to say how postscreen is great ! The only drawback, which is minor from our point of view, but maybe major for the DNSBL operators, is that every connection means a hit on every DNSBL. Many of those were being blocked without any DNS lookups at all, such as the non-FQDN or non-alpha HELO. I was wondering about this also. Under the old setup I was seeing fewer request to the DNSBLs since zen and other checks were stopping the message first. When setup with prescreen, it's not checking known good clients on every connect, but checking all DNSBLs for new/bad connects. I would still expect the number of DNSBL queries to go down, but on my system I'm seeing an increase. Maybe they will start going down as more hosts are added to the white lists. -Matt smime.p7s Description: S/MIME Cryptographic Signature
Re: Postscreen + SenderBase
* David Touzeau da...@touzeau.eu: Did anyone have tips to integrate PostScreen with SenderBase DNSBL has the Cisco IronMail blacklist ? Please rephrase and please do mention how one would query the SenderBase DNSBL! -- 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
Re: message tracking logging request
On 2/2/11 12:20 AM, Matthias Andree wrote: Postfix logs the ID whenever one is available, and it did in your case. I'm wondering what exactly you seem to be missing. If it's about the client connection as logged by postfix/smtpd, then it has no connection to individual messages, hence doesn't have IDs associated. That's why I suggested a connection id be assigned then, and the message id be that with a per-message suffix. This would allow one to find messages relating to connections, say if there's an ip blacklist going on. When someone reports a problem with mail from a given server, I can grep for the ip address of the server, then re-grep for the connection ids associated with that address and get everything that was ever logged about mail from that server. smime.p7s Description: S/MIME Cryptographic Signature
Re: message tracking logging request
Am 03.02.2011 20:41, schrieb Alan Batie: On 2/2/11 12:20 AM, Matthias Andree wrote: Postfix logs the ID whenever one is available, and it did in your case. I'm wondering what exactly you seem to be missing. If it's about the client connection as logged by postfix/smtpd, then it has no connection to individual messages, hence doesn't have IDs associated. That's why I suggested a connection id be assigned then, and the message id be that with a per-message suffix. This would allow one to find messages relating to connections, say if there's an ip blacklist going on. When someone reports a problem with mail from a given server, I can grep for the ip address of the server, then re-grep for the connection ids associated with that address and get everything that was ever logged about mail from that server. what is the benefit? connection id = one id for each connection so hwat would be the difference grep the ip oder id? signature.asc Description: OpenPGP digital signature
Re: Postscreen is great !
Matt Rude: On 2/3/2011 11:53 AM, /dev/rob0 wrote: On Thu, Feb 03, 2011 at 03:31:07PM +0100, Frank Bonnet wrote: Just few words to say how postscreen is great ! The only drawback, which is minor from our point of view, but maybe major for the DNSBL operators, is that every connection means a hit on every DNSBL. Many of those were being blocked without any DNS lookups at all, such as the non-FQDN or non-alpha HELO. I was wondering about this also. Under the old setup I was seeing fewer request to the DNSBLs since zen and other checks were stopping the message first. When setup with prescreen, it's not checking known good clients on every connect, but checking all DNSBLs for new/bad connects. I would still expect the number of DNSBL queries to go down, but on my system I'm seeing an increase. Maybe they will start going down as more hosts are added to the white lists. You could try to increase postscreen_dnsbl_ttl from its default 1h; that will reduce the number of DNS lookups for dynamically-whitelisted clients. I've set the default on the low side, so it can catch spamware before (smtpd) greylist deadline expires. Wietse
Re: Postscreen is great !
On Thu, 03 Feb 2011 12:52:47 -0600, Noel Jones njo...@megan.vbhcs.org wrote: list.dnswl.org*-5 this includes dnswl_none just a note hostkarma.junkemailfilter.com=127.0.0.1*-5 super that its is supported, still missing rhsbl in postscreen ?
Re: Postscreen is great !
Benny Pedersen: On Thu, 03 Feb 2011 12:52:47 -0600, Noel Jones njo...@megan.vbhcs.org wrote: list.dnswl.org*-5 this includes dnswl_none just a note hostkarma.junkemailfilter.com=127.0.0.1*-5 super that its is supported, still missing rhsbl in postscreen ? There is not yet a user interface design for rhsbl in postscreen. Suggestions are welcome. Wietse
Re: Postscreen is great !
On Thu, Feb 03, 2011 at 03:01:56PM -0500, Wietse Venema wrote: Benny Pedersen: super that its is supported, still missing rhsbl in postscreen ? There is not yet a user interface design for rhsbl in postscreen. Suggestions are welcome. I don't see how it would be useful. The only thing available to lookup at this stage is the client PTR (and verify that), right? Since the design goal is to keep it fast and minimal, I'd say, no need for RHSBL in postscreen. smtpd gets to look up the HELO and sender and recipient, as well as the client PTR. That's where RHSBL makes most sense, in smtpd. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Postscreen is great !
/dev/rob0: On Thu, Feb 03, 2011 at 03:01:56PM -0500, Wietse Venema wrote: Benny Pedersen: super that its is supported, still missing rhsbl in postscreen ? There is not yet a user interface design for rhsbl in postscreen. Suggestions are welcome. I don't see how it would be useful. The only thing available to lookup at this stage is the client PTR (and verify that), right? Since the design goal is to keep it fast and minimal, I'd say, no need for RHSBL in postscreen. When the after 220 greeting tests are enabled, also known as deep protocol tests, then the client can be rhsbl blocked based on their helo/sender/recipient information. This would be a late check of the client intentions. These after 220 greeting tests are not as painful as some greylisting implementations, because positive results have a long TTL of 30 days by default. I remember some greylisters have pretty narrow time windows. Otherwise, postscreen's after 220 greeting tests add just one more step to the greylisting delays. If a client is not willing to connect three times, that may be a problem for some, but it is not a problem for me. Wietse smtpd gets to look up the HELO and sender and recipient, as well as the client PTR. That's where RHSBL makes most sense, in smtpd. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Postscreen + SenderBase
Sorry, I rephrase How can we set PostScreen to query SenderBase DNBSL ? Best regards Le jeudi 03 février 2011 à 20:37 +0100, Ralf Hildebrandt a écrit : * David Touzeau da...@touzeau.eu: Did anyone have tips to integrate PostScreen with SenderBase DNSBL has the Cisco IronMail blacklist ? Please rephrase and please do mention how one would query the SenderBase DNSBL!
Re: Delivering Mail with priority based on domain
On 2/3/11 8:31 PM, Joe wrote: On 02/03/2011 11:24 AM, James R. Marcus wrote: Hi, I have been reading about prioritizing mail in Postfix on this list. It seems that the answer is, there is a shared queue and mail is not prioritized. I want to make sure that I fully understand if this applies to my situation. All of our servers that send mail go through our Postfix gateways. I don't want to manage our exchange server as a relay. I find that when we send out a lot of email and there is mail queued, internal mail is delayed. I'm assuming the short term solution to this is: postqueue -s domain.com Is there another way to prioritize internal mail delivery based on domain? Postfix-2.3.3-2.1.el5_2 running on CentOS 5.5 x64 One huge improvement you can make is to specify the relay transport for incoming mail. To achieve what ? That will create a separate queue from the outgoing mail which is using the smtp transport, There is one queue. The qmgr(8) does not make priority or precedence decisions based on the transport:nexthop information of queued mail; all eligible mail is processed ASAP (in the incoming and active queues) or when its time is up (in the deferred queue). If you want to prioritize mail, you can create a separate postfix instance with postmulti(1) so there really will be 2 queues. These can then process and deliver mail bound for specific destinations - internal vs. external, for instance. Their queue performance will still depend largely on your disk I/O subsystem's capabilities, but the qmgr(8) itself will no longer be the bottleneck for internal mail vs. the slower-moving external mail, because there will be two of them, each able to fully utilize a single CPU. Based on your post, however, the disk I/O subsystem is most likely the bottleneck for you. Of course, another logical solution is to just set up a different machine to handle internal mail, thereby completely bypassing the bottleneck. Personally, I would set up a mail destination for the entire network (optionally load-balanced), which has the resources to at least decide what to do with all mail, and can then hand off internal mail to an internal mail store and/or back to the exchange servers, and hand off outgoing mail to dedicated SMTP senders that do nothing else. If you separate all auxiliary functions from the core routing, the core routing can be very fast; of course, you would have to scale the queue subsystem to match. -- J.
Re: Postscreen + SenderBase
On 2/4/11 12:33 AM, David Touzeau wrote: Sorry, I rephrase How can we set PostScreen to query SenderBase DNBSL ? Best regards Le jeudi 03 février 2011 à 20:37 +0100, Ralf Hildebrandt a écrit : * David Touzeauda...@touzeau.eu mailto:da...@touzeau.eu: Did anyone have tips to integrate PostScreen with SenderBase DNSBL has the Cisco IronMail blacklist ? Please rephrase and please do mention how one would query the SenderBase DNSBL! I think Ralph meant: do you have an example how one would query this DNSBL ? Postfix has native support for querying DNS A-record-based blacklists; if this one uses a different query mechanism, it is unlikely that postfix can natively support it. If it uses the common query method, just add it to your list of DNSBLs. Have you tried using it ? -- J.
Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]
On 2/3/11 1:44 AM, Stan Hoeppner wrote: Jeroen Geilman put forth on 2/2/2011 2:56 PM: Debian won't have 2.8 in stable until at least 2013, although you may be able to get it as a backport later this year: http://packages.debian.org/search?keywords=postfix They lag behind something awful. You're smoke'n crack. ;) That stuff is expensive! 2.7.1 was Wietse's latest stable when Debian froze the testing code base in prep for the release, which should occur within a month or so. Historically Debian has suffered from many stale packages, no argument there. But now that the backports project is an official part of Debian, See, I did not know this. Last I used Debian-pure (instead of Ubuntu), you had to mess with unstable to get up-to-date packages. this situation has become much better. BTW, I'm running backport 2.7.1. How is that lagging behind WRT to a distro package? Wietse just released 2.8 as stable a few weeks ago. Do you expect distro maintainers to have packages ready the next day? ;) I'm prepared to give them a week ;) CentOS 5.5, their latest, ships with Postfix 2.3.3, which hasn't been supported by Wietse for quite some time. A new install of CentOS 5.5 gives you an officially unsupported Postfix, thought I'm sure CentOS will support it. Now _that_ is lagging behind something awful. Awfulness is had, somehow. -- J.
Re: Delivering Mail with priority based on domain
On 02/03/2011 03:51 PM, Jeroen Geilman wrote: On 2/3/11 8:31 PM, Joe wrote: On 02/03/2011 11:24 AM, James R. Marcus wrote: Hi, I have been reading about prioritizing mail in Postfix on this list. It seems that the answer is, there is a shared queue and mail is not prioritized. I want to make sure that I fully understand if this applies to my situation. All of our servers that send mail go through our Postfix gateways. I don't want to manage our exchange server as a relay. I find that when we send out a lot of email and there is mail queued, internal mail is delayed. I'm assuming the short term solution to this is: postqueue -s domain.com Is there another way to prioritize internal mail delivery based on domain? Postfix-2.3.3-2.1.el5_2 running on CentOS 5.5 x64 One huge improvement you can make is to specify the relay transport for incoming mail. To achieve what ? To minimize the impact of large outbound queue on incoming message delivery latency. That will create a separate queue from the outgoing mail which is using the smtp transport, There is one queue. I might not have used the best term queue but the concept is still correct. the queue manager implements fairness between transports, so if incoming and outgoing mail are on two different transports it will help a lot. Our incoming messages used to be delayed quite a bit when the outbound queue grew to the tens of thousands. When we assigned incoming messages to the relay transport, distinct from the default smtp transport used for outgoing messages, we stopped seeing any problems with inbound message delays even with huge numbers of queued outgoing messages. There are certainly cases for multiple postfix instances, but I wouldn't assume that this scenario necessarily calls for such a measure. I'd try the separate transport first, and see how it works. You may not have to do anything else. You can always add multiple instances later if that's really what you want to do. There are other parameters I would look at, before running multiple instances - maximal_queue_lifetime, maximal_backoff_time, the process limits in master.cf are all worth looking at. Joe
Re: Postscreen is great !
On 2/3/2011 1:59 PM, Benny Pedersen wrote: On Thu, 03 Feb 2011 12:52:47 -0600, Noel Jonesnjo...@megan.vbhcs.org wrote: list.dnswl.org*-5 this includes dnswl_none just a note I intentionally don't want to RBL block sometimes-legit hosts. To only whitelist low..high trusted hosts, something like: list.dnswl.org=127.0.[0..255].[1..3]*-5 hostkarma.junkemailfilter.com=127.0.0.1*-5 super that its is supported, still missing rhsbl in postscreen ? I suppose rhsbl could be added in the tests after the SMTP greeting, but it's not clear to me that this would be widely useful. -- Noel Jones
Re: Delivering Mail with priority based on domain
Jeroen Geilman: [ Charset UTF-8 unsupported, converting... ] On 2/3/11 8:31 PM, Joe wrote: On 02/03/2011 11:24 AM, James R. Marcus wrote: Hi, I have been reading about prioritizing mail in Postfix on this list. It seems that the answer is, there is a shared queue and mail is not prioritized. I want to make sure that I fully understand if this applies to my situation. All of our servers that send mail go through our Postfix gateways. I don't want to manage our exchange server as a relay. I find that when we send out a lot of email and there is mail queued, internal mail is delayed. I'm assuming the short term solution to this is: postqueue -s domain.com Is there another way to prioritize internal mail delivery based on domain? Postfix-2.3.3-2.1.el5_2 running on CentOS 5.5 x64 One huge improvement you can make is to specify the relay transport for incoming mail. To achieve what ? Postfix has separate smtp and relay transports for a good reason. The scheduler uses round-robin destination selection. This improves fairness in the general case, but it bites when you have lots of mail going to one place, typically, from internet to inside mailhost. In that case it is better to separate inbound (relay) mail from outbound (smtp) mail, otherwise inbound deliveries suffer from competition by outbound deliveries. Wietse
Re: Delivering Mail with priority based on domain
On 2/4/11 1:25 AM, Wietse Venema wrote: Jeroen Geilman: [ Charset UTF-8 unsupported, converting... ] Oops... Bad Thunderbird. On 2/3/11 8:31 PM, Joe wrote: On 02/03/2011 11:24 AM, James R. Marcus wrote: Hi, I have been reading about prioritizing mail in Postfix on this list. It seems that the answer is, there is a shared queue and mail is not prioritized. I want to make sure that I fully understand if this applies to my situation. All of our servers that send mail go through our Postfix gateways. I don't want to manage our exchange server as a relay. I find that when we send out a lot of email and there is mail queued, internal mail is delayed. I'm assuming the short term solution to this is: postqueue -s domain.com Is there another way to prioritize internal mail delivery based on domain? Postfix-2.3.3-2.1.el5_2 running on CentOS 5.5 x64 One huge improvement you can make is to specify the relay transport for incoming mail. To achieve what ? Postfix has separate smtp and relay transports for a good reason. The scheduler uses round-robin destination selection. Does this mean recipient domain or transport ? The qmgr(8) page doesn't say, and I have learned not to take these things for granted. This improves fairness in the general case, but it bites when you have lots of mail going to one place, typically, from internet to inside mailhost. In that case it is better to separate inbound (relay) mail from outbound (smtp) mail, otherwise inbound deliveries suffer from competition by outbound deliveries. How does this work ? I was under the impression that delivery is balanced between destination nexthops (as present in the queued message), not between transports. Or is it BOTH ? -- J.
Re: Delivering Mail with priority based on domain
Jeroen Geilman: One huge improvement you can make is to specify the relay transport for incoming mail. To achieve what ? Postfix has separate smtp and relay transports for a good reason. The scheduler uses round-robin destination selection. Does this mean recipient domain or transport ? The next-hop destination. This improves fairness in the general case, but it bites when you have lots of mail going to one place, typically, from internet to inside mailhost. In that case it is better to separate inbound (relay) mail from outbound (smtp) mail, otherwise inbound deliveries suffer from competition by outbound deliveries. How does this work ? I was under the impression that delivery is balanced between destination nexthops (as present in the queued message), not between transports. Or is it BOTH ? Each transport (relay, smtp, local, etc.) has its own round-robin scheduler. All schedulers share the active queue. Wietse
Re: Delivering Mail with priority based on domain
On 2/4/11 3:38 AM, Wietse Venema wrote: Jeroen Geilman: One huge improvement you can make is to specify the relay transport for incoming mail. To achieve what ? Postfix has separate smtp and relay transports for a good reason. The scheduler uses round-robin destination selection. Does this mean recipient domain or transport ? The next-hop destination. This improves fairness in the general case, but it bites when you have lots of mail going to one place, typically, from internet to inside mailhost. In that case it is better to separate inbound (relay) mail from outbound (smtp) mail, otherwise inbound deliveries suffer from competition by outbound deliveries. How does this work ? I was under the impression that delivery is balanced between destination nexthops (as present in the queued message), not between transports. Or is it BOTH ? Each transport (relay, smtp, local, etc.) has its own round-robin scheduler. All schedulers share the active queue. Wietse Thanks for the clarification; I can test this with smtpsource to see the behaviour. -- J.
Re: spammers getting better? help with filtering this one
Daniel Bromberg put forth on 2/3/2011 3:36 AM: The following spam got past all my filters. They're constantly evolving :-( I can't find the IP in any RBLs. Some meta-RBLs claim it's listed, but when I follow up to the actual RBL, it's clean. I use zen.spamhaus spamcop. SpamAssassin was helpless as seen below. Those who can block this, how did you do it? I hope whatever technique(s) also help block many more like it. (We have the quoting problem. This will probably go into the junk folder of all those who are doing filtering better than I :-( ) Blocking spam from compromised accounts is difficult. Best thing to do is report the spam to the provider: ad...@ogicom.pl If your MX is being flooded by such spam, simply block the IP (or parent network) of the IPs that are sending the spam. In this case, if you have no need to receive email from Poland, ever, then simply cidr ban the entire country using ipdeny.com information. If you don't want to ban the entire country, maybe just start with Ogicom's 93.157.96.0/21 There is no single magic bullet that will stop all spam. You must use a diverse set of tools. -- Stan
Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]
J4K put forth on 2/3/2011 3:44 AM: Its a good idea, but this would limit a user from using a server on his residential ADSL from being an Email server, As the directions in the file itself state, fix situations like this with a simple whitelist. Given the number of hobbyist servers your MX will receive mail from, the whitelist will be very small and easily manageable. The ratio of hobbyist MTAs to spambots on a given residential subnet is going to be something like 1:5,000 give or take. The math speaks in favor of blocking the spambots and whitelisting the hobby MTAs. -- Stan
Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]
J4K put forth on 2/3/2011 4:09 AM: True. Some of the matches don't reject, but prepend this header: X-GenericStaticHELO What is this header used for? This exists due to the grey area between residential and business classification. Some providers offer static IP service to small businesses over cable/xDSL but don't offer custom rDNS. We don't block on these rDNS patterns outright because the probability is sufficiently high that the client MTA is legit vs a spambot. You, the OP, can use this header for scoring in a content filter such as SA. Note that you can change this header string to whatever you choose. You can also change the PREPEND to REJECT if you so choose. Modify the file/expressions any way you see fit to meet your needs. -- Stan
Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]
Jerry put forth on 2/3/2011 5:19 AM: FreeBSD had the 2.8 release in its ports system a few days after it was officially released. The 2.9(beta) release will be released into the ports system shortly. The original 2.8(beta) was available almost from its inception. The speed with which a package is made available to a system is directly proportionate to the amount of time and effort a maintainer wished to invest. Well, I think there's a bit more to it than that. Some distros have various policies in place that hinder rapid inclusion. That said, if Sahil were associated with the Debian project instead of or in addition to FreeBSD, we'd probably see current Postfix backports in Debian more quickly. :) CentOS 5.5, their latest, ships with Postfix 2.3.3, which hasn't been supported by Wietse for quite some time. A new install of CentOS 5.5 gives you an officially unsupported Postfix, thought I'm sure CentOS will support it. Now _that_ is lagging behind something awful. CentOS's support for current software is an abomination. I wonder why anyone takes it seriously. I've pondered this myself, and the conclusion I come to is that they are ignorant newbs who are enamored with the free version of Red Hat Enterprise Linux. They look at the price tag of RHEL and think they're getting something good for nothing. They just don't realize RHEL is not good and is years behind current, and that CentOS is months to years behind RHEL. I think I summed it up best when I stated CentOS uses an outdated distribution as their upstream source. -- Stan
Re: Delivering Mail with priority based on domain
On Fri, Feb 04, 2011 at 12:51:36AM +0100, Jeroen Geilman wrote: That will create a separate queue from the outgoing mail which is using the smtp transport, There is one queue. Physically, yes. Logically, and this is what matters more: no. Each transport has a separate pool of delivery agent processes transports are scheduled in parallel (well, round-robin, but unless the queue manager is disk-I/O starved, transport allocation is very fast, delay is caused by lack of delivery agents or per-transport, per-nexthop concurrency limits). So the comment about one queue is mostly wrong, and the previous post is essentially correct. -- Viktor.
Re: Question about: postfix/smtpd[ ]: connect from unknown[unknown]
Steve Jenkins put forth on 2/3/2011 11:18 AM: On Thu, Feb 3, 2011 at 1:44 AM, J4K ju...@klunky.co.uk wrote: Its a good idea, but this would limit a user from using a server on his residential ADSL from being an Email server, and force them to use their ISPs relay. Else they might have to upgrade to a business package or spend more money for a static IP address that they can amend the reverse lookup record for. Pros and cons. It's a GREAT idea. I don't want/need email from users with ADSL or cable modem servers that refuse to use their ISP's relay. If enough of us stand firm on our mail acceptance policies to the point where we force SOHO and Linux Weenies to use their ISP's relay (which shouldn't cost them any money), then SPAMmers would take a huge hit. Unfortunately the situation isn't quite that simple. Note the explanation I gave for the header prepending. There are ISPs who only offer xDSL to business clients, with static IPs, but without custom rDNS, and they don't want these business clients relaying through their MSAs. Most are going to run their own MX MTA anyway. We don't want to be throwing these babies out with the bath water, nor the hobbyists. We're fighting spammers. The battle that needs to be fought is getting all ISPs to implement TCP 25 outbound filtering across the board for residential lines, and only opening it upon request. Some already do this in the states, but relatively few. That's the better way to solve the spambot/zombie problem, not penalizing one or two segments of ISP customers simply because they're on a residential class broadband line. If a hobbyist knows how to run an MTA properly, and wants to send/receive directly, we should not discourage that. And we shouldn't be penalizing SOHOs doing the same. Remember, we're fighting spam, not innocent bystanders who simply have the same connectivity a bot infected PC sits behind. -- Stan
Re: Postscreen + SenderBase
Jeroen Geilman put forth on 2/3/2011 5:55 PM: If it uses the common query method, just add it to your list of DNSBLs. from: http://spamlinks.net/filter-dnsbl-lists.htm query.senderbase.orgSENDERBASE ... Returns TXT records Not suitable for direct Postfix use. I manually dug a few bad and good (Senderbase' own reputation) IPs into it and got nothing in return, no TXT records, nut'n, with neither forward or reversed IP notation. -- Stan
Re: Vacation with maildir format ?
Le 03/02/2011 10:24, Frank Bonnet a écrit : Hello I'm migrating my mailhub. on the fly I'm converting the mailboxes format from MBOX to Maildir and I wonder how to use the vacation program ( or equivalent ) with Maiidir format ? vacation has nothing to do with the storage. Thanks for any infos , links ... etc.
Re: Order of restrictions
Le 02/02/2011 21:25, Noel Jones a écrit : On 2/2/2011 1:48 PM, mouss wrote: Le 02/02/2011 19:28, Steve Jenkins a écrit : smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_client_access pcre:/etc/postfix/fqrdns.pcre, reject_unknown_reverse_client_hostname, warn_if_reject reject_non_fqdn_helo_hostname, warn_if_reject reject_invalid_helo_hostname, warn_if_reject reject_unknown_helo_hostname, reject_unknown_helo_hostname implies a dns query. do you really want it here? (do you need it at all!). also, be careful with warn_if_reject. postfix caches the results of checks. so if you use say reject_invalid_helo_hostname later (for example as the result of one of your check_*_acces), then it will only warn. No, warn_if_reject only applies to the next restriction, not to subsequent restrictions even if it's a repeat. I had the impression that postfix used to cache the result and use it even if it's a warn. but now I tested and this doesn't match reality. not sure if it's something of the past or if my memory plays bad games...
