Re: This ought to be simple to stop. Am I missing something?

[Phil Stracchino]

pypolicyd-spf installed and working.  Studying the postscreen docs now...


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: 603.293.8485

Re: This ought to be simple to stop. Am I missing something?

[Phil Stracchino]

On 07/13/16 11:34, Bill Cole wrote:
> On 13 Jul 2016, at 9:50, Phil Stracchino wrote:
>> One thing I USED to do back when I was running an OpenBSD firewall box
>> was reject incoming connections to port 25 from Windows hosts.  Any
>> legitimate mail coming directly from a Windows machine would fall back
>> to my MX relay.  It stopped a LOT of botnet spam.  I don't imagine
>> there's any way to do that with Postfix though, and there doesn't seem
>> to be a way to do ut ising netfilter/shorewall on my current firewall,
>> which is a Ubiquiti embedded appliance.
> 
> I think the world has largely moved beyond that being useful. Microsoft 
> is actually using Exchange for their free and cheap mail hosting these 
> days and doing so in a very big way, and there are botnets of shoddy 
> Linux machines. Those include at least one that sustains itself by 
> exploiting BusyBox (i.e. embedded Linux) flaws. We live in a world of 
> small routers, firewalls, lightbulbs, doorbells, and refrigerators 
> sending spam YAY!

Agreed, it's no longer really a useful strategem anyway.  So I haven't
tried too hard to figure out a way to re-implement it.

>> ...And then remove the settings from smtp_sender_restrictions that are
>> now duplicated in the expanded smtpd_recipient_restrictions list?
> 
> Yes. Note that ordering becomes critical when collapsing everything into 
> smtpd_recipient_restrictions because a PERMIT from any directive in a 
> restriction list causes a message to bypass later directives in that 
> list. It is not inherently better or worse to split up the directives 
> between lists but with the ones you are using, it should work correctly 
> and avoids duplication of directives in multiple lists.

That would make sense.  Early PERMITs only where you want them to be
unconditionally accepted regardless of other conditions.

 unknown_client_reject_code = 450
>>>
>>> If you're sticking with reject_unknown_reverse_client_hostname only
>>> (which I'd recommend) you can change this safely to 550 (and in my
>>> opinion should, on a 'fail fast' principle.)
>>
>> I'm not actually sure why I had that set to 450.  Might have been a
>> testing setting that I forgot.
> 
> It's also duplicative of the default setting. Using 450 makes sense as a 
> default IF you use the more aggressive and accident-prone 
> reject_unknown_client_hostname. Since that restriction relies on DNS 
> coordination of 2 zones that may not have a common administrative 
> authority, it is more likely to "catch" on temporary mistakes that are 
> resolved within the retry lifetime of a legitimate message.

Noted.  Makes sense.


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: 603.293.8485

RE: auth/tls combinations sanity check

[Michael Fox]

> > I can make up any variable name I want and assign a value to
> > it main.cf, and then reference its value in main.cf and master.cf?
> 
> Yes.
> 
> --
>   Viktor.

Ah.  That is indeed powerful.  

And now I understand your suggested solution, Viktor.  It even solves a
problem I didn't mention in that it allows me to offer both STARTTLS (with
enforced TLS for external clients) on port 457 and wrapper mode on port 465
(for internal or external clients that don't speak STARTTLS). 

Brilliant.  Thanks much!

Michael

Re: auth/tls combinations sanity check

[Benny Pedersen]

On 2016-07-13 19:47, Michael Fox wrote:

Are you saying I can make up any variable name I want and assign a 
value to

it main.cf, and then reference its value in main.cf and master.cf?


indeed yes

Re: OT: ANN: S/MIME signing milter (for Postfix)

[Christian Rößner]

Hi Robert :-)

> Am 13.07.2016 um 17:51 schrieb Robert Schetterer :
> 
> Am 13.07.2016 um 15:45 schrieb Christian Rößner:
>> Hi,
>> 
>> I developed a S/MIME signing milter that can be used with Postfix. It 
>> features a simple map file, where you can define email addresses and 
>> corresponding certs/keys. If a mail arrives, the milter checks the MAIL FROM 
>> address and looks up the map file. If it finds a record, it signs the mail 
>> with S/MIME.
>> 
>> The milter is written in C++ (14. Probably 11 will work as well).
>> 
>> I tested it on Mac OS X and Gentoo Linux. Readmes and Man-pages are 
>> included. Feel free to give it a try:
>> 
>> https://signing-milter.org (Thanks to Andreas Schulze for the home)
>> 
>> Code: https://github.com/croessner/sigh
>> 
>> Feedback very welcome
>> 
>> Christian
>> 
> 
> Hi Christian, do you plan SMIMEA Support on the long run ?
> 
> https://tools.ietf.org/html/draft-ietf-dane-smime-02

I must think about this. Currently we (Patrick Ben Koetter) and I have 
developed a pure SMIMEA milter that is already available on Github. At the 
other hand, I decided to use C++ for this milter, because I wanted to be able 
to easily extend the milter in OOP.

If I get feedback that people are interested in a full crypto milter (signing 
and decrypting) and with SMIMEA support, I would go this direction. But first I 
need some response, if the current milter works as expected. And please, if 
there are some coders here, make a review of the code and let me know, if you 
find issues.

I also could include databases like LDAP or SQL. This is a first release, which 
covers basic usage.

Kind regards

Christian
-- 
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com



smime.p7s
Description: S/MIME cryptographic signature

Re: auth/tls combinations sanity check

[Viktor Dukhovni]

On Wed, Jul 13, 2016 at 10:47:37AM -0700, Michael Fox wrote:

> I can make up any variable name I want and assign a value to
> it main.cf, and then reference its value in main.cf and master.cf?

Yes.

-- 
Viktor.

RE: auth/tls combinations sanity check

[Michael Fox]

> > But looking at http://www.postfix.org/postconf.5.html, I don't find
> > mua_discard_ehlo_keyword_address_maps or mua_sender_restrictions.  Are
> > those
> > literal names?  Where can I find documentation?
> 
> trick here is that we only ask for postconf -n, this will not display
> postconf -Mf :=)
> 
> with the above config its not needed to provide both
> 
> and its more readeble to see what happends when one edit main.cf, and
> not needing edit master.cf eath day

