OT lightweight IMAP client

[@lbutlr]

Figured someone on the list would have an opinion on a very lightweight 
feature-poor IMAP client. It doesn't need to do much else but access a single 
IMAP account and be able to forward emails as attachments. Search would be 
good, but not required. Searching for queueIDs in the Received header would be 
fantastic.

Primary considerations are fast and as light on memory use as possible and 
usable from a Mac (command-line is fine). I know mutt can do IMAP but I don't 
think it can forward messages as attachments though I am probably wrong. 
Windows 10 might be useful, but not required.

-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Re: Using a date in a bcc map

[@lbutlr]

On 08 Sep 2017, at 09:53, Wietse Venema  wrote:
> CONFIGURATION PARAMETERS
>   Changes to main.cf are picked up automatically, as cleanup(8) processes
>   run for only a limited amount of time. Use the command "postfix reload"
>   to speed up a change.

Right, I knew that.

> That also applies to the content of lookup tables that are used by the
> cleanup daemon.

I did not know that, however. Thanks.

The script is stupidly simple, but I will include it anyway in case anyone 
cares:

#!/bin/bash

JDATE=$(gdate +%j)
cat << EOF > /etc/postfix/recipient_bcc.pcre
if !/backup.*@/
/^([^+_]*).*@([^.]*)/   backup+${JDATE}.\${1}-\${2}@southgaylord.com 
endif

EOF

this results in a maildir for today for my list email address of

.251.kremels-kreme

Which is certainly easier to sort and search through than the previous method, 
especially if I use an MUA instead of doing everything via the shell.

I was torn on doing the SI date, but decided since the backups are only short 
term, there was no reason not to simply use the day of the year for sorting.

I use cron to run it at midnight

-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Re: Using a date in a bcc map

[Wietse Venema]

LuKreme:
> On Sep 8, 2017, at 05:30, Ralf Hildebrandt  wrote:
> >=20
> > Try creating the recipient_bcc.pcre using a script, and let the scipt
> > insert the date.
> 
> So recipient_bcc.pcre is not simply loaded at startup? Is it read each time (=
> seems unlikely) or simply periodically refreshed, or does my script to write=
>  the map need to thump postfix?

According to the cleanup manpage:

CONFIGURATION PARAMETERS
   Changes to main.cf are picked up automatically, as cleanup(8) processes
   run for only a limited amount of time. Use the command "postfix reload"
   to speed up a change.

That also applies to the content of lookup tables that are used by the
cleanup daemon.

Wietse

RE: can't get server to start postfix --ISSUE RESOLVED

[Fazzina, Angelo]

Hi again, thanks for the pointers everyone.

It was not a Postfix issue. I have no idea how it happened but permissions on / 
got changed some how.



This fixed the default Postfix install, and then I put my config in and we are 
running normally again.



root@mail2 ~]# ls -ld /

drw---. 23 root root 4096 Sep  8 09:59 /





[root@mail2 ~]# chmod 555 /

[root@mail2 ~]# ls -ld /

dr-xr-xr-x. 23 root root 4096 Sep  8 09:59 /





Server was rebooted



[root@mail2 ~]# ps -ef | grep post

root  1821 1  0 10:15 ?00:00:00 /usr/libexec/postfix/master

postfix   1827  1821  0 10:15 ?00:00:00 pickup -l -t fifo -u

postfix   1828  1821  0 10:15 ?00:00:00 qmgr -l -t fifo -u

root  2637  2609  0 10:15 pts/000:00:00 grep post



Sadly I did not figure it out a co-worker did, but at least production services 
are running again.

With Dovecot and other things running I was convinced it was not the server 
still and a postfix issue

Thanks again for all that tried to help.

-ALF



-Angelo Fazzina

Operating Systems Programmer / Analyst

University of Connecticut,  UITS, SSG, Server Systems

860-486-9075





-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Viktor Dukhovni
Sent: Friday, September 8, 2017 10:17 AM
To: postfix-users@postfix.org
Subject: Re: can't get server to start postfix





> On Sep 8, 2017, at 10:07 AM, Fazzina, Angelo 
> > wrote:

>

> I ran

> Yum remove postfix

> I moved any directories not deleted

> I have SELinux disabled  in /etc/sysconfig/

>

> I ran yum install postfix.

>

> Still same error, this is crazy.



You're not providing actionable information.  Does the "ls -ld"

