What about trouble with the DNSBL lists? I know when I changed my IP
address I had to work to get the new one removed from a few blacklists
it had previously been placed on. I wasn't sending spam, but my
messages would have been blocked under that config if I hadn't done
the work to get the IP off the lists.
- Grant
We do get false positives from the blacklists on rare occasion, but
they're the same ones we got before postscreen.
The two should be more or less equivalent considering that
postscreen_dnsbl_threshold = 1. (I should mention that you have to
register with barracuda before using their list.)
12-06-2011, 03:32 PM
Grant
clamav and spamassassin
>> What about trouble with the DNSBL lists? *I know when I changed my IP
>> address I had to work to get the new one removed from a few blacklists
>> it had previously been placed on. *I wasn't sending spam, but my
>> messages would have been blocked under that config if I hadn't done
>> the work to get the IP off the lists.
>>
>> - Grant
>>
>
> We do get false positives from the blacklists on rare occasion, but they're
> the same ones we got before postscreen.
>
> Before postscreen, we had,
>
> *smtpd_recipient_restrictions =
> * * * *permit_mynetworks,
> * * * *...
> * * * *reject_rbl_client psbl.surriel.com,
> * * * *reject_rbl_client bl.spamcop.net,
> * * * *reject_rbl_client zen.spamhaus.org,
> * * * *reject_rbl_client b.barracudacentral.org,
> * * * *permit
>
> After postscreen, we have,
>
> *smtpd_recipient_restrictions =
> * * * *permit_mynetworks,
> * * * *...
> * * * *permit
>
>
> *postscreen_dnsbl_sites =
> * * * *psbl.surriel.com,
> * * * *bl.spamcop.net,
> * * * *zen.spamhaus.org,
> * * * *b.barracudacentral.org
>
> The two should be more or less equivalent considering that
> postscreen_dnsbl_threshold = 1. (I should mention that you have to register
> with barracuda before using their list.)
Should this effectively disable postgrey and enable postscreen?
- Grant
12-06-2011, 04:11 PM
Michael Orlitzky
clamav and spamassassin
On 12/06/11 11:32, Grant wrote:
>
> Got it. Your explanations are positively lucid.
>
> I added this to /etc/postifx/main.cf:
>
> postscreen_greet_action = enforce
> postscreen_pipelining_enable = yes
> postscreen_pipelining_action = enforce
> postscreen_non_smtp_command_enable = yes
> postscreen_non_smtp_command_action = enforce
> postscreen_bare_newline_enable = yes
> postscreen_bare_newline_action = enforce
>
> and I commented this and restarted postfix:
>
> #check_policy_service inet:127.0.0.1:10030
>
> Should this effectively disable postgrey and enable postscreen?
>
That will disable postgrey, but isn't enough to enable postscreen. There
are a couple of daemons you have to enable in master.cf (steps 2 through 6):
That README refers to lines that are commented-out in master.cf; of
course, if you've upgraded from an earlier of postfix, you won't have them.
What I did was to untar the latest postfix release under my home
directory, and find the master.cf that ships with it. Then, I
copy/pasted the lines mentioned in the README over to my real master.cf.
After a restart, you should see lines like this in your mail log:
Dec 6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...
that let you know its' working.
12-06-2011, 06:17 PM
Paul Hartman
clamav and spamassassin
On Tue, Dec 6, 2011 at 11:11 AM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 12/06/11 11:32, Grant wrote:
>>
>> Got it. *Your explanations are positively lucid.
>>
>> I added this to /etc/postifx/main.cf:
>>
>> postscreen_greet_action = enforce
>> postscreen_pipelining_enable = yes
>> postscreen_pipelining_action = enforce
>> postscreen_non_smtp_command_enable = yes
>> postscreen_non_smtp_command_action = enforce
>> postscreen_bare_newline_enable = yes
>> postscreen_bare_newline_action = enforce
>>
>> and I commented this and restarted postfix:
>>
>> #check_policy_service inet:127.0.0.1:10030
>>
>> Should this effectively disable postgrey and enable postscreen?
>>
>
> That will disable postgrey, but isn't enough to enable postscreen. There
> are a couple of daemons you have to enable in master.cf (steps 2 through 6):
>
> *http://www.postfix.org/POSTSCREEN_README.html#enable
>
> That README refers to lines that are commented-out in master.cf; of
> course, if you've upgraded from an earlier of postfix, you won't have them.
>
> What I did was to untar the latest postfix release under my home
> directory, and find the master.cf that ships with it. Then, I
> copy/pasted the lines mentioned in the README over to my real master.cf.
>
> After a restart, you should see lines like this in your mail log:
>
> *Dec *6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...
>
> that let you know its' working.
Thanks for bringing up postscreen and the rest of your responses to
Grant in this thread, I wasn't aware of it either. None of the HOWTOs
I read ever mentioned it. I'm going to give it a try and see how it
goes.
12-06-2011, 08:34 PM
Grant
clamav and spamassassin
>> Got it. *Your explanations are positively lucid.
>>
>> I added this to /etc/postifx/main.cf:
>>
>> postscreen_greet_action = enforce
>> postscreen_pipelining_enable = yes
>> postscreen_pipelining_action = enforce
>> postscreen_non_smtp_command_enable = yes
>> postscreen_non_smtp_command_action = enforce
>> postscreen_bare_newline_enable = yes
>> postscreen_bare_newline_action = enforce
>>
>> and I commented this and restarted postfix:
>>
>> #check_policy_service inet:127.0.0.1:10030
>>
>> Should this effectively disable postgrey and enable postscreen?
>>
>
> That will disable postgrey, but isn't enough to enable postscreen. There
> are a couple of daemons you have to enable in master.cf (steps 2 through 6):
>
> *http://www.postfix.org/POSTSCREEN_README.html#enable
>
> That README refers to lines that are commented-out in master.cf; of
> course, if you've upgraded from an earlier of postfix, you won't have them.
>
> What I did was to untar the latest postfix release under my home
> directory, and find the master.cf that ships with it. Then, I
> copy/pasted the lines mentioned in the README over to my real master.cf.
>
> After a restart, you should see lines like this in your mail log:
>
> *Dec *6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...
>
> that let you know its' working.
Do you know how smtps comes into play? Right now I've got the
following uncommented in master.cf:
smtp inet n - n - - smtpd
smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
Should I write an smtpsd line or does tlsproxy make that unnecessary?
- Grant
12-06-2011, 09:20 PM
Michael Orlitzky
clamav and spamassassin
On 12/06/2011 04:34 PM, Grant wrote:
Do you know how smtps comes into play? Right now I've got the
following uncommented in master.cf:
smtp inet n - n - - smtpd
smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
Should I write an smtpsd line or does tlsproxy make that unnecessary?
SMTPS is deprecated. You probably don't need it at all, unless you do.
Some older (Microsoft...) clients can't use anything else for encryption.
These days, the "proper" way to secure your users' connections is with
TLS on the submission port, 587. You should also have a commented-out
'submission' line in your master.cf; that's what it's for.
The idea is that you can force encryption on port 587, and have your
users connect there instead of port 25. Then, the only restriction you
need for those connections is that the username/password be correct. The
rest of the mail comes in on port 25, unencrypted, as usual, and is
subjected to your anti-spam checks.
If you're using either SMTPS or the submission service, you don't need
to change them. Your users will continue to connect to port 465 (smtps)
or 587 (submission), bypassing postscreen entirely.
If you're not using the submission service, i.e. both external and
user-submitted mail come in on port 25, then you'll probably want to
exempt your users from the postscreen restrictions:
> > That README refers to lines that are commented-out in master.cf; of
> > course, if you've upgraded from an earlier of postfix, you won't have them.
> >
> > What I did was to untar the latest postfix release under my home
> > directory, and find the master.cf that ships with it. Then, I
> > copy/pasted the lines mentioned in the README over to my real master.cf.
> >
> > After a restart, you should see lines like this in your mail log:
> >
> > *Dec *6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...
> >
> > that let you know its' working.
>
> Thanks for bringing up postscreen and the rest of your responses to
> Grant in this thread, I wasn't aware of it either. None of the HOWTOs
> I read ever mentioned it. I'm going to give it a try and see how it
> goes.
>
Indeed. They are also unclear on how to configure SASL (but that's a different story).
Luckily, I'm building my mailfiltering gateway from scratch, and have been logging everything I do. When everything's finished and the mfgw works well, I'll distill my log into yet-another-wiki-article.
Rgds,
12-06-2011, 11:57 PM
Grant
clamav and spamassassin
> That will disable postgrey, but isn't enough to enable postscreen. There
> are a couple of daemons you have to enable in master.cf (steps 2 through 6):
>
> *http://www.postfix.org/POSTSCREEN_README.html#enable
>
> That README refers to lines that are commented-out in master.cf; of
> course, if you've upgraded from an earlier of postfix, you won't have them.
Don't you let etc-update add them for you?
> What I did was to untar the latest postfix release under my home
> directory, and find the master.cf that ships with it. Then, I
> copy/pasted the lines mentioned in the README over to my real master.cf.
>
> After a restart, you should see lines like this in your mail log:
>
> *Dec *6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...
>
> that let you know its' working.
Working now, thanks a lot. I should only need the tlsproxy line if my
users connect to port 25 to send mail, correct?
- Grant
12-07-2011, 12:02 AM
Grant
clamav and spamassassin
> SMTPS is deprecated. You probably don't need it at all, unless you do. Some
> older (Microsoft...) clients can't use anything else for encryption.
>
> These days, the "proper" way to secure your users' connections is with TLS
> on the submission port, 587. You should also have a commented-out
> 'submission' line in your master.cf; that's what it's for.
>
> The idea is that you can force encryption on port 587, and have your users
> connect there instead of port 25. Then, the only restriction you need for
> those connections is that the username/password be correct. The rest of the
> mail comes in on port 25, unencrypted, as usual, and is subjected to your
> anti-spam checks.
>
> If you're using either SMTPS or the submission service, you don't need to
> change them. Your users will continue to connect to port 465 (smtps) or 587
> (submission), bypassing postscreen entirely.
>
> If you're not using the submission service, i.e. both external and
> user-submitted mail come in on port 25, then you'll probably want to exempt
> your users from the postscreen restrictions:
>
> *http://www.postfix.org/postconf.5.html#postscreen_access_list
>
> but you should really be using the submission port!
Aye aye. Should I make the change like this:
#smtps inet n - n - - smtpd
# -o smtpd_tls_wrappermode=yes
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticate d,reject
# -o milter_macro_daemon_name=ORIGINATING
And then switch my clients from port 465 to 587?
- Grant
12-07-2011, 12:11 AM
Pandu Poluan
clamav and spamassassin
On Dec 7, 2011 8:01 AM, "Grant" <emailgrant@gmail.com> wrote:
>
> > That will disable postgrey, but isn't enough to enable postscreen. There
> > are a couple of daemons you have to enable in master.cf (steps 2 through 6):
clamav and spamassassin
I'm going to give it a try and see how it