I'm not sure I understand you Benny.

Are you saying I can make up any variable name I want and assign a value to
it main.cf, and then reference its value in main.cf and master.cf?

If so, is that capability documented somewhere?  (When I couldn't find mua_*
in http://www.postfix.org/postconf.5.html, I looked for a statement to that
effect on http://www.postfix.org/  but could not find any indication that
that was allowed.)

Thanks,
Michael

Re: auth/tls combinations sanity check

[Benny Pedersen]

On 2016-07-13 18:45, Michael Fox wrote:


But looking at http://www.postfix.org/postconf.5.html, I don't find
mua_discard_ehlo_keyword_address_maps or mua_sender_restrictions.  Are 
those

literal names?  Where can I find documentation?


trick here is that we only ask for postconf -n, this will not display 
postconf -Mf :=)


with the above config its not needed to provide both

and its more readeble to see what happends when one edit main.cf, and 
not needing edit master.cf eath day

RE: auth/tls combinations sanity check

[Michael Fox]

> > So, I'm thinking I need three submission ports:
> > * one for AUTH but no TLS
> > * one for AUTH with opportunistic TLS
> > * one for AUTH with enforced TLS
> 
> You can combine these into just one service by using:
> 
> main.cf:
>   mua_discard_ehlo_keyword_address_maps =
> cidr:${config_directory}/ehlo.cidr
> 
> master.cf:
>   submission inet ... smtpd
>   -o
> smtpd_discard_ehlo_keyword_address_maps=$mua_discard_ehlo_keyword_address_
> maps
> 
> ehlo.cidr:
>   192.0.2.1/32 starttls,silent-discard
> 
> to suppress TLS for some clients, and:
> 
> main.cf:
>mua_sender_restrictions =
> check_client_access cidr:${config_directory}/tlsclient.cidr
> 
> master.cf:
>submission inet ... smtpd
>   -o smtpd_sender_restrictions=$mua_sender_restrictions
> 
> tlsclient.cidr:
>   192.0.2.0/24 DUNNO
>   0.0.0.0/0   reject_plaintext_session
> 
> --
>   Viktor.

Wow.  Thank you!  That looks elegant and powerful.  It will take me some
time for me to absorb.

But looking at http://www.postfix.org/postconf.5.html, I don't find
mua_discard_ehlo_keyword_address_maps or mua_sender_restrictions.  Are those
literal names?  Where can I find documentation?

Thanks,
Michael

Re: OT: ANN: S/MIME signing milter (for Postfix)

[Robert Schetterer]

Am 13.07.2016 um 15:45 schrieb Christian Rößner:
> Hi,
> 
> I developed a S/MIME signing milter that can be used with Postfix. It 
> features a simple map file, where you can define email addresses and 
> corresponding certs/keys. If a mail arrives, the milter checks the MAIL FROM 
> address and looks up the map file. If it finds a record, it signs the mail 
> with S/MIME.
> 
> The milter is written in C++ (14. Probably 11 will work as well).
> 
> I tested it on Mac OS X and Gentoo Linux. Readmes and Man-pages are included. 
> Feel free to give it a try:
> 
> https://signing-milter.org (Thanks to Andreas Schulze for the home)
> 
> Code: https://github.com/croessner/sigh
> 
> Feedback very welcome
> 
> Christian
> 

Hi Christian, do you plan SMIMEA Support on the long run ?

https://tools.ietf.org/html/draft-ietf-dane-smime-02

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: This ought to be simple to stop. Am I missing something?

[Bill Cole]

On 13 Jul 2016, at 9:50, Phil Stracchino wrote:


On 07/13/16 01:52, Bill Cole wrote:

On 12 Jul 2016, at 15:44, Phil Stracchino wrote:

[...]

One thing I USED to do back when I was running an OpenBSD firewall box
was reject incoming connections to port 25 from Windows hosts.  Any
legitimate mail coming directly from a Windows machine would fall back
to my MX relay.  It stopped a LOT of botnet spam.  I don't imagine
there's any way to do that with Postfix though, and there doesn't seem
to be a way to do ut ising netfilter/shorewall on my current firewall,
which is a Ubiquiti embedded appliance.


I think the world has largely moved beyond that being useful. Microsoft 
is actually using Exchange for their free and cheap mail hosting these 
days and doing so in a very big way, and there are botnets of shoddy 
Linux machines. Those include at least one that sustains itself by 
exploiting BusyBox (i.e. embedded Linux) flaws. We live in a world of 
small routers, firewalls, lightbulbs, doorbells, and refrigerators 
sending spam YAY!



1st note: You have a lot of explicitly set parameters that simply
replicate defaults. That's not harmful per se, but it adds noise to
postconf -n. The ones I found trivially are:

[...]

So you can reduce clutter in main.cf and postconf -n by removing the
explicit setting of those. There are likely others.


So noted, and cleaned up those.  I'll check through and see if I can
spot any others, with the reservation that in some cases I've left the
default explicitly set as a reminder to myself of what the default 
*is*.


I get that, and it also has the tangible benefit of nailing down 
defaults that you depend on not being changed by Wietse (rare and almost 
never wrong) or an intermediary packager (less rare, less consistently 
right.)





smtpd_client_restrictions = permit_mynetworks


Noise. There's no need to define any of the smtpd_*_restrictions 
lists
if the definition only includes a sequence of conditions that are 
going

to show up in logically later ones.


Hm, don't think I'd been aware of that.


Well, I understand it to be an innovation somewhere near v2...  :)

[...]


Also, consider putting all of that in smtpd_recipient_restrictions
instead, after permit_mynetworks.


reject_invalid_helo_hostname can go in smtpd_recipient_restrictions?


Yes. This has been true for at least as long as Postfix has had milter 
support (which is when I tossed Sendmail aside for anything other than 
than null-client and completely insane rigs involving hand-built 
cf-ese.) Like I said above, I think this was a v2 innovation.