command still report alternative access control for any of

the directories on the path from the root to

"/var/lib/postfix/master.lock"?



If so, master(8) likely still gets "Permission" denied when trying

to open the lock file.



Either you're wrong and SELinux is not disabled, or as Wietse

suggested there could be filesystem corruption, or there are

inherited access controls in place down from /var, etc.



You can test whether the restriction is still in place by giving

the "postfix" user a shell of "/bin/sh", then:



   # su postfix

   $ touch /var/lib/postfix/master.lock # Likely fails

   $ echo $$ > /var/lib/postfix/master.lock   # Likely fails



Fixing SELinux and broken filesystems is not a subject matter

for Postfix experts, best to ask on some forum dedicated for

your O/S, or just hunker down and figure it out.  Come back

to this list when the Postfix user has full rights to the

/var/lib/postfix/ directory.



--

  Viktor.

Re: Using a date in a bcc map

[LuKreme]

On Sep 8, 2017, at 05:30, Ralf Hildebrandt  wrote:
> 
> Try creating the recipient_bcc.pcre using a script, and let the scipt
> insert the date.

So recipient_bcc.pcre is not simply loaded at startup? Is it read each time 
(seems unlikely) or simply periodically refreshed, or does my script to write 
the map need to thump postfix?

> Nice idea!

Thanks. It seems like it will be useful.

-- 
This is my signature. There are many like it, but this one is mine.

Re: can't get server to start postfix

[Viktor Dukhovni]

> On Sep 8, 2017, at 10:07 AM, Fazzina, Angelo  wrote:
> 
> I ran 
> Yum remove postfix
> I moved any directories not deleted
> I have SELinux disabled  in /etc/sysconfig/
> 
> I ran yum install postfix.
> 
> Still same error, this is crazy.

You're not providing actionable information.  Does the "ls -ld"
command still report alternative access control for any of
the directories on the path from the root to
"/var/lib/postfix/master.lock"?

If so, master(8) likely still gets "Permission" denied when trying
to open the lock file.

Either you're wrong and SELinux is not disabled, or as Wietse
suggested there could be filesystem corruption, or there are
inherited access controls in place down from /var, etc.

You can test whether the restriction is still in place by giving
the "postfix" user a shell of "/bin/sh", then:

   # su postfix
   $ touch /var/lib/postfix/master.lock # Likely fails
   $ echo $$ > /var/lib/postfix/master.lock   # Likely fails

Fixing SELinux and broken filesystems is not a subject matter
for Postfix experts, best to ask on some forum dedicated for
your O/S, or just hunker down and figure it out.  Come back
to this list when the Postfix user has full rights to the
/var/lib/postfix/ directory.

-- 
Viktor.

RE: can't get server to start postfix

[Fazzina, Angelo]

Thank you all for trying to help.

I ran 
Yum remove postfix
I moved any directories not deleted
I have SELinux disabled  in /etc/sysconfig/

I ran yum install postfix.

Still same error, this is crazy.
-ALF

-Angelo Fazzina
Operating Systems Programmer / Analyst 
University of Connecticut,  UITS, SSG, Server Systems
860-486-9075


-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Viktor Dukhovni
Sent: Thursday, September 7, 2017 5:48 PM
To: postfix-users@postfix.org
Subject: Re: can't get server to start postfix

On Thu, Sep 07, 2017 at 09:34:55PM +, Fazzina, Angelo wrote:

> Victor: I messed with it a little but no change.

I did not suggest "messing" with it. :-)

> [root@mail2 ~]#  bash -c "ls -ld /var{,/lib{,/postfix{,/master.lock}}}"
> drwxr-xr-x. 20 rootroot4096 Mar  2  2017 /var
> drwxr-xr-x. 29 rootroot4096 Sep  7 03:46 /var/lib
> drwx--.  2 postfix postfix 4096 Sep  7 16:07 /var/lib/postfix
> -rw-r--r--.  1 postfix postfix0 Sep  7 16:07 /var/lib/postfix/master.lock

Note those "." characters at the end of the file mode, they likely
indicate some sort of file-access ACL beyond the file mode:


https://www.cloudinsidr.com/content/understanding-and-settingchanging-access-privileges-on-unixlinux-files-and-directories-mode-bits-and-alternative-access-methods-explained/

GNU's "ls" command uses a dot (".") to indicate a file with an
*SELinux security context and no other alternate access method*.
A file with *any other combination of alternate access methods*
is marked with a *+* character.

So you've been SELinux'ed, now turn that off or configure it
properly.

> [root@mail2 ~]# chmod 744 /var/lib/postfix/

You should not do that, the "postfix set-permissions" command sets
the directory mode to 0700.

> [root@mail2 ~]#  bash -c "ls -ld /var{,/lib{,/postfix{,/master.lock}}}"
> drwxr-xr-x. 20 rootroot4096 Mar  2  2017 /var
> drwxr-xr-x. 29 rootroot4096 Sep  7 03:46 /var/lib
> drwxr--r--.  2 postfix postfix 4096 Sep  7 16:07 /var/lib/postfix
> -rw-r--r--.  1 postfix postfix0 Sep  7 16:07 /var/lib/postfix/master.lock

And yet the funny "." characters remain...  

-- 
Viktor.

Re: Postscreen exceptions and blacklisting

[Nikolaos Milas]

On 8/9/2017 4:17 μμ, /dev/rob0 wrote:


...


Thanks a lot for your detailed and valuable advice! It helped me a lot 
to understand things better!


I will surely work on my configuration based on your recommendations.

I think I'll start by using your initial recommended changes and see how 
it goes.


Unfortunately, I have to work on many other areas so I don't have much 
time for experimentation.


Cheers,
Nick

Re: Postscreen exceptions and blacklisting

[/dev/rob0]

On Fri, Sep 08, 2017 at 03:03:49PM +0300, Nikolaos Milas wrote:
> On 8/9/2017 2:42 μμ, Wietse Venema wrote:
> > Just as with smtpd access maps, permit/reject are a final 
> > decision, and dunno means 'let something else make the decision'.
> 
> Please let my ask for a clarification here. The problem is that
> the rejection seems to have happened by postscreen itself.
> 
> I would expect that by using dunno for a client in
> postscript_exceptions (as follows):
> 
>postscreen_access_list =
>     permit_mynetworks,
>     cidr:/etc/postfix/postscreen_exceptions.cidr
> 
> all the following postscreen directives would by bypassed for
> this client:
> 
>postscreen_dnsbl_threshold = 2
>postscreen_dnsbl_sites =
>     b.barracudacentral.org*2,
>     zen.spamhaus.org*2,
>     psbl.surriel.com*2
>postscreen_dnsbl_action = enforce
>postscreen_greet_action = enforce
>postscreen_blacklist_action = enforce
> 
> Isn't this true?

No, and I thought that was already answered.

> In particular, why the postscreen_access_list did not affect the
> postscreen_dnsbl_action, which I would expect to be bypassed?

Your DUNNO result only terminated the postscreen_access_list test.

> Can you please explain? Which postscreen actions are affected by
> postscreen_access_list?

A permit/OK result causes all postscreen tests to be bypassed.

> Sorry if my question is dumb.

It's really the wrong question.  The fundamental problem is that 
you're trusting unsafe DNSBL services for outright rejection.  This 
typically is the case for those who need whitelisting.

>postscreen_dnsbl_threshold = 2

Default there is 1, and the way you are scoring things, you didn't 
need this.

>postscreen_dnsbl_sites =
>     b.barracudacentral.org*2,

A very good list, but fully automated from Barracuda devices' input; 
I have tried using it for rejection and had some complaints about 
blocking real mail.

>     zen.spamhaus.org*2,

This is the only one I'd trust fully.

>     psbl.surriel.com*2

Also mostly automated, with a removal tool provided to end users, 
whether spammers or not.

I'd replace your config with:

>postscreen_dnsbl_threshold = 2
>postscreen_dnsbl_sites =
>     b.barracudacentral.org,
>     zen.spamhaus.org*2,
>     psbl.surriel.com
>postscreen_dnsbl_action = enforce

This changes BRBL and PSBL to the default score of 1.  More spam 
would get through postscreen this way, but it's unlikely that you
would need to do much whitelisting.

Note, I would not stop there; I'd go the rest of the way to my 
postscreen sample config as can be found at the site in .sig.
Upgrade to at least Postfix 2.11 if you're not there yet.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Postscreen exceptions and blacklisting

[Matus UHLAR - fantomas]

On 8/9/2017 2:42 μμ, Wietse Venema wrote:

Just as with smtpd access maps, permit/reject are a final decision,
and dunno means 'let something else make the decision'.


On 08.09.17 15:03, Nikolaos Milas wrote:
Please let my ask for a clarification here. The problem is that the 
rejection seems to have happened by postscreen itself.


I would expect that by using dunno for a client in 
postscript_exceptions (as follows):


  postscreen_access_list =
       permit_mynetworks,
       cidr:/etc/postfix/postscreen_exceptions.cidr

all the following postscreen directives would by bypassed for this client:

  postscreen_dnsbl_threshold = 2
  postscreen_dnsbl_sites =
       b.barracudacentral.org*2,
       zen.spamhaus.org*2,
       psbl.surriel.com*2
  postscreen_dnsbl_action = enforce
  postscreen_greet_action = enforce
  postscreen_blacklist_action = enforce



Isn't this true?


no.

use permit in postscreen_exceptions.cidr to avoid remaining tests or reject
to reject immediately.

dunno is not even documented to work with postfix.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Honk if you love peace and quiet. 

Re: Postscreen exceptions and blacklisting

[Nikolaos Milas]

On 8/9/2017 2:42 μμ, Wietse Venema wrote:


Just as with smtpd access maps, permit/reject are a final decision,
and dunno means 'let something else make the decision'.


Thank you Wietse,

Please let my ask for a clarification here. The problem is that the 
rejection seems to have happened by postscreen itself.


I would expect that by using dunno for a client in postscript_exceptions 
(as follows):


   postscreen_access_list =
    permit_mynetworks,
    cidr:/etc/postfix/postscreen_exceptions.cidr

all the following postscreen directives would by bypassed for this client:

   postscreen_dnsbl_threshold = 2
   postscreen_dnsbl_sites =
    b.barracudacentral.org*2,
    zen.spamhaus.org*2,
    psbl.surriel.com*2
   postscreen_dnsbl_action = enforce
   postscreen_greet_action = enforce
   postscreen_blacklist_action = enforce

Isn't this true?

In particular, why the postscreen_access_list did not affect the 
postscreen_dnsbl_action, which I would expect to be bypassed?


Can you please explain? Which postscreen actions are affected by 
postscreen_access_list?


Sorry if my question is dumb.

Thanks a lot,
Nick

Re: Restrict outgoing/submission to defined local or virtual users

[Matus UHLAR - fantomas]

Matus:


why just outgoing? Are you willing to accept spam with fake from in your
domain?


On 07.09.17 15:13, Scott Techlist wrote:

I am not willing.  Inbound is already restricted and functioning properly.

That said, I migrated my configs from an older version of PF so now you made me 
worry about *how* it is restricted.

I have set at postfix level for local, virtual and relay users:
   local_recipient_maps = hash:/etc/postfix/local_recipient
   virtual_alias_maps = hash:/etc/postfix/virtual_users
   relay_recipient_maps = hash:/etc/postfix/relay_recipients

If the email isn't in one of those, it is rejected.

I *thought* it was those settings that are causing/accomplishing the inbound 
invalid address restricting.  No?  Fuzzy on this detail.

I will deploy reject_unlisted_sender for outbound checking.  I gather it will also 
consult local, virtual, and relay maps for what is "listed"?


I believe you must configure reject_unlisted_sender everywhere in order to
check sender address if it exists.  That's why I recommended you to do it
(and put it before all permit_* options).

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I wonder how much deeper the ocean would be without sponges. 

Re: bind smtpd to UNIX socket

[postfix-user]

> I think this is not supported.
> Try using type 'inet', bound to 127.0.0.1.
Thank you.
I was able to run smtpd on a UNIX socket. The problem was in the 
policies smtpd_relay_restrictions and smtpd_recipient_restrictions, 
which can not be set as "permit".

Re: Postscreen exceptions and blacklisting

[Nikolaos Milas]

On 8/9/2017 1:56 μμ, Allen Coates wrote:


In your exceptions list, use ACCEPT or REJECT;


By the way, can we interchangeably use any of the values ACCEPT / PERMIT 
/ OK ?


If so, can you please reference any associated documentation?

I ask because at http://www.postfix.org/POSTSCREEN_README.html the 
values described (for acceptance) are "PERMIT", while in the CIDR table 
documentation (http://www.postfix.org/cidr_table.5.html) the respective 
example shows: "OK".


Thanks a lot,
Nick

Re: Dupliacte messages from aliases

[Wietse Venema]

GP:
> Hi list,
> 
> I have a postfix install  on a debian 8  machine . I have some 
> distribution groups through
> aliases  and when a user sends a message to eg group1  which he is a 
> member and cc to group2
> (which he might be a member or  another member of group1 might be in ) 
> they get the message twice.
> Is there a way to avoid duplicate delivery on local defined alias 
> deliveries?

No. Postfix makes the deliveries to group1 and group2 in parallel.

Wietse

Re: Postscreen exceptions and blacklisting

[Wietse Venema]

Nikolaos Milas:
> On 8/9/2017 1:56 ??, Allen Coates wrote:
> 
> > DUNNO means "let something else decide" ...
> 
> Hi Allen,
> 
> I understand that, but shouldn't this also mean "Bypass ALL 
> postscreen-related checks & filtering", which should avoid blocking by 
> RBLs used within postscreen?

It means this:

dunno All postscreen(8) access lists implicitly have this  command  at
  the end.
  When   dunno  is executed inside a lookup table, return from the
  lookup table and evaluate the next command.
  When  dunno  is executed outside a lookup table,  terminate  the
  search,  and  subject  the client to the configured before/after
  220 greeting tests.

Just as with smtpd access maps, permit/reject are a final decision,
and dunno means 'let something else make the decision'.

Wietse

Re: Postscreen exceptions and blacklisting

[Nikolaos Milas]

On 8/9/2017 1:56 μμ, Allen Coates wrote:


DUNNO means "let something else decide" ...


Hi Allen,

I understand that, but shouldn't this also mean "Bypass ALL 
postscreen-related checks & filtering", which should avoid blocking by 
RBLs used within postscreen?


Cheers,
Nick

Re: Using a date in a bcc map

[Ralf Hildebrandt]

* @lbutlr :
> [This message bounced because the words "c h a n g e" and "a d d r e s s" 
> were on the same line.]
> 
> I currently have recipient_bcc.pcre:
> 
> if !/backup.*@/
> /^([^+_]*).*@(.*)/   backup+${1}.${2}@localdomain.tld
> endif
> 
> I would like to change 
> this to add a date field 
> to the backup address. 

Try creating the recipient_bcc.pcre using a script, and let the scipt
insert the date.

Nice idea!

-- 
[*] sys4 AG

https://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: Postscreen exceptions and blacklisting

[Allen Coates]

In your exceptions list, use ACCEPT or REJECT;
DUNNO means "let something else decide" ...

Allen C

On 08/09/17 09:36, Nikolaos Milas wrote:
> Hello,
> 
> I have tried to whitelist some servers for postscreen, but I notice that
> they continue to get blocked if they are blacklisted.
> 
> What I am doing wrong in whitelisting them?
> 
> How can I successfully whitelist them so that they are not blocked even
> if they are blacklisted in a RBL/RSBL?
> 
> Here is a session with remote server 195.134.100.81 (ours is 62.217.124.2):
> 
> Aug 31 11:14:01 mailgw3 postfix/postscreen[6476]: CONNECT from
> [195.134.100.81]:50520 to [62.217.124.2]:25
> Aug 31 11:14:02 mailgw3 postfix/dnsblog[6328]: addr 195.134.100.81
> listed by domain b.barracudacentral.org as 127.0.0.2
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: DNSBL rank 2 for
> [195.134.100.81]:50520
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: NOQUEUE: reject: RCPT
> from [195.134.100.81]:50520: 550 5.7.1 Service unavailable; client
> [195.134.100.81] blocked using b.barracudacentral.org; from=<>,
> to=, proto=SMTP, helo=
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: NOQUEUE: reject: RCPT
> from [195.134.100.81]:50520: 550 5.7.1 Service unavailable; client
> [195.134.100.81] blocked using b.barracudacentral.org;
> from=, to=, proto=SMTP,
> helo=
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: DISCONNECT
> [195.134.100.81]:50520
> 
> My setup (on Postfix 2.11.0):
> 
> # postconf -n
> allowed_list1 = check_client_access cidr:/etc/postfix/vmail.cidr,reject
> allowed_list2 = check_client_access
> cidr:/etc/postfix/internalnetworks.cidr,reject
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> content_filter = smtp-amavis:[127.0.0.1]:10024
> daemon_directory = /usr/libexec/postfix
> data_directory = /var/lib/postfix
> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
> xxgdb $daemon_directory/$process_name $process_id & sleep 5
> default_process_limit = 50
> disable_vrfy_command = yes
> enable_long_queue_ids = yes
> header_checks = pcre:/etc/postfix/blacklisted_maillists
> html_directory = no
> inet_interfaces = all
> inet_protocols = ipv4, ipv6
> local_recipient_maps =
> local_transport = error:local mail delivery is disabled
> mail_name = NOA Mail Srv XAPITI XPICTOY
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> message_size_limit = 15728640
> mydestination =
> mynetworks = 127.0.0.1/32 [::1]/128
> myorigin = $mydomain
> newaliases_path = /usr/bin/newaliases.postfix
> postscreen_access_list = permit_mynetworks,
> cidr:/etc/postfix/postscreen_exceptions.cidr
> postscreen_blacklist_action = enforce
> postscreen_dnsbl_action = enforce
> postscreen_dnsbl_sites = b.barracudacentral.org*2, zen.spamhaus.org*2,
> psbl.surriel.com*2
> postscreen_dnsbl_threshold = 2
> postscreen_greet_action = enforce
> queue_directory = /var/spool/postfix
> relay_domains = noa.gr, astro.noa.gr, admin.noa.gr, nestor.noa.gr,
> space.noa.gr, meteo.noa.gr, gein.noa.gr, technet.noa.gr, hesperia-space.eu
> relay_recipient_maps =
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtp_tls_security_level = may
> smtpd_helo_required = yes
> smtpd_recipient_restrictions = check_client_access
> hash:/etc/postfix/amavis_bypass check_sender_access
> hash:/etc/postfix/blacklisted_senders check_sender_access
> pcre:/etc/postfix/blacklisted_maillists reject_unverified_recipient
> reject_unauth_destination check_recipient_access
> hash:/etc/postfix/protected_destinations permit_mynetworks
> reject_invalid_hostname reject_unauth_pipelining reject_non_fqdn_sender
> reject_unknown_sender_domain reject_non_fqdn_recipient
> reject_unknown_recipient_domain reject_rbl_client b.barracudacentral.org
> reject_rbl_client zen.spamhaus.org reject_rbl_client psbl.surriel.com
> reject_rbl_client bl.spamcop.net reject_rbl_client dnsbl.sorbs.net
> reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_sender
> dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org check_policy_service
> unix:postgrey/socket permit
> smtpd_restriction_classes = allowed_list1,allowed_list2
> smtpd_tls_CAfile = /etc/pki/tls/certs/DigiCertCA.crt
> smtpd_tls_cert_file = /etc/pki/tls/certs/star_noa_gr-1365536.crt
> smtpd_tls_exclude_ciphers = DES,3DES,MD5,aNULL,AES128,CAMELLIA128
> smtpd_tls_key_file = /etc/pki/tls/private/star_noa_gr-1365536.key
> smtpd_tls_loglevel = 1
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_timeout = 3600s
> transport_maps = hash:/etc/postfix/transportmap
> unknown_local_recipient_reject_code = 550
> unverified_sender_reject_code = 550
> virtual_alias_maps = hash:/etc/postfix/virtualmap
> 
> and cidr:/etc/postfix/postscreen_exceptions.cidr is:
> 
>195.134.100.72   dunno
>195.134.100.69   dunno
>195.134.100.81   dunno
>195.134.100.119  dunno
> 
> Please advise!

Re: Postscreen exceptions and blacklisting

[Nikolaos Milas]

On 8/9/2017 11:36 πμ, Nikolaos Milas wrote:


What I am doing wrong in whitelisting them?


Let me try to guess: should I use "permit" rather than "dunno" (in 
postscreen_exceptions.cidr)?


If so, why "dunno" doesn't work? Shouldn't it whitelist a client from 
any and all postscreen tests?


Please advise!

Thanks,
Nick

Postscreen exceptions and blacklisting

[Nikolaos Milas]

Hello,

I have tried to whitelist some servers for postscreen, but I notice that 
they continue to get blocked if they are blacklisted.


What I am doing wrong in whitelisting them?

How can I successfully whitelist them so that they are not blocked even 
if they are blacklisted in a RBL/RSBL?


Here is a session with remote server 195.134.100.81 (ours is 62.217.124.2):

Aug 31 11:14:01 mailgw3 postfix/postscreen[6476]: CONNECT from 
[195.134.100.81]:50520 to [62.217.124.2]:25
Aug 31 11:14:02 mailgw3 postfix/dnsblog[6328]: addr 195.134.100.81 
listed by domain b.barracudacentral.org as 127.0.0.2
Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: DNSBL rank 2 for 
[195.134.100.81]:50520
Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: NOQUEUE: reject: RCPT 
from [195.134.100.81]:50520: 550 5.7.1 Service unavailable; client 
[195.134.100.81] blocked using b.barracudacentral.org; from=<>, 
to=, proto=SMTP, helo=
Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: NOQUEUE: reject: RCPT 
from [195.134.100.81]:50520: 550 5.7.1 Service unavailable; client 
[195.134.100.81] blocked using b.barracudacentral.org; 
from=, to=, proto=SMTP, 
helo=
Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: DISCONNECT 
[195.134.100.81]:50520


My setup (on Postfix 2.11.0):

# postconf -n
allowed_list1 = check_client_access cidr:/etc/postfix/vmail.cidr,reject
allowed_list2 = check_client_access 
cidr:/etc/postfix/internalnetworks.cidr,reject

command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin 
xxgdb $daemon_directory/$process_name $process_id & sleep 5

default_process_limit = 50
disable_vrfy_command = yes
enable_long_queue_ids = yes
header_checks = pcre:/etc/postfix/blacklisted_maillists
html_directory = no
inet_interfaces = all
inet_protocols = ipv4, ipv6
local_recipient_maps =
local_transport = error:local mail delivery is disabled
mail_name = NOA Mail Srv XAPITI XPICTOY
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 15728640
mydestination =
mynetworks = 127.0.0.1/32 [::1]/128
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
postscreen_access_list = permit_mynetworks, 
cidr:/etc/postfix/postscreen_exceptions.cidr

postscreen_blacklist_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = b.barracudacentral.org*2, zen.spamhaus.org*2, 
psbl.surriel.com*2

postscreen_dnsbl_threshold = 2
postscreen_greet_action = enforce
queue_directory = /var/spool/postfix
relay_domains = noa.gr, astro.noa.gr, admin.noa.gr, nestor.noa.gr, 
space.noa.gr, meteo.noa.gr, gein.noa.gr, technet.noa.gr, hesperia-space.eu

relay_recipient_maps =
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_recipient_restrictions = check_client_access 
hash:/etc/postfix/amavis_bypass check_sender_access 
hash:/etc/postfix/blacklisted_senders check_sender_access 
pcre:/etc/postfix/blacklisted_maillists reject_unverified_recipient 
reject_unauth_destination check_recipient_access 
hash:/etc/postfix/protected_destinations permit_mynetworks 
reject_invalid_hostname reject_unauth_pipelining reject_non_fqdn_sender 
reject_unknown_sender_domain reject_non_fqdn_recipient 
reject_unknown_recipient_domain reject_rbl_client b.barracudacentral.org 
reject_rbl_client zen.spamhaus.org reject_rbl_client psbl.surriel.com 
reject_rbl_client bl.spamcop.net reject_rbl_client dnsbl.sorbs.net 
reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_sender 
dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org check_policy_service 
unix:postgrey/socket permit

smtpd_restriction_classes = allowed_list1,allowed_list2
smtpd_tls_CAfile = /etc/pki/tls/certs/DigiCertCA.crt
smtpd_tls_cert_file = /etc/pki/tls/certs/star_noa_gr-1365536.crt
smtpd_tls_exclude_ciphers = DES,3DES,MD5,aNULL,AES128,CAMELLIA128
smtpd_tls_key_file = /etc/pki/tls/private/star_noa_gr-1365536.key
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
transport_maps = hash:/etc/postfix/transportmap
unknown_local_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtualmap

and cidr:/etc/postfix/postscreen_exceptions.cidr is:

   195.134.100.72   dunno
   195.134.100.69   dunno
   195.134.100.81   dunno
   195.134.100.119  dunno

Please advise!

Thanks a lot,
Nick

Dupliacte messages from aliases

[GP]

Hi list,

I have a postfix install  on a debian 8  machine . I have some 
distribution groups through
aliases  and when a user sends a message to eg group1  which he is a 
member and cc to group2
(which he might be a member or  another member of group1 might be in ) 
they get the message twice.
Is there a way to avoid duplicate delivery on local defined alias 
deliveries?


thanks and regards