Re: Integration of content filter in master.cf
Tue, 08 Jan 2013 16:24:11 -0600 skrev Noel Jones njo...@megan.vbhcs.org: On 1/8/2013 4:11 PM, Titanus Eramius wrote: I've had some trouble seeing the difference between -o overrides in main.cf and master.cf, but this really helps. main.cf parameters are used by all postfix services (but not all parameters apply to all services). Individual services defined in master.cf can override main.cf settings with -o ... options. http://www.postfix.org/postconf.5.html http://www.postfix.org/master.5.html -- Noel Jones Sorry for the delayed answer, it took some time to adjust the server to match the advices I got, but everything seems to run better than ever, so thanks for the help again. Some day one really ought to read the entire postconf(5) manual to get a sense of what Postfix is capable of, but so far I've only read about the settings I use. If I may ask one last thing, just to be sure. To integrate SpamAssassin I adjusted the smtp-line in master.cf to --- smtp inet n - - - - smtpd -o content_filter=spamassassin --- and then disallowed submission on port 25. In main.cf I have 7 reject_*-lines like so --- smtpd_recipient_restrictions = ... reject_invalid_helo_hostname reject_unknown_sender_domain ... permit --- Will the reject_*-rules still apply to incoming mail before Postfix hands it over to SpamAssassin?
Re: Integration of content filter in master.cf
Tue, 08 Jan 2013 23:59:31 +0100 skrev mouss mo...@ml.netoyen.net: This raises the question (or at least I think it do), if it's possible to force the users onto 587 by denying relay access to 25? fix the problem at the source: force the client to do the work: use different services for different uses: [MX service] port: 25 example DNS name: mx01.example.com = no relay virus and spam filtering... [submission service] example DNS name: smtp01.example.com port 587. if this is hard, port 25 with a specific IP is ok. SASL auth. when not desirable, IP based access control (thoug this may be implemented outside of postfix, such as on a firewall) virus filtering rate limit and custom checks as needed. [reverse MX] example DNS name: mailrelay01.example.com in small setups, this could be the same service as the submission one. in larger setups, make this dedicated. it'll take the complexity of mail routing and caching (retry). ... Thank you for the insights, together with a subdomain to the Dovecot IMAP service they have all been implemented so I later may split the services to multiple servers. However I'm not sure I understand the reverse MX part very well, perhaps I could trouble you for a link where I could do some reading on the subject?
Re: Integration of content filter in master.cf
On 1/16/2013 3:13 AM, Titanus Eramius wrote: Tue, 08 Jan 2013 16:24:11 -0600 skrev Noel Jones njo...@megan.vbhcs.org: main.cf parameters are used by all postfix services (but not all parameters apply to all services). Individual services defined in master.cf can override main.cf settings with -o ... options. http://www.postfix.org/postconf.5.html http://www.postfix.org/master.5.html -- Noel Jones If I may ask one last thing, just to be sure. To integrate SpamAssassin I adjusted the smtp-line in master.cf to --- smtp inet n - - - - smtpd -o content_filter=spamassassin --- and then disallowed submission on port 25. In main.cf I have 7 reject_*-lines like so --- smtpd_recipient_restrictions = ... reject_invalid_helo_hostname reject_unknown_sender_domain ... permit --- Will the reject_*-rules still apply to incoming mail before Postfix hands it over to SpamAssassin? The -o content_filter... setting on smtpd will override any main.cf content_filter setting, all other main.cf smtpd settings still apply. So yes, your main.cf smtpd_recipient_restrictions will still apply. -- Noel Jones
Integration of content filter in master.cf
I'm a little unsure about best practice here, hence the question.
Running /usr/sbin/spamd from the SpamAssassin package to scan mail, I've
integrated it into /etc/postfix/master.cf with the following
lines
---
smtp inet n - n - - smtpd -o
content_filter=spamassassin
...
spamassassin unix - n n - - pipe
flags=Rq user=spamd argv=/usr/bin/spamc -u ${user}@${domain}
-e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
---
And then in /etc/postfix/main.cf there's added the line
---
spamassassin_destination_recipient_limit = 1
---
However, this scans both incoming and outgoing mail, but for outgoing I
plan on using rate-limiting to avoid spamming the net (to much), in
case an account gets hacked.
So I searched the web, and constructed this alternative to use in
master.cf
---
26 inet n - n - - smtpd -o content_filter=spamassassin
smtp inet n - n - - smtpd
---
Using iptables, all incoming connections to port 25 could then be
directed to port 26. The server only have one ip-address.
The question then is, is this a practical solution, or can it be done
smarter, for example with less work and without using iptables, or
maybe some other way entirely?
Re: Integration of content filter in master.cf
On 1/8/2013 10:47 AM, Titanus Eramius wrote:
I'm a little unsure about best practice here, hence the question.
Running /usr/sbin/spamd from the SpamAssassin package to scan mail, I've
integrated it into /etc/postfix/master.cf with the following
lines
---
smtp inet n - n - - smtpd -o
content_filter=spamassassin
...
spamassassin unix - n n - - pipe
flags=Rq user=spamd argv=/usr/bin/spamc -u ${user}@${domain}
-e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
---
And then in /etc/postfix/main.cf there's added the line
---
spamassassin_destination_recipient_limit = 1
---
However, this scans both incoming and outgoing mail, but for outgoing I
plan on using rate-limiting to avoid spamming the net (to much), in
case an account gets hacked.
So I searched the web, and constructed this alternative to use in
master.cf
---
26 inet n - n - - smtpd -o content_filter=spamassassin
smtp inet n - n - - smtpd
---
Using iptables, all incoming connections to port 25 could then be
directed to port 26. The server only have one ip-address.
The question then is, is this a practical solution, or can it be done
smarter, for example with less work and without using iptables, or
maybe some other way entirely?
Using iptables to separate traffic is a reasonable solution.
Probably a good idea to add a comment to master.cf documenting what
you've done.
The more typical way to do this is for local mail to use the
submission port 587. Sometimes folks redirect port 25 on the local
network to 587 as a migration aid.
-- Noel Jones
Re: Integration of content filter in master.cf
On Jan 8, 2013, at 19:39, Noel Jones wrote: On 1/8/2013 10:47 AM, Titanus Eramius wrote: I'm a little unsure about best practice here, hence the question. Running /usr/sbin/spamd from the SpamAssassin package to scan mail, I've integrated it into /etc/postfix/master.cf with the following lines [snip] The question then is, is this a practical solution, or can it be done smarter, for example with less work and without using iptables, or maybe some other way entirely? Using iptables to separate traffic is a reasonable solution. Probably a good idea to add a comment to master.cf documenting what you've done. The more typical way to do this is for local mail to use the submission port 587. Sometimes folks redirect port 25 on the local network to 587 as a migration aid. This. Using the submission port is highly recommended, as it avoids all kinds of trouble, such as access providers blocking port 25. It also allows you to tailor each service to its specific needs; postscreen on 25, required authentication plus TLS and rate limiting on 587, and so on. HTH, Jona
Re: Integration of content filter in master.cf
Tue, 08 Jan 2013 12:39:58 -0600 skrev Noel Jones
njo...@megan.vbhcs.org:
On 1/8/2013 10:47 AM, Titanus Eramius wrote:
I'm a little unsure about best practice here, hence the question.
Running /usr/sbin/spamd from the SpamAssassin package to scan mail,
I've integrated it into /etc/postfix/master.cf with the following
lines
---
smtp inet n - n - - smtpd -o
content_filter=spamassassin
...
spamassassin unix - n n - - pipe
flags=Rq user=spamd argv=/usr/bin/spamc -u ${user}@${domain}
-e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
---
And then in /etc/postfix/main.cf there's added the line
---
spamassassin_destination_recipient_limit = 1
---
However, this scans both incoming and outgoing mail, but for
outgoing I plan on using rate-limiting to avoid spamming the net
(to much), in case an account gets hacked.
So I searched the web, and constructed this alternative to use in
master.cf
---
26 inet n - n - - smtpd -o
content_filter=spamassassin smtp inet n - n - - smtpd
---
Using iptables, all incoming connections to port 25 could then be
directed to port 26. The server only have one ip-address.
The question then is, is this a practical solution, or can it be
done smarter, for example with less work and without using
iptables, or maybe some other way entirely?
Using iptables to separate traffic is a reasonable solution.
Probably a good idea to add a comment to master.cf documenting what
you've done.
The more typical way to do this is for local mail to use the
submission port 587. Sometimes folks redirect port 25 on the local
network to 587 as a migration aid.
-- Noel Jones
OK, but using submission more or less removes the problem with
SpamAssassin. Thank you for the pointer, I'll be sure to use 587
for relaying from the users.
This raises the question (or at least I think it do), if it's
possible to force the users onto 587 by denying relay access to 25?
Re: Integration of content filter in master.cf
Tue, 8 Jan 2013 20:29:30 +0100 skrev DTNX Postmaster postmas...@dtnx.net: ... The more typical way to do this is for local mail to use the submission port 587. Sometimes folks redirect port 25 on the local network to 587 as a migration aid. This. Using the submission port is highly recommended, as it avoids all kinds of trouble, such as access providers blocking port 25. It also allows you to tailor each service to its specific needs; postscreen on 25, required authentication plus TLS and rate limiting on 587, and so on. HTH, Jona Thank you for the pointer on submission, I'll be sure to make use of it. But it raises a question (like i wrote in the reply to Noel), and that is (as far as i know) that I need to ensure the use of 587 so users can't go around rate limiting on 587 by using 25 for relaying. Would such a thing be possible to do?
Re: Integration of content filter in master.cf
Am 08.01.2013 21:48, schrieb Titanus Eramius: This raises the question (or at least I think it do), if it's possible to force the users onto 587 by denying relay access to 25? it's more a human problem than a technically to force a large amount of users to change their for a long time wrong usage of port 25 submission inet n - n - 50 smtpd -o smtpd_client_connection_count_limit=15 -o smtpd_client_connection_rate_limit=80 -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o max_idle=1h -o max_use=500 remove permit_sasl_authenticated at the same time from main.cf and you should be more or less done, but as said. how to explain all users that thheir config is wrong since the first day they are using it signature.asc Description: OpenPGP digital signature
Re: Integration of content filter in master.cf
Am 08.01.2013 22:03, schrieb Titanus Eramius: But it raises a question (like i wrote in the reply to Noel), and that is (as far as i know) that I need to ensure the use of 587 so users can't go around rate limiting on 587 by using 25 for relaying. Would such a thing be possible to do? smtpinet n - n - 50 smtpd -o smtpd_client_connection_rate_limit=5 submission inet n - n - 50 smtpd -o smtpd_client_connection_rate_limit=500 -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject signature.asc Description: OpenPGP digital signature
Re: Integration of content filter in master.cf
Tue, 08 Jan 2013 22:06:26 +0100 skrev Reindl Harald h.rei...@thelounge.net: Am 08.01.2013 21:48, schrieb Titanus Eramius: This raises the question (or at least I think it do), if it's possible to force the users onto 587 by denying relay access to 25? it's more a human problem than a technically to force a large amount of users to change their for a long time wrong usage of port 25 submission inet n - n - 50 smtpd -o smtpd_client_connection_count_limit=15 -o smtpd_client_connection_rate_limit=80 -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o max_idle=1h -o max_use=500 remove permit_sasl_authenticated at the same time from main.cf and you should be more or less done, but as said. how to explain all users that thheir config is wrong since the first day they are using it Thankfully I still have a few months before I start to have actual costumers, so this is my one chance to avoid some of the common problems. But I suspect you might be right with 587 anyway, because at least this client (Claws Mail) uses 25 as the standard port when sending through POP. Thank you for the example to deactivate client relaying through 25. I think this solves my problem, so thanks again for the replies.
Re: Integration of content filter in master.cf
On 1/8/2013 2:48 PM, Titanus Eramius wrote: Tue, 08 Jan 2013 12:39:58 -0600 skrev Noel Jones Using iptables to separate traffic is a reasonable solution. Probably a good idea to add a comment to master.cf documenting what you've done. The more typical way to do this is for local mail to use the submission port 587. Sometimes folks redirect port 25 on the local network to 587 as a migration aid. OK, but using submission more or less removes the problem with SpamAssassin. Thank you for the pointer, I'll be sure to use 587 for relaying from the users. This raises the question (or at least I think it do), if it's possible to force the users onto 587 by denying relay access to 25? It's certainly possible to prevent relaying via port 25, and many sites do so. The choice is a local policy decision; do what fits your needs best. Typically this is done by giving submission and port 25 different settings via master.cf -o ... overrides. A quick incomplete example: # main.cf mynetworks = 127.0.0.1 submission_mynetworks = 127.0.0.1, 192.168.0.0/16 smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination ... anti-spam controls ... submission_smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject # master.cf submission inet n - n - - smtpd -o syslog_name=postfix/submission -o mynetworks=$submission_mynetworks -o smtpd_recipient_restrictions=$submission_smtpd_recipient_restrictions ... more -o overrides ... Common variations are to require sasl AUTH on the submission port by removing permit_mynetworks, and to require TLS with AUTH by using -o smtpd_tls_auth_only=yes. -- Noel Jones
Re: Integration of content filter in master.cf
Tue, 08 Jan 2013 15:54:41 -0600 skrev Noel Jones njo...@megan.vbhcs.org: ... This raises the question (or at least I think it do), if it's possible to force the users onto 587 by denying relay access to 25? It's certainly possible to prevent relaying via port 25, and many sites do so. The choice is a local policy decision; do what fits your needs best. Typically this is done by giving submission and port 25 different settings via master.cf -o ... overrides. A quick incomplete example: # main.cf mynetworks = 127.0.0.1 submission_mynetworks = 127.0.0.1, 192.168.0.0/16 smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination ... anti-spam controls ... submission_smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject # master.cf submission inet n - n - - smtpd -o syslog_name=postfix/submission -o mynetworks=$submission_mynetworks -o smtpd_recipient_restrictions=$submission_smtpd_recipient_restrictions ... more -o overrides ... Common variations are to require sasl AUTH on the submission port by removing permit_mynetworks, and to require TLS with AUTH by using -o smtpd_tls_auth_only=yes. -- Noel Jones Thank you for the additional information, it's very helpful in the understanding of Postfix. I've had some trouble seeing the difference between -o overrides in main.cf and master.cf, but this really helps.
Re: Integration of content filter in master.cf
On 1/8/2013 4:11 PM, Titanus Eramius wrote: I've had some trouble seeing the difference between -o overrides in main.cf and master.cf, but this really helps. main.cf parameters are used by all postfix services (but not all parameters apply to all services). Individual services defined in master.cf can override main.cf settings with -o ... options. http://www.postfix.org/postconf.5.html http://www.postfix.org/master.5.html -- Noel Jones
Re: Integration of content filter in master.cf
Le 08/01/2013 21:48, Titanus Eramius a écrit :
Tue, 08 Jan 2013 12:39:58 -0600 skrev Noel Jones
njo...@megan.vbhcs.org:
On 1/8/2013 10:47 AM, Titanus Eramius wrote:
I'm a little unsure about best practice here, hence the question.
Running /usr/sbin/spamd from the SpamAssassin package to scan mail,
I've integrated it into /etc/postfix/master.cf with the following
lines
---
smtp inet n - n - - smtpd -o
content_filter=spamassassin
...
spamassassin unix - n n - - pipe
flags=Rq user=spamd argv=/usr/bin/spamc -u ${user}@${domain}
-e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
---
And then in /etc/postfix/main.cf there's added the line
---
spamassassin_destination_recipient_limit = 1
---
However, this scans both incoming and outgoing mail, but for
outgoing I plan on using rate-limiting to avoid spamming the net
(to much), in case an account gets hacked.
So I searched the web, and constructed this alternative to use in
master.cf
---
26 inet n - n - - smtpd -o
content_filter=spamassassin smtp inet n - n - - smtpd
---
Using iptables, all incoming connections to port 25 could then be
directed to port 26. The server only have one ip-address.
The question then is, is this a practical solution, or can it be
done smarter, for example with less work and without using
iptables, or maybe some other way entirely?
Using iptables to separate traffic is a reasonable solution.
Probably a good idea to add a comment to master.cf documenting what
you've done.
The more typical way to do this is for local mail to use the
submission port 587. Sometimes folks redirect port 25 on the local
network to 587 as a migration aid.
-- Noel Jones
OK, but using submission more or less removes the problem with
SpamAssassin. Thank you for the pointer, I'll be sure to use 587
for relaying from the users.
This raises the question (or at least I think it do), if it's
possible to force the users onto 587 by denying relay access to 25?
fix the problem at the source: force the client to do the work:
use different services for different uses:
[MX service]
port: 25
example DNS name: mx01.example.com
= no relay
virus and spam filtering...
[submission service]
example DNS name: smtp01.example.com
port 587. if this is hard, port 25 with a specific IP is ok.
SASL auth. when not desirable, IP based access control (thoug this may
be implemented outside of postfix, such as on a firewall)
virus filtering
rate limit and custom checks as needed.
[reverse MX]
example DNS name: mailrelay01.example.com
in small setups, this could be the same service as the submission one.
in larger setups, make this dedicated. it'll take the complexity of mail
routing and caching (retry).
...