There are corner cases where particular needs make it helpful to put 
logically early restrictions and permissions into the client/helo/sender 
lists but the side effects can be subtle and non-intuitive. By default 
(i.e. with smtpd_delay_reject=yes) all of the smtpd restriction lists 
are evaluated in order at RCPT time, with PERMIT results from early 
lists being effectively DUNNO results. See the SMTPD_ACCESS_README file 
for details and examples of where you might want to make use of multiple 
lists vs. putting all client/ehlo/sender directives in 
smtpd_recipient_restrictions.



smtpd_milters = inet:localhost:8891


Presumably opendkim?


Yup.  I'll have to study the docs (and possibly ask on the opendkim
list) on how to have opendkim sign only *outgoing* mail.  I hadn't
actually looked closely enough to see that it was signing incoming 
mail

as well.  Though possibly the forged sender was tricking it.


smtpd_recipient_restrictions = permit_mynetworks

smtpd_recipient_restrictions =
permit_mynetworks,reject_unauth_destination,

reject_unknown_reverse_client_hostname,reject_invalid_helo_hostname,
 check_helo_access pcre:/etc/postfix/helo.pcre,
 reject_unknown_sender_domain,reject_non_fqdn_sender,
 check_sender_access btree:/etc/postfix/block-local-sender


...And then remove the settings from smtp_sender_restrictions that are
now duplicated in the expanded smtpd_recipient_restrictions list?


Yes. Note that ordering becomes critical when collapsing everything into 
smtpd_recipient_restrictions because a PERMIT from any directive in a 
restriction list causes a message to bypass later directives in that 
list. It is not inherently better or worse to split up the directives 
between lists but with the ones you are using, it should work correctly 
and avoids duplication of directives in multiple lists.



unknown_client_reject_code = 450


If you're sticking with reject_unknown_reverse_client_hostname only
(which I'd recommend) you can change this safely to 550 (and in my
opinion should, on a 'fail fast' principle.)


I'm not actually sure why I had that set to 450.  Might have been a
testing setting that I forgot.


It's also duplicative of the default setting. Using 450 makes sense as a 
default IF you use the more aggressive and accident-prone 
reject_unknown_client_hostname. Since that restriction relies on DNS 
coordination of 2 

rewrite envelope and header address

[nasu.kyuri]

Hi guys,

I want to rewrite envelope and header address(From and To).

  e.g. : abc@sample.local > 123@sample.local
   123@sample.local > abc@sample.local

  123 is new address for other campany, and abc original address.

I want hide original address.
I used this commands.

  sender_canonical_maps
  recipient_canonical_maps
  canonical_maps

But I can't rewrite this case below. Other case is good.

  header to :  abc@sample.local , def@other.private
  envelope to :  def@other.private
  header from : ghi@sample.local
  envelope from : ghi@sample.local

result: 

  header to :  abc@sample.local , def@other.private
  envelope to :  def@other.private
  header from : 456@sample.local
  envelope from : 456@sample.local

I want to rewrite header address abc@sample.local to 123@sample.local.

Thanks

Re: auth/tls combinations sanity check

[Viktor Dukhovni]

> On Jul 13, 2016, at 10:33 AM, Viktor Dukhovni  
> wrote:
> 
>tlsclient.cidr:
>   192.0.2.0/24 DUNNO
>   0.0.0.0   reject_plaintext_session

That would be 0.0.0.0/0 of course.

-- 
Viktor.

Re: auth/tls combinations sanity check

[Viktor Dukhovni]

> On Jul 13, 2016, at 2:27 AM, Michael Fox  wrote:
> 
> So, I'm thinking I need three submission ports:
> * one for AUTH but no TLS
> * one for AUTH with opportunistic TLS
> * one for AUTH with enforced TLS

You can combine these into just one service by using:

main.cf:
mua_discard_ehlo_keyword_address_maps = 
cidr:${config_directory}/ehlo.cidr

master.cf:
submission inet ... smtpd
  -o 
smtpd_discard_ehlo_keyword_address_maps=$mua_discard_ehlo_keyword_address_maps

ehlo.cidr:
192.0.2.1/32 starttls,silent-discard

to suppress TLS for some clients, and:

main.cf:
   mua_sender_restrictions =
  check_client_access cidr:${config_directory}/tlsclient.cidr

master.cf:
   submission inet ... smtpd
  -o smtpd_sender_restrictions=$mua_sender_restrictions

tlsclient.cidr:
192.0.2.0/24 DUNNO
0.0.0.0   reject_plaintext_session

-- 
Viktor.

Re: OT: ANN: S/MIME signing milter (for Postfix)

[Christian Rößner]

> Am 13.07.2016 um 16:16 schrieb Benny Pedersen :
> 
> On 2016-07-13 16:08, Christian Rößner wrote:
> 
>>> I tested it on Mac OS X and Gentoo Linux. Readmes and Man-pages are 
>>> included. Feel free to give it a try:
>>> https://signing-milter.org (Thanks to Andreas Schulze for the home)
>>> Code: https://github.com/croessner/sigh
>> I forgot: The name "sigh" is an idea from Patrick Ben Koetter.
> 
> what gentoo overlay is it in ?
> 
> soon to see sigh.epub :=)
> 
> is it basicly what https://protonmail.com/ do already ?

Marc Schiffbauer from sys4 AG just does a review on the ebuild. I guess, it 
will arrive soon in Portage.

Christian
-- 
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com



smime.p7s
Description: S/MIME cryptographic signature

Re: OT: ANN: S/MIME signing milter (for Postfix)

[Benny Pedersen]

On 2016-07-13 16:08, Christian Rößner wrote:

I tested it on Mac OS X and Gentoo Linux. Readmes and Man-pages are 
included. Feel free to give it a try:

https://signing-milter.org (Thanks to Andreas Schulze for the home)
Code: https://github.com/croessner/sigh

I forgot: The name "sigh" is an idea from Patrick Ben Koetter.


what gentoo overlay is it in ?

soon to see sigh.epub :=)

is it basicly what https://protonmail.com/ do already ?

Re: recipient filtering and transport table - problem

[Zalezny Niezalezny]

I think I know where is my problem.
In the /etc/postfix/transport I have this configuration

mydomain.com  relay:relay.server.local
*   discard




To discard some specified E-mail address I used this settings:

smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/bad_recipients, permit_mynetworks,
reject_unauth_destination, permit


/etc/postfix/bad_recipients

supp...@mydomain.com REJECT




Now its working fine. In transport table I can put only IP or Domain, but
its not working with an E-mail addresses.


I hope this is the right configuration and it will work properly.To filter
my e-mails I will use


check_recipient_access hash:/etc/postfix/bad_recipients



Its also working perfectly with multiple recipients in the To: field.




If my understanding is wrong please reply.



With kind regards

Zalezny





On Wed, Jul 13, 2016 at 3:36 PM, Wietse Venema  wrote:

> Zalezny Niezalezny:
> > If I will put this to my transport file:
> >
> > supp...@mydomain.com  discard
> > mydomain.com  relay:relay.server.local
> > *   discard
> >
> > It will not work.
>
> That is insufficient information.  Include "postconf -n" output,
> "postmap -s" output for the transport map, logging of what happens,
> and a description of what should happen instead.
>
> Wietse
>

Re: OT: ANN: S/MIME signing milter (for Postfix)

[Christian Rößner]

> I developed a S/MIME signing milter that can be used with Postfix. It 
> features a simple map file, where you can define email addresses and 
> corresponding certs/keys. If a mail arrives, the milter checks the MAIL FROM 
> address and looks up the map file. If it finds a record, it signs the mail 
> with S/MIME.
> 
> The milter is written in C++ (14. Probably 11 will work as well).
> 
> I tested it on Mac OS X and Gentoo Linux. Readmes and Man-pages are included. 
> Feel free to give it a try:
> 
> https://signing-milter.org (Thanks to Andreas Schulze for the home)
> 
> Code: https://github.com/croessner/sigh

I forgot: The name "sigh" is an idea from Patrick Ben Koetter.

-- 
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com



smime.p7s
Description: S/MIME cryptographic signature

Re: This ought to be simple to stop. Am I missing something?

[Bill Cole]

On 13 Jul 2016, at 2:54, li...@lazygranch.com wrote:

‎Hopefully this won't be interpreted as thread hijacking, but can 
you elaborate of this?

---
reject_rbl_client zen.spamhaus.org=127.0.0.2,
reject_rbl_client zen.spamhaus.org=127.0.0.3,
reject_rbl_client zen.spamhaus.org=127.0.0.4,
reject_rbl_client zen.spamhaus.org=127.0.0.10,
reject_rbl_client zen.spamhaus.org=127.0.0.11,

Those are, in order: SBL(chronic spam sources), CSS(snowshoers), 
CBL(spambots), PBL(ISP-designated dynamic), and 
PBL(Spamhaus-determined 

dynamic)‎
-

So I gather some element of "zen" are not to your liking?


No. Those are all of the documented return codes currently in use.

To be clear: I cannot imagine a circumstance where I would say: "I don't 
think Steve Linford's judgment can be trusted with this." I know he's 
not the sole operator of Spamhaus these days, but he's one of the few 
people I've dealt with professionally who I trust so fully that I extend 
that trust to the team and processes he has built for Spamhaus.


That is, if you didn't specify the return codes, zen would do all of 
the above and more.


I don't believe that to be true. See these pages:

https://www.spamhaus.org/zen/
https://www.spamhaus.org/faq/section/Spamhaus%20XBL#136

I expect that if and when Spamhaus brings a new class of listing into 
Zen and assigns it a new code, I will hear about it quite near the 
launch and add it to the systems I manage immediately.


HOWEVER: in the history of DNSBLs there have been a number of cases 
where technical or psychological glitches have caused a DNSBL to 
effectively list the whole IPv4 space, sometimes with wild return codes. 
Until Spamhaus clearly *intentionally* uses other return codes, I will 
not treat them as meaningful. I trust Steve, his team, and their 
processes, but I do not trust the universe to not toss up a bit of chaos 
in random places like DNSBLs from time to time.



The Spamhaus write up on snow shoe spam is certainly interesting. 


Yes. They were really the first anti-spam organization to notice the 
snowshoe mechanism as a defining characteristic of a distinct class of 
spammer in between the purely criminal botnet spammers and the nominally 
legitimate sorts who can be handled by the SBL-style (or MAPS RBL-style, 
if you're old enough...) human-vetted DNSBL.

Re: This ought to be simple to stop. Am I missing something?

[Phil Stracchino]

On 07/13/16 01:52, Bill Cole wrote:
> On 12 Jul 2016, at 15:44, Phil Stracchino wrote:
>> I'm trying to.  :)
> 
> Well, the choices for how to do that are many. Probably the simplest way 
> to do it is with a "policy daemon" and the pypolicyd-spf implementation 
> is the purest up-to-date SPF enforcement tool in that class.

I will definitely investigate that recommendation then.  Thanks.

> Other options: there are other more comprehensive policy daemons, you 
> can do SPF checks with amavisd-new, or if you're a Perl weenie like me 
> you can install MIMEDefang and either implement SPF checks through one 
> of the available Perl modules in filter_sender() or let SpamAssassin 
> handle it.

I'm not actually using amavisd or spamassassin (I've been using DSpam,
which has historically performed very well for me, though I may have to
switch to spamassassin because DSpam is abandoned and becoming
increasingly difficult to maintain).  So pypolicyd-spf sounds like the
way to go at the moment.


>> I considered that option, yes.  I ...  could have sworn I *was* using
>> the Zen RBL, actually.  It looks as though I took it out for some 
>> reason
>> at some time in the past and never restored it.
> 
> I strongly recommend it. If you want fine-grained control over which 
> parts you use, you can select which return codes to look for. In my 
> case, I use these as part of my smtpd_recipient_restrictions list:

I will take that recommendation too, especially since I don't remember
why I stopped using it in the first place.


>> I haven't deployed postscreen yet, as I simply don't know enough about
>> it.
> 
> It's designed for doing the simplest and most numerous spam rejections 
> with the least effort. Its best features are the greeting delay, which 
> catches many of the most aggressively obnoxious bots, and the ability to 
> use multiple DNSBLs and DNSWLs in a scoring configuration. ~90% of the 
> rejections my personal mail system does are by postscreen, and I don't 
> believe it has ever made a mistake in rejecting a would-be sender. 
> That's with ONLY the DNSBL and PREGREET functions enabled. Obviously 
> everything else I do to keep the spam out is marginal in comparison...

I will definitely have to make time to investigate that as well then.

One thing I USED to do back when I was running an OpenBSD firewall box
was reject incoming connections to port 25 from Windows hosts.  Any
legitimate mail coming directly from a Windows machine would fall back
to my MX relay.  It stopped a LOT of botnet spam.  I don't imagine
there's any way to do that with Postfix though, and there doesn't seem
to be a way to do ut ising netfilter/shorewall on my current firewall,
which is a Ubiquiti embedded appliance.

> 1st note: You have a lot of explicitly set parameters that simply 
> replicate defaults. That's not harmful per se, but it adds noise to 
> postconf -n. The ones I found trivially are:
[...]
> So you can reduce clutter in main.cf and postconf -n by removing the 
> explicit setting of those. There are likely others.

So noted, and cleaned up those.  I'll check through and see if I can
spot any others, with the reservation that in some cases I've left the
default explicitly set as a reminder to myself of what the default *is*.

>> smtpd_client_restrictions = permit_mynetworks
> 
> Noise. There's no need to define any of the smtpd_*_restrictions lists 
> if the definition only includes a sequence of conditions that are going 
> to show up in logically later ones.

Hm, don't think I'd been aware of that.

>> smtpd_helo_restrictions = reject_invalid_hostname
>> reject_unknown_reverse_client_hostname pcre:/etc/postfix/helo.pcre
> 
> I cannot make sense of the dangling map reference at the end. Perhaps 
> you want 'check_helo_access' before it? I would expect an error to be 
> logged about this.

Totally right.  I'm not sure how I munged that.  I only added that the
other day, trying to defeat the forged local sender problem.

> Also: it seems that you've been using Postfix longer than me. :) The 
> 'new' name for "reject_invalid_hostname" is 
> "reject_invalid_helo_hostname" because there are too many nuances in 
> email jargon... Non-critical to change it, but doing so may save you a 
> 'man 5 postconf' next year or later.

Thanks.  :)  Good catch, I wasn't aware of that change.

> Also, consider putting all of that in smtpd_recipient_restrictions 
> instead, after permit_mynetworks.

reject_invalid_helo_hostname can go in smtpd_recipient_restrictions?

>> smtpd_milters = inet:localhost:8891
> 
> Presumably opendkim?

Yup.  I'll have to study the docs (and possibly ask on the opendkim
list) on how to have opendkim sign only *outgoing* mail.  I hadn't
actually looked closely enough to see that it was signing incoming mail
as well.  Though possibly the forged sender was tricking it.

>> smtpd_recipient_restrictions = permit_mynetworks
> smtpd_recipient_restrictions = 
> permit_mynetworks,reject_unauth_destination,
>  

OT: ANN: S/MIME signing milter (for Postfix)

[Christian Rößner]

Hi,

I developed a S/MIME signing milter that can be used with Postfix. It features 
a simple map file, where you can define email addresses and corresponding 
certs/keys. If a mail arrives, the milter checks the MAIL FROM address and 
looks up the map file. If it finds a record, it signs the mail with S/MIME.

The milter is written in C++ (14. Probably 11 will work as well).

I tested it on Mac OS X and Gentoo Linux. Readmes and Man-pages are included. 
Feel free to give it a try:

https://signing-milter.org (Thanks to Andreas Schulze for the home)

Code: https://github.com/croessner/sigh

Feedback very welcome

Christian
-- 
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com



smime.p7s
Description: S/MIME cryptographic signature

Re: recipient filtering and transport table - problem

[Wietse Venema]

Zalezny Niezalezny:
> If I will put this to my transport file:
> 
> supp...@mydomain.com  discard
> mydomain.com  relay:relay.server.local
> *   discard
> 
> It will not work.

That is insufficient information.  Include "postconf -n" output,
"postmap -s" output for the transport map, logging of what happens,
and a description of what should happen instead.

Wietse

Re: recipient filtering and transport table - problem

[Zalezny Niezalezny]

Hallo Wietse,

in my /etc/postfix/transport I have this

mydomain.com  relay:relay.server.local
*   discard


This configuration accept all E-mails addressed to @mydomain.com.


If I will put this to my transport file:

supp...@mydomain.com  discard
mydomain.com  relay:relay.server.local
*   discard

It will not work. How to do it properly ? Accept all To: *@mydomain.com
except supp...@mydomain.com


MfG

Zalezny

On Wed, Jul 13, 2016 at 1:06 PM, Wietse Venema  wrote:

> Zalezny Niezalezny:
> > Dear Colleagues,
> >
> > in our test app environment we are using real e-mail addresses to test.
> > Each test application sending to our test relay server some e-mails. On
> > that machine we are filtering all incoming E-mails from our test
> > environment.
> >
> >
> > - we are accepting E-mails addressed to our internal domain (TO:
> > u...@mydomain.com)
> > - we are dropping all external e-mails (TO: @gmail, @hotmail etc.etc.)
> with
> > transport table (* error: )
> >
> >
> > Unfortunately pool of our internal domains, include also technical
> > accounts. How to properly discard all E-mails addressed for example TO:
> > supp...@mydomain.com ?
>
> Use a transport table that returns "discard:" for those recipients.
>
> Wietse
>

Re: This ought to be simple to stop. Am I missing something?

[Benny Pedersen]

On 2016-07-13 11:56, L.P.H. van Belle wrote:

here your have an bind log example, WITH lame server logging.
Adjust where needed.



logging {
channel default_log {
file "/var/log/named/named.log" versions 9 size 1M;
print-time yes;
print-severity yes;
print-category yes;
};

category default { default_log; };
category general { default_log; };
};

i have only the above

26-Jun-2016 07:53:24.062 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
26-Jun-2016 20:55:53.324 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 168.100.1.3#53
26-Jun-2016 20:55:53.945 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
27-Jun-2016 00:08:46.369 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 168.100.1.3#53
27-Jun-2016 01:20:09.482 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
27-Jun-2016 01:20:09.590 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 168.100.1.3#53
27-Jun-2016 02:29:09.732 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
27-Jun-2016 03:43:58.806 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
27-Jun-2016 06:18:26.299 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 168.100.1.3#53
27-Jun-2016 15:28:56.449 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 168.100.1.3#53
28-Jun-2016 07:16:36.493 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 168.100.1.3#53
28-Jun-2016 15:48:29.665 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
29-Jun-2016 02:32:58.281 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 168.100.1.3#53
29-Jun-2016 02:32:58.349 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
29-Jun-2016 09:59:43.474 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
29-Jun-2016 21:07:58.956 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 168.100.1.3#53
29-Jun-2016 21:07:59.026 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
30-Jun-2016 06:32:03.605 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 168.100.1.3#53
01-Jul-2016 04:32:07.408 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 168.100.1.3#53
01-Jul-2016 08:48:15.474 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
01-Jul-2016 10:02:22.506 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 168.100.1.3#53
01-Jul-2016 13:45:54.584 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
01-Jul-2016 13:45:55.588 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 168.100.1.3#53
01-Jul-2016 18:20:13.819 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 168.100.1.3#53
01-Jul-2016 18:20:13.887 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
02-Jul-2016 03:22:45.031 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
02-Jul-2016 04:28:20.981 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
02-Jul-2016 04:28:21.055 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 168.100.1.3#53
02-Jul-2016 19:56:18.759 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
02-Jul-2016 23:34:16.631 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
03-Jul-2016 05:05:21.607 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 168.100.1.3#53
03-Jul-2016 16:35:46.833 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 168.100.1.3#53
03-Jul-2016 22:20:58.588 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 168.100.1.3#53
03-Jul-2016 23:21:23.438 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
04-Jul-2016 02:51:53.104 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
04-Jul-2016 11:26:57.156 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
04-Jul-2016 11:26:57.232 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/NS/IN': 168.100.1.3#53
04-Jul-2016 18:10:26.131 lame-servers: info: REFUSED unexpected RCODE 
resolving 'postfix.org/MX/IN': 

Re: recipient filtering and transport table - problem

[Wietse Venema]

Zalezny Niezalezny:
> Dear Colleagues,
> 
> in our test app environment we are using real e-mail addresses to test.
> Each test application sending to our test relay server some e-mails. On
> that machine we are filtering all incoming E-mails from our test
> environment.
> 
> 
> - we are accepting E-mails addressed to our internal domain (TO:
> u...@mydomain.com)
> - we are dropping all external e-mails (TO: @gmail, @hotmail etc.etc.) with
> transport table (* error: )
> 
> 
> Unfortunately pool of our internal domains, include also technical
> accounts. How to properly discard all E-mails addressed for example TO:
> supp...@mydomain.com ?

Use a transport table that returns "discard:" for those recipients.

Wietse

RE: This ought to be simple to stop. Am I missing something?

[L . P . H . van Belle]

here your have an bind log example, WITH lame server logging.
Adjust where needed. 

Just enable only lameserver logging. 
Set all to null and enable lameserver logging. 
No performance drop. 

logging {
channel bind_log {
file "/var/log/bind/bind.log" versions 3 size 1m;
severity info;
print-category  yes;
print-severity  yes;
print-time  yes;
};
channel query_log {
file "/var/log/bind/query.log" size 1m;
// Set the severity to dynamic to see all the debug messages.
severity debug 3;
};
channel update_debug {
file "/var/log/bind/update_debug.log" versions 3 size 100k;
severity debug;
print-severity  yes;
print-time  yes;
};
channel security_info {
file "/var/log/bind/security_info.log" versions 1 size 100k;
severity info;
print-severity  yes;
print-time  yes;
};
   channel xfer_log {
   file "/var/log/bind/xfer.log" size 1m;
   print-category yes;
   print-severity yes;
   print-time yes;
   severity info;
};

   channel unmatched_log {
   file "/var/log/bind/unmatched.log" size 1m;
   print-category yes;
   print-severity yes;
   print-time yes;
   severity info;
};

   channel lameservers_log {
   file "/var/log/bind/lameservers.log" size 1m;
   print-category yes;
   print-severity yes;
   print-time yes;
   severity info;
};

category default { bind_log; };
category lame-servers { lameservers_log; };
category update { update_debug; };
category update-security { update_debug; };
category security { security_info; };
category queries { query_log; };
//category unmatched { unmatched_log; };
category xfer-in { xfer_log; };
category xfer-out { xfer_log; };

// No logging at all .. 
// category default { null; };

};


> -Oorspronkelijk bericht-
> Van: m...@junc.eu [mailto:owner-postfix-us...@postfix.org] Namens Benny
> Pedersen
> Verzonden: woensdag 13 juli 2016 11:48
> Aan: postfix-users@postfix.org
> Onderwerp: Re: This ought to be simple to stop. Am I missing something?
> 
> On 2016-07-13 11:41, L.P.H. van Belle wrote:
> 
> > recommend using your own DNS servers when doing DNSBL queries to
> > Spamhaus.
> 
> using ::1 here i dont trust others
> 
> > I no lame servers in my bind logs.
> > The set below is running over 1 year now, without any problems.
> 
> bind9 default dont log lame-servers, since there is none that if enabled
> will fill logs pretty fast and it will drop bind9 performance aswell

Re: This ought to be simple to stop. Am I missing something?

[Benny Pedersen]

On 2016-07-13 11:41, L.P.H. van Belle wrote:


recommend using your own DNS servers when doing DNSBL queries to
Spamhaus.


using ::1 here i dont trust others


I no lame servers in my bind logs.
The set below is running over 1 year now, without any problems.


bind9 default dont log lame-servers, since there is none that if enabled 
will fill logs pretty fast and it will drop bind9 performance aswell

RE: This ought to be simple to stop. Am I missing something?

[L . P . H . van Belle]

Then stop using google dns or other dns servers 
that block dns request to rbl servers. 
Source :  https://www.spamhaus.org/faq/section/DNSBL%20Usage 

Check what DNS resolvers you are using: If you are using a free "open DNS 
resolver" service such as the Google Public DNS or large cloud/outsourced 
public DNS servers, such as Level3's or Verizon's, to resolve your DNSBL 
requests, in most cases you will receive a "not listed" (NXDOMAIN) reply from 
Spamhaus' public DNSBL servers. We recommend using your own DNS servers when 
doing DNSBL queries to Spamhaus.


I no lame servers in my bind logs. 
The set below is running over 1 year now, without any problems. 


Greetz, 

Louis


> -Oorspronkelijk bericht-
> Van: m...@junc.eu [mailto:owner-postfix-us...@postfix.org] Namens Benny
> Pedersen
> Verzonden: woensdag 13 juli 2016 11:36
> Aan: postfix-users@postfix.org
> Onderwerp: Re: This ought to be simple to stop. Am I missing something?
> 
> On 2016-07-13 08:55, L.P.H. van Belle wrote:
> > A good combination of rbl lists with postscreen im using.
> >
> > postscreen_dnsbl_threshold=4
> > postscreen_dnsbl_sites =
> > b.barracudacentral.org*4
> > bad.psky.me*4
> > zen.spamhaus.org*4
> > dnsbl.cobion.com*2
> > bl.spameatingmonkey.net*2
> > fresh.spameatingmonkey.net*2
> > dnsbl.anonmails.de*2
> > dnsbl.kempt.net*2
> > dnsbl.inps.de*2
> > bl.spamcop.net*2
> > dnsbl.sorbs.net*2
> > psbl.surriel.com*2
> > bl.mailspike.net*2
> > bl.suomispam.net*2
> > all.rbl.jp*2
> > swl.spamhaus.org*-4
> 
> last time it was tryed here bind9 says lame-servers to some of them, so
> if see this then dont use them
> 
> the good part here is postscreen sadly many of the above needs datafeeds
> to be stable

Re: This ought to be simple to stop. Am I missing something?

[Benny Pedersen]

On 2016-07-13 08:54, li...@lazygranch.com wrote:


So I gather some element of "zen" are not to your liking? That is, if
you didn't specify the return codes, zen would do all of the above and
more.


each of them can hit independly, eq some ips is listed multiplaces

so postscreen score would not be the same

Re: This ought to be simple to stop. Am I missing something?

[Benny Pedersen]

On 2016-07-13 08:55, L.P.H. van Belle wrote:

A good combination of rbl lists with postscreen im using.

postscreen_dnsbl_threshold=4
postscreen_dnsbl_sites =
b.barracudacentral.org*4
bad.psky.me*4
zen.spamhaus.org*4
dnsbl.cobion.com*2
bl.spameatingmonkey.net*2
fresh.spameatingmonkey.net*2
dnsbl.anonmails.de*2
dnsbl.kempt.net*2
dnsbl.inps.de*2
bl.spamcop.net*2
dnsbl.sorbs.net*2
psbl.surriel.com*2
bl.mailspike.net*2
bl.suomispam.net*2
all.rbl.jp*2
swl.spamhaus.org*-4


last time it was tryed here bind9 says lame-servers to some of them, so 
if see this then dont use them


the good part here is postscreen sadly many of the above needs datafeeds 
to be stable

recipient filtering and transport table - problem

[Zalezny Niezalezny]

Dear Colleagues,

in our test app environment we are using real e-mail addresses to test.
Each test application sending to our test relay server some e-mails. On
that machine we are filtering all incoming E-mails from our test
environment.


- we are accepting E-mails addressed to our internal domain (TO:
u...@mydomain.com)
- we are dropping all external e-mails (TO: @gmail, @hotmail etc.etc.) with
transport table (* error: )


Unfortunately pool of our internal domains, include also technical
accounts. How to properly discard all E-mails addressed for example TO:
supp...@mydomain.com ?

In the transport table e-mail to mydomain.com will be routed to the next
hop. How to properly discard technical accounts ?


Accept TO: user1...@mydomain.com
DROP: TO: supp...@mydomain.com

Also how to do it correctly, if TO: field include multiple E-mails ?


Thank in advance for any hints!

With kind regards

Zalezny

RE: This ought to be simple to stop. Am I missing something?

[L . P . H . van Belle]

A good combination of rbl lists with postscreen im using. 

postscreen_dnsbl_threshold=4
postscreen_dnsbl_sites =
b.barracudacentral.org*4
bad.psky.me*4
zen.spamhaus.org*4
dnsbl.cobion.com*2
bl.spameatingmonkey.net*2
fresh.spameatingmonkey.net*2
dnsbl.anonmails.de*2
dnsbl.kempt.net*2
dnsbl.inps.de*2
bl.spamcop.net*2
dnsbl.sorbs.net*2
psbl.surriel.com*2
bl.mailspike.net*2
bl.suomispam.net*2
all.rbl.jp*2
swl.spamhaus.org*-4

basicly. If one of the servers is in barracuda spamhaus or psky 
its always spam so i gave the the max (4). 
If its a "new" domain name fresh.spameatingmonkey.net give 2. 
And mostly one of the other gives also to if its really spam. 

Works good here and espacialy with fail2ban 
Using these filter/failregex 
failregex = addr  listed by domain
client \[\] blocked using multiple DNS-based blocklists
Which reduces cpu load and unneeded connections. 

And if you use spamassassin 
https://github.com/extremeshok/spamassassin-extremeshok_fromreplyto 

but setting up dkim dmarc spf is recommended yes. 

Greetz, 

Louis



> -Oorspronkelijk bericht-
> Van: postfixlists-070...@billmail.scconsult.com [mailto:owner-postfix-
> us...@postfix.org] Namens Bill Cole
> Verzonden: woensdag 13 juli 2016 7:53
> Aan: postfix-users@postfix.org
> Onderwerp: Re: This ought to be simple to stop. Am I missing something?
> 
> On 12 Jul 2016, at 15:44, Phil Stracchino wrote:
> 
> > On 07/12/16 10:30, Bill Cole wrote:
> >> On 12 Jul 2016, at 9:14, Phil Stracchino wrote:
> >>
> >>> I'm getting spam leaking through from sites with non-resolving IP or
> >>> invalid DNS, sending mail to myself as me.
> >>
> >> You COULD use reject_unknown_client_hostname but it has substantial
> >> false positives.
> >>
> >> More directly, you could enforce your own SPF record:
> >>
> >> caerllewys.net.259200  IN  TXT "v=spf1
> ip4:216.246.132.90 -all"
> >
> > I'm trying to.  :)
> 
> Well, the choices for how to do that are many. Probably the simplest way
> to do it is with a "policy daemon" and the pypolicyd-spf implementation
> is the purest up-to-date SPF enforcement tool in that class.
> 
> Other options: there are other more comprehensive policy daemons, you
> can do SPF checks with amavisd-new, or if you're a Perl weenie like me
> you can install MIMEDefang and either implement SPF checks through one
> of the available Perl modules in filter_sender() or let SpamAssassin
> handle it.
> 
> I'd definitely choose pypolicyd-spf if I had noticeable quantities of
> this sort of crap making it to holistic filtering. SPF failure is
> actually decisive in so little mail that I see anywhere that I've not
> seen a need to push it to the top of the filtering heap.
> 
> That's assuming you have a need to accept some mail claiming to be from
> addresses in your own domain via that service, which you may not if
> you've got a submission service set up. Based on the absence of any SASL
> settings in your postconf -n output, I'm guessing you have such a
> service, unless you rely entirely on source IP (i.e. permit_mynetworks)
> for relay control.
> 
> [...]
> >> In this case it also appears that the IP address was in the CBL and
> >> hence SpamHaus Zen when you accepted it. Maybe not, but if you are
> >> not
> >> killing such IPs in postscreen you're going to have a lot of spam
> >> getting further in than it needs to. Also, if you're running a
> >> smallish
> >> mail system with a limited audience that does not include a need to
> >> communicate with Vietnamese correspondents, you can probably block
> >> all
> >> email traffic from 14.160.0.0/11.
> >
> > I considered that option, yes.  I ...  could have sworn I *was* using
> > the Zen RBL, actually.  It looks as though I took it out for some
> > reason
> > at some time in the past and never restored it.
> 
> I strongly recommend it. If you want fine-grained control over which
> parts you use, you can select which return codes to look for. In my
> case, I use these as part of my smtpd_recipient_restrictions list:
> 
> reject_rbl_client zen.spamhaus.org=127.0.0.2,
> reject_rbl_client zen.spamhaus.org=127.0.0.3,
> reject_rbl_client zen.spamhaus.org=127.0.0.4,
> reject_rbl_client zen.spamhaus.org=127.0.0.10,
> reject_rbl_client zen.spamhaus.org=127.0.0.11,
> 
> Those are, in order: SBL(chronic spam sources), CSS(snowshoers),
> CBL(spambots), PBL(ISP-designated dynamic), and PBL(Spamhaus-determined
> dynamic)
> 
> > I haven't deployed postscreen yet, as I simply don't know enough about
> > it.
> 
> It's designed for doing the simplest and most numerous spam rejections
> with the least effort. Its best features are the greeting delay, which
> catches many of the most aggressively obnoxious bots, and the ability to
> use multiple DNSBLs and DNSWLs in a scoring configuration. ~90% of the
> rejections my personal mail system does are by 

Re: This ought to be simple to stop. Am I missing something?

[lists]

‎Hopefully this won't be interpreted as thread hijacking, but can you elaborate 
of this?
---
reject_rbl_client zen.spamhaus.org=127.0.0.2,
reject_rbl_client zen.spamhaus.org=127.0.0.3,
reject_rbl_client zen.spamhaus.org=127.0.0.4,
reject_rbl_client zen.spamhaus.org=127.0.0.10,
reject_rbl_client zen.spamhaus.org=127.0.0.11,

Those are, in order: SBL(chronic spam sources), CSS(snowshoers), 
CBL(spambots), PBL(ISP-designated dynamic), and PBL(Spamhaus-determined 
dynamic)‎
-

So I gather some element of "zen" are not to your liking? That is, if you 
didn't specify the return codes, zen would do all of the above and more.

The Spamhaus write up on snow shoe spam is certainly interesting. 

auth/tls combinations sanity check

[Michael Fox]

I have a possibly unusual AUTH/TLS combination requirement.  As a newbie, I
could use a sanity check.

Requirements:
* All virtual mail clients will use SASL AUTH
* Virtual mail clients on specific internal networks MUST NOT be offered
TLS.  This is to satisfy FCC requirements prohibiting the use of encryption
on certain radio frequencies.
* Other virtual mail clients on internal networks may choose to use TLS or
not.  (Some simple network appliances don't support TLS at all, or don't
support STARTTLS)
* Virtual mail clients from external networks (outside the firewall) MUST
use TLS. 


So, I'm thinking I need three submission ports:
* one for AUTH but no TLS
* one for AUTH with opportunistic TLS
* one for AUTH with enforced TLS

So, I'm thinking:

/etc/postfix/master.cf:

  # Submission for internal, radio clients; access controlled by IP address
in iptables
  2525 inet ...
-o smtpd_tls_security_level=none
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
...

  # Submission for internal, non-radio clients
  submission inet ...
-o smtpd_tls_security_level=may
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
...

  # Submission for external clients
  smtps inet ...
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
...

Does that make sense?
Is there a better way?
Is there anything I should keep in mind?

All comments and suggestions would be helpful.

Thanks,
Michael