[pfx] Re: Incoming mail server blocks outlook / microsoft servers

[Nikolaos Milas via Postfix-users]

On 10/1/2024 6:30 μ.μ., Bill Cole via Postfix-users wrote:
You should be more selective about your long lists of DNSBLs. They are 
not all the same thing, and so are not all suitable for use at 
postscreen time. It seems like you are ignoring the fact that the 
underlying cause of this rejection is your decision to trust the 
Spamcop 'bl' list as an absolute blocker, which for most people who 
value their email is not a good idea. If you want to consistently 
receive mail from the giant mailbox providers, you need to use more 
nuanced mechanisms.

...
Using reject_rbl_client with DNSBLs which occasionally list IPs which 
send a mix of spam and ham can be made feasible by putting the 
reject_rbl_client restriction late in the restriction list and having 
exemption mechanisms ahead of it. For example, I use reject_rbl_client 
extensively, but with check_*_access maps ahead of those directives. 
If you like everything about the Spamcop DNSBL except for it listing 
Microsoft outbounds, you could have a check_client_access directive 
with a map that permits *.outbound.protection.outlook.com clients 
before any DNSBL checks (in the same restriction list.)


Thank you Bill, and all others for your feedback.

Unfortunately at this time I don't have the luxury to invest time in 
more complex configuration scenarios as mail server management is only a 
small fraction of our tiny department... I guess I have to trust 
Postscreen and avoid false positives in smtpd restrictions as Matus 
advised.


To optimize behavior I would need to constantly monitor BL trust status 
and experiment with configuration changes (supported/offered abundantly 
by postfix) which is not feasible in my case I am afraid. I have to be 
modest in my aspirations.


However, I do admit that all suggestions do have their place if used 
knowledgeably in the right context.


If there are any complete and working configuration suggestions I could 
probably try them, but it would be very difficult to work on preparing a 
new one starting from our current config.


If anyone would like to provide or point to any publicly available 
*complete* config suggestion(s) for testing in our production 
environment, please let me know.


{Note: Our gateway servers are working with postfix - amavis (with 
spamassassin, clamav) on Rocky Linux 8.}


All the best,
Nick

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Incoming mail server blocks outlook / microsoft servers

[Nikolaos Milas via Postfix-users]

On 10/1/2024 5:24 μ.μ., Matus UHLAR - fantomas via Postfix-users wrote:


If you use postscreen, remove reject_rbl_client from *_restrictions.

reject_rhsbl_client, reject_rhsbl_sender and reject_rhsbl_helo are 
fine to stay since they use something postscreen does not. 


Thanks Matus for your prompt reply. I appreciate it a lot.

Cheers,
Nick

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Incoming mail server blocks outlook / microsoft servers

[Nikolaos Milas via Postfix-users]

Hello,

Our postfix v3.8.3 mail gateway server (for incoming mail) filters 
clients using postscreen as follows:


   postscreen_dnsbl_sites =
    zen.spamhaus.org*3
    b.barracudacentral.org*2
    bl.spameatingmonkey.net*2
    bl.spamcop.net
    dnsbl.sorbs.net
    psbl.surriel.com
    bl.mailspike.net
    list.dnswl.org=127.0.[0..255].0*-2
    list.dnswl.org=127.0.[0..255].1*-3
    list.dnswl.org=127.0.[0..255].[2..3]*-4

and:

   smtpd_recipient_restrictions =
    ...
    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_rhsbl_client dbl.spamhaus.org
    reject_rhsbl_sender dbl.spamhaus.org
    reject_rhsbl_helo dbl.spamhaus.org
    permit

It seems that the blacklisting services sometimes block some of 
microsoft/outlook servers. Example:


Jan 08 10:02:17 mailgw1 postfix/postscreen[925211]: CONNECT from 
[40.107.20.56]:12832 to [83.212.5.27]:25
Jan 08 10:02:17 mailgw1 postfix/dnsblog[930573]: addr 40.107.20.56 
listed by domain bl.spamcop.net as 127.0.0.2
Jan 08 10:02:17 mailgw1 postfix/dnsblog[928879]: addr 40.107.20.56 
listed by domain list.dnswl.org as 127.0.3.0
Jan 08 10:02:18 mailgw1 postfix/postscreen[925211]: PASS OLD 
[40.107.20.56]:12832
Jan 08 10:02:18 mailgw1 postfix/smtpd[930587]: connect from 
mail-db8eur05on2056.outbound.protection.outlook.com[40.107.20.56]
Jan 08 10:02:18 mailgw1 postfix/smtpd[930587]: Anonymous TLS connection 
established from 
mail-db8eur05on2056.outbound.protection.outlook.com[40.107.20.56]: 
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jan 08 10:02:18 mailgw1 postfix/smtpd[930587]: NOQUEUE: reject: RCPT 
from mail-db8eur05on2056.outbound.protection.outlook.com[40.107.20.56]: 
554 5.7.1 Service unavailable; Client host [40.107.20.56] blocked using 
bl.spamcop.net; Blocked - see 
https://www.spamcop.net/bl.shtml?40.107.20.56; 
from= to= proto=ESMTP 
helo=


and this causes legitimate mail to be discarded (actual mail addresses 
modified above).


My question in this case: If I understand right, it seems that 
postscreen allows the client connection even though it is listed because 
it uses a cache which serves as a useful buffer; however the client is 
subsequently blocked by reject_rbl_client restrictions.


So, it seems I should I entirely remove the reject_rbl_client filters 
(from smtpd_recipient_restrictions) as they are already listed with 
postscreen.


It appears to me that using rbl services both with postscreen and 
smtpd_recipient_restrictions is actually pointless and causes double 
lookups which in the end make things worse. Postscreen is sufficient and 
better in filtering with rbl services. Am I right?


Thanks a lot,
Nick
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Warnings related to TLS and hostnames not resolving to IP

[Nikolaos Milas via Postfix-users]

Hello,

I would like to ask your help to find out how to best resolve the 
following warnings. We are having a lot of such warnings; here is a sample:


...
Jun 29 06:07:33 mailgw1 postfix/smtpd[471365]: warning: hostname 
chg.server1.ideacentral.com does not resolve to address 173.236.106.135
Jun 29 06:07:35 mailgw1 postfix/smtpd[471363]: warning: hostname 
chg.server1.ideacentral.com does not resolve to address 173.236.106.135
Jun 29 06:07:35 mailgw1 postfix/smtpd[471355]: warning: hostname 
chg.server1.ideacentral.com does not resolve to address 173.236.106.135
Jun 29 06:07:51 mailgw1 postfix/smtpd[471355]: warning: hostname 
chg.server1.ideacentral.com does not resolve to address 173.236.106.135
Jun 29 06:07:54 mailgw1 postfix/postscreen[469582]: warning: dnsblog 
reply timeout 10s for dnsbl.sorbs.net
Jun 29 06:15:15 mailgw1 postfix/smtpd[471389]: warning: TLS library 
problem: error:14209102:SSL 
routines:tls_early_post_process_client_hello:unsupported 
protocol:ssl/statem/statem_srvr.c:1686:
Jun 29 07:00:02 mailgw1 postfix/smtpd[472286]: warning: TLS library 
problem: error:14209102:SSL 
routines:tls_early_post_process_client_hello:unsupported 
protocol:ssl/statem/statem_srvr.c:1686:
Jun 29 07:15:13 mailgw1 postfix/smtpd[472304]: warning: TLS library 
problem: error:14209102:SSL 
routines:tls_early_post_process_client_hello:unsupported 
protocol:ssl/statem/statem_srvr.c:1686:
Jun 29 07:31:16 mailgw1 postfix/tlsproxy[473032]: warning: TLS library 
problem: error:14209102:SSL 
routines:tls_early_post_process_client_hello:unsupported 
protocol:ssl/statem/statem_srvr.c:1686:
Jun 29 07:43:27 mailgw1 postfix/smtpd[473022]: warning: hostname 
list.paperssubmt.com does not resolve to address 185.227.110.51
Jun 29 08:00:02 mailgw1 postfix/smtpd[473096]: warning: TLS library 
problem: error:14209102:SSL 
routines:tls_early_post_process_client_hello:unsupported 
protocol:ssl/statem/statem_srvr.c:1686:

...

My question: How should I best configure postfix to get rid of these 
warnings?


1. Is it normal/acceptable to have hostnames not resolving to the IP 
Address? Should we drop such connections? If so, how?


2. The TLS errors are caused by clients with older TLS protocols (as we 
allow only TLS 1.2 or 1.3) or we should investigate some OpenSSL library 
misbehavior? In any case, which TLS settings would you advise from 
experience?


Below I add details about the system.

Please kindly provide your advice on the above.

Thanks a lot,
Nick


# cat /etc/redhat-release
Rocky Linux release 8.8 (Green Obsidian)

# rpm -qa | grep ssl
openssl-1.1.1k-9.el8_7.x86_64
openssl-pkcs11-0.4.10-3.el8.x86_64
openssl-libs-1.1.1k-9.el8_7.x86_64


[root@mailgw1 postfix]# postconf -n
allowed_list1 = reject
allowed_list2 = reject
command_directory = /usr/sbin
compatibility_level = 3.6
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 = 100
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 ICXC-NIKA
mail_owner = postfix
maillog_file = /var/log/postfix.log
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 15728640
meta_directory = /etc/postfix
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 = zen.spamhaus.org*3 b.barracudacentral.org*2 
bl.spameatingmonkey.net*2 bl.spamcop.net dnsbl.sorbs.net 
psbl.surriel.com bl.mailspike.net list.dnswl.org=127.0.[0..255].0*-2 
list.dnswl.org=127.0.[0..255].1*-3 list.dnswl.org=127.0.[0..255].[2..3]*-4

postscreen_dnsbl_threshold = 3
postscreen_dnsbl_whitelist_threshold = -1
postscreen_greet_action = enforce
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix3-3.8.1/README_FILES
relay_domains = $transport_maps
relay_recipient_maps =
sample_directory = /usr/share/doc/postfix3-3.8.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib/postfix
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_protocols = >=TLSv1.2
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_recipient_restrictions = check_client_access 
hash:/etc/postfix/blacklisted_clients check_client_access 
hash:/etc/postfix/amavis_bypass_clients check_sender_access 
hash:/etc/postfix/amavis_bypass_senders check_sender_access 

Re: Local relay delivery delays on particular mails

[Nikolaos Milas]

On 8/6/2022 11:55 p.m., Viktor Dukhovni wrote:

The milter may be performing DKIM signature checks on inbound mail,
signing would be only for outbound.  DKIM signature checks may involve
DNS lookups, which could introduce some latency if the remote zone is
uncooperative.

On 9/6/2022 2:41 a.m., Wietse Venema wrote:

I agree that DKIM is unlikely to use upo 255 seconds even if
you had turned on signature checks by mistake.


Based on your comments (and based on our current postfix config, which 
is simple) I focused on checking the OpenDKIM config, as a serious 
candidate of being responsible for the delays.


I noticed that our incoming mails had DKIM verification signatures from 
both servers (mailgw1 AND vmail2) which was not right. There is no point 
in verifying DKIM signature twice.


So, yes, I had mistakenly turned on signature checking on vmail2.

Additionally, the usual delay was around 4 minutes, which is consistent 
with the 255 seconds timeout you mentioned.


I turned off signature checking on vmail2 and *delays stopped occurring*!

It seems that something in DKIM signature verification process was 
causing OpenDKIM to stall when analyzing particular domains.


(Note that DKIM signature checking on mailgw1 through amavis does not 
cause any issues whatsoever.)


OpenDKIM logs did not reveal any details regarding the messages with 
earlier delays; only the final successful signing event was logged.


I did not try to re-enable (unneeded) signature verification and 
increasing OpenDKIM log level in an effort to discover more details on 
the issue; therefore I can't tell what exactly may have been the cause 
of failures on particular domains. Since it is a production server, it 
is not easy to make a decision to re-introduce mail delivery delays to 
end-users in order to do further experiments.


Yet, it is clear that the delay was induced by OpenDKIM sig verification 
process.


I do appreciate and thank you both Wietse and Victor for the precious 
insight you have provided on postfix message processing at various 
stages and your commendable kindness in devoting your effort to help me, 
even though I am not a mail expert! I would have surely needed your 
further guidance to configure postfix in a way that would allow me to 
carry out the step-by-step analysis you advised if it had proved necessary.


All the best,
Nick

Re: Local relay delivery delays on particular mails

[Nikolaos Milas]

On 8/6/2022 5:44 μ.μ., Wietse Venema wrote:

Possible causes (there may be more):

- There is a problem with the network connection between mailgw1
and mailgw1 that causes some connections to have excessive retries.
This could be a data-dependent problem. About 20 years ago, someone
fixed a Postfix networking problem by replacing bad network hardware
(a different port on a switch).

- There is a problem in the file system that causes delays in the
fsync() system call. Postfix will not reply that the mesasage has
been "received" before that system call completes successfully. If
you are using a networked file system, see my previous point. fsync()
performance also depends on how a disk drive manages its cache.

- vmail2 is using header_checks, body_checks, or smtpd_milters that
take an insane amount of time.  These are by their nature data-dependent.
Sorry, no time to examine up your Postfix configuration.


Thank you Wietse for this analysis.

My big question is why this happens *ONLY* to particular messages, esp. 
those originating from wetransfer.com and sharepointonline.com, and it 
happens *consistently* to those.


If there was a system / OS issue, it would occur randomly on various 
messages (from various sender domains). But in fact the phenomenon is 
very selective and directly associated with particular sender domains.


For example, two more such sender domains (where delays also occur, and 
do so consistently) are apmascongress.org and uea.ac.uk.


These messages (with delays) are a *very* small percentage of the total 
mail we receive.


Moreover, we don't do any header / body  etc checks. All such checks 
have been performed during amavis examination at mailgw1. We only 
deliver mail to the final recipient.


As I wrote to Victor, the only milter is the DKIM signing one, used for 
outgoing messages.


How could we further investigate the issue, e.g. by more thoroughly 
(i.e. in high detail) logging postifx activity on mails from those domains?


If needed, I can provide more extended logs for your analysis.

Please advise! I am out of ideas.

Thanks again,
Nick

Re: Local relay delivery delays on particular mails

[Nikolaos Milas]

On 8/6/2022 4:57 μ.μ., Viktor Dukhovni wrote:

...

The delay was in processing the message body and/or alerting the queue
manager to the arrival of the new message.  Are you using milters that
query remote oracles (perhaps DNS?) in order to determine whether the
message content is acceptable?  Perhaps there are many URLs in the
message that result in many slow remote lookups?


Thanks Victor for the reply,

Some answers follow inline:

We are not using any milters except the one you mentioned, for DKIM signing.

For your reference, I am attaching (zipped) the whole message from 
wetransfer for which I earlier posted the delivery log (with mail local 
parts changed consistently, and with wetransfer true download links 
scrambled consistently).


You can study the mail content at your convenience.




Jun 08 11:52:48 vmail2 postfix/smtpd[10619]: disconnect from
mailgw1.noa.gr[2001:648:2ffc:1115::27] ehlo=2 starttls=1 mail=1 rcpt=1
data=1 quit=1 commands=7

Either transmission was slow, or body processing (milters, header
checks, body checks, ...) was slow, since the SMTP dialogue ended
late.  If the queue is draining slowly, this could be related to
"inflow_delay" kicking in when message arrival outpaces delivery.


If it is message-related, you may tell from the message source I am 
attaching.


If not, why this phenomenon does not occur with other messages?




smtpd_end_of_data_restrictions = check_client_access
cidr:/etc/postfix/postfwdpolicy.cidr

Could this be slow?


It's fairly simple:

   # cat /etc/postfix/postfwdpolicy.cidr
   127.0.0.1   DUNNO
   [::1]   DUNNO
   195.251.204.12  gwcheck
   [2001:648:2ffc:1115::27]    gwcheck
   83.212.5.27 gwcheck
   [2001:648:2ffc:126::2]  gwcheck
   62.217.124.2    gwcheck
   [2001:648:2011:8010::213]   gwcheck
   195.251.204.213 gwcheck
   195.251.204.211 DUNNO
   [2001:648:2011:8010::211]   DUNNO
   195.251.204.212 DUNNO
   [2001:648:2011:8010::212]   DUNNO
   194.177.195.36  DUNNO
   195.251.204.238 DUNNO
   [2001:648:2011:10::238] DUNNO
   195.251.203.238 DUNNO
   [2001:648:2011:3::238]  DUNNO
   10.201.14.48    DUNNO
   0.0.0.0/0   postfwdcheck
   [::]/0  postfwdcheck

So, for messages from mailgw1.noa.gr we apply:

   [2001:648:2ffc:1115::27]    gwcheck
   83.212.5.27 gwcheck

which is:

gwcheck = reject_unverified_recipient, reject_unauth_destination




milter_default_action = accept
non_smtpd_milters = $smtpd_milters
smtpd_milters = inet:127.0.0.1:8891

What does this milter do?


That's for DKIM signing, as I mentioned above.

Any ideas?

Thanks again,
Nick
<>

Local relay delivery delays on particular mails

[Nikolaos Milas]

Hello,

In our setup we have two mail gateway servers accepting incoming mail 
(mailgw1.noa.gr [primary] and mailgw3.noa.gr - both RockyLinux 8 on VPS 
with 2 CPUs, 6GB RAM), filtering mail (using postscreen, amavis, 
spamassassin, clamav) and forwarding to the internal mail server 
(vmail2.noa.gr - CentOS 7 with 1 CPU and 5GB RAM) where user mailboxes lie.


All servers are running postfix 3.7.0.

I am trying to find out why some mails delivered from mailgw1.noa.gr to 
vmail2.noa.gr are delayed around 4 (and up to 7) minutes, while ALL 
other messages are delivered consistently within a couple of seconds.


This mainly happens consistently with mail from wetransfer and 
sharepoint servers.


As you will see, amavis on mailgw1 receives (at port 10024) from postfix 
and processes messages *quickly* and returns them back to postfix (at 
port 10025) immediately for final delivery. Postfix however delivers the 
message to vmail2.noa.gr after ~4 minutes. This does NOT happen with 
other mail, nor there is any special load that would justify delays. 
This behavior is driving me nuts.


Am I missing something?

Here is one such mail from wetransfer (copied from collated logs, 
destination address local part modified):


=== 



On mailgw1.noa.gr:

Jun 08 11:48:29 mailgw1 postfix/smtpd[379212]: connect from 
o5.email.wetransfer.com[167.89.35.243]
Jun 08 11:48:30 mailgw1 postfix/smtpd[379212]: Anonymous TLS connection 
established from o5.email.wetransfer.com[167.89.35.243]: TLSv1.3 with 
cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 
server-signature RSA-PSS (4096 bits) server-digest SHA256
Jun 08 11:48:31 mailgw1 postfix/smtpd[379212]: 4LJ18v2F3zzM587: 
client=o5.email.wetransfer.com[167.89.35.243]
Jun 08 11:48:31 mailgw1 postfix/cleanup[380438]: 4LJ18v2F3zzM587: 
message-id=
Jun 08 11:48:31 mailgw1 postfix/qmgr[372611]: 4LJ18v2F3zzM587: 
from=, 
size=43976, nrcpt=1 (queue active)
Jun 08 11:48:32 mailgw1 postfix/smtpd[379212]: disconnect from 
o5.email.wetransfer.com[167.89.35.243] ehlo=2 starttls=1 mail=1 rcpt=1 
data=1 quit=1 commands=7
Jun 08 11:48:33 mailgw1 postfix/lmtp[380474]: 4LJ18v2F3zzM587: 
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=2.7, 
delays=1.3/0/0/1.4, dsn=2.0.0, status=sent (250 2.0.0 from 
MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4LJ18x2TQSzM58J)

Jun 08 11:48:33 mailgw1 postfix/qmgr[372611]: 4LJ18v2F3zzM587: removed

Jun 08 11:48:33 mailgw1 postfix/smtpd[379124]: connect from 
localhost[127.0.0.1]
Jun 08 11:48:33 mailgw1 postfix/smtpd[379124]: 4LJ18x2TQSzM58J: 
client=localhost[127.0.0.1]
Jun 08 11:48:33 mailgw1 postfix/cleanup[380469]: 4LJ18x2TQSzM58J: 
message-id=
Jun 08 11:48:33 mailgw1 postfix/qmgr[372611]: 4LJ18x2TQSzM58J: 
from=, 
size=44853, nrcpt=1 (queue active)
Jun 08 11:48:33 mailgw1 postfix/smtpd[379124]: disconnect from 
localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
Jun 08 11:52:48 mailgw1 postfix/smtp[380422]: 4LJ18x2TQSzM58J: 
to=, relay=vmail2.noa.gr[2001:648:2011:15::166]:25, 
delay=255, delays=0.01/0/0.05/255, dsn=2.0.0, status=sent (250 2.0.0 Ok: 
queued as 671E9804DEE08)

Jun 08 11:52:48 mailgw1 postfix/qmgr[372611]: 4LJ18x2TQSzM58J: removed

On vmail2.noa.gr:

Jun 08 11:48:33 vmail2 postfix/smtpd[10619]: connect from 
mailgw1.noa.gr[2001:648:2ffc:1115::27]
Jun 08 11:48:33 vmail2 postfix/smtpd[10619]: Anonymous TLS connection 
established from mailgw1.noa.gr[2001:648:2ffc:1115::27]: TLSv1.3 with 
cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-

exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
Jun 08 11:48:33 vmail2 postfix/smtpd[10619]: 671E9804DEE08: 
client=mailgw1.noa.gr[2001:648:2ffc:1115::27]
Jun 08 11:48:33 vmail2 postfix/cleanup[10742]: 671E9804DEE08: 
message-id=
Jun 08 11:52:48 vmail2 postfix/qmgr[30346]: 671E9804DEE08: 
from=, 
size=45294, nrcpt=1 (queue active)
Jun 08 11:52:48 vmail2 postfix/smtpd[10619]: disconnect from 
mailgw1.noa.gr[2001:648:2ffc:1115::27] ehlo=2 starttls=1 mail=1 rcpt=1 
data=1 quit=1 commands=7
Jun 08 11:52:48 vmail2 postfix/lmtp[17935]: 671E9804DEE08: 
to=, relay=vmail2.noa.gr[private/dovecot-lmtp], delay=255, 
delays=255/0.003/0.001/0.016, dsn=2.0.0, status=sent (250 2.0.0 
 SIJZCWBjoGIQRgAAcV+qjQ Saved)

Jun 08 11:52:48 vmail2 postfix/qmgr[30346]: 671E9804DEE08: removed

===


Another one from sharepoint (copied from collated logs, destination 
address local part modified):


===

On mailgw1.noa.gr:

Jun 08 12:19:27 mailgw1 postfix/smtpd[380489]: connect from 
mail-eopbgr10114.outbound.protection.outlook.com[40.107.1.114]
Jun 08 12:19:28 

Re: "Alternating" IPv4 / IPv6 connections

[Nikolaos Milas]

On 9/5/2022 3:39 μ.μ., Nikolaos Milas wrote:

As an example I am listing below some successive log entries 
(collated, usernames modified). 


For your reference, I am posting below the log entries (usernames 
modified consistently) of the same sessions (which I listed in my 
original message), as logged at mailgw1.noa.gr


(You will notice that each session includes local delivery to amavis and 
return back for final deliver to vmail2.noa.gr):


May 03 07:23:50 mailgw1 postfix/smtpd[195932]: connect from 
a10-227.smtp-out.amazonses.com[54.240.10.227]
May 03 07:23:51 mailgw1 postfix/smtpd[195932]: Anonymous  connection 
established from a10-227.smtp-out.amazonses.com[54.240.10.227]: TLSv1.2 
with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)
May 03 07:23:51 mailgw1 postfix/smtpd[195932]: 4Ksn0768SXzLyyK: 
client=a10-227.smtp-out.amazonses.com[54.240.10.227]
May 03 07:23:52 mailgw1 postfix/cleanup[196401]: 4Ksn0768SXzLyyK: 
message-id=<010001808828f889-bcb7b94b-b241-41c4-879f-353d04ea2966-000...@email.amazonses.com>
May 03 07:23:52 mailgw1 postfix/qmgr[193390]: 4Ksn0768SXzLyyK: 
from=<010001808828f889-bcb7b94b-b241-41c4-879f-353d04ea2966-000...@bounce.academia-mail.com>, 
size=61693, nrcpt=1 (queue active)
May 03 07:23:54 mailgw1 postfix/smtpd[196404]: connect from 
localhost[127.0.0.1]
May 03 07:23:54 mailgw1 postfix/smtpd[196404]: 4Ksn0B16bmzM016: 
client=localhost[127.0.0.1]
May 03 07:23:54 mailgw1 postfix/cleanup[196401]: 4Ksn0B16bmzM016: 
message-id=<010001808828f889-bcb7b94b-b241-41c4-879f-353d04ea2966-000...@email.amazonses.com>
May 03 07:23:54 mailgw1 postfix/qmgr[193390]: 4Ksn0B16bmzM016: 
from=<010001808828f889-bcb7b94b-b241-41c4-879f-353d04ea2966-000...@bounce.academia-mail.com>, 
size=62726, nrcpt=1 (queue active)
May 03 07:23:54 mailgw1 postfix/lmtp[196406]: 4Ksn0768SXzLyyK: 
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=2.8, 
delays=0.95/0/0.01/1.8, dsn=2.0.0, status=sent (250 2.0.0 from 
MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4Ksn0B16bmzM016)

May 03 07:23:54 mailgw1 postfix/qmgr[193390]: 4Ksn0768SXzLyyK: removed
May 03 07:23:54 mailgw1 postfix/smtpd[196404]: connect from 
localhost[127.0.0.1]
May 03 07:23:54 mailgw1 postfix/smtpd[196404]: 4Ksn0B16bmzM016: 
client=localhost[127.0.0.1]
May 03 07:23:54 mailgw1 postfix/cleanup[196401]: 4Ksn0B16bmzM016: 
message-id=<010001808828f889-bcb7b94b-b241-41c4-879f-353d04ea2966-000...@email.amazonses.com>
May 03 07:23:54 mailgw1 postfix/qmgr[193390]: 4Ksn0B16bmzM016: 
from=<010001808828f889-bcb7b94b-b241-41c4-879f-353d04ea2966-000...@bounce.academia-mail.com>, 
size=62726, nrcpt=1 (queue active)
May 03 07:23:54 mailgw1 postfix/smtp[196405]: 4Ksn0B16bmzM016: 
to=, relay=vmail2.noa.gr[2001:648:2011:15::166]:25, 
delay=0.41, delays=0.05/0/0.04/0.32, dsn=2.0.0, status=sent (250 2.0.0 
Ok: queued as 3EA3681E8C1DE)

May 03 07:23:54 mailgw1 postfix/qmgr[193390]: 4Ksn0B16bmzM016: removed

May 03 07:24:15 mailgw1 postfix/smtpd[195934]: connect from 
66-220-155-141.mail-mail.facebook.com[66.220.155.141]
May 03 07:24:15 mailgw1 postfix/smtpd[195934]: Anonymous TLS connection 
established from 66-220-155-141.mail-mail.facebook.com[66.220.155.141]: 
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange 
X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
May 03 07:24:15 mailgw1 postfix/smtpd[195934]: 4Ksn0b6C9dzLyyK: 
client=66-220-155-141.mail-mail.facebook.com[66.220.155.141]
May 03 07:24:16 mailgw1 postfix/cleanup[196401]: 4Ksn0b6C9dzLyyK: 
message-id=
May 03 07:24:16 mailgw1 postfix/qmgr[193390]: 4Ksn0b6C9dzLyyK: 
from=, size=24266, nrcpt=1 (queue active)
May 03 07:24:17 mailgw1 postfix/smtpd[195932]: disconnect from 
a10-227.smtp-out.amazonses.com[54.240.10.227] ehlo=2 starttls=1 mail=1 
rcpt=1 data=1 quit=1 commands=7
May 03 07:24:17 mailgw1 postfix/smtpd[196411]: connect from 
localhost[127.0.0.1]
May 03 07:24:17 mailgw1 postfix/smtpd[196411]: 4Ksn0d20kHzM019: 
client=localhost[127.0.0.1]
May 03 07:24:17 mailgw1 postfix/cleanup[196401]: 4Ksn0d20kHzM019: 
message-id=
May 03 07:24:17 mailgw1 postfix/qmgr[193390]: 4Ksn0d20kHzM019: 
from=, size=25399, nrcpt=1 (queue active)
May 03 07:24:17 mailgw1 postfix/lmtp[196402]: 4Ksn0b6C9dzLyyK: 
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.7, 
delays=0.5/0/0.01/1.2, dsn=2.0.0, status=sent (250 2.0.0 from 
MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4Ksn0d20kHzM019)

May 03 07:24:17 mailgw1 postfix/qmgr[193390]: 4Ksn0b6C9dzLyyK: removed
May 03 07:24:17 mailgw1 postfix/smtp[196405]: 4Ksn0d20kHzM019: 
to=, relay=vmail2.noa.gr[2001:648:2011:15::166]:25, 
delay=0.16, delays=0.01/0/0.04/0.1, dsn=2.0.0, status=sent (250 2.0.0 
Ok: queued as 5415981E8C1DE)

May 03 07:24:17 mailgw1 postfix/qmgr[193390]: 4Ksn0d20kHzM019: removed


May 03 07:24:22 mailgw1 postfix/smtpd[195934]: connect from 
mx0a-0d04.pphosted.com[148.163.149.245]
May 03 07:24:23 mailgw1 postfix/smtpd[195934]: Anonymous TLS connection 
established from mx0a-0d04.pp

Re: "Alternating" IPv4 / IPv6 connections

[Nikolaos Milas]

On 9/5/2022 3:39 μ.μ., Nikolaos Milas wrote:
In our setup we have two mail gateway servers accepting incoming mail 
(mailgw1.noa.gr [primary] and mailgw3.noa.gr), filtering mail (using 
postscreen, amavis, spamassassin, clamav) and forwarding to the 
internal mail server (vmail2.noa.gr) where user mailboxes lie.

...


Transport is configured as follows (on mailgw1 and mailgw3 servers):

/etc/postfix/transportmap:

noa.gr  relay:[vmail2.noa.gr]
admin.noa.gr    relay:[vmail2.noa.gr]
nestor.noa.gr   relay:[vmail2.noa.gr]
space.noa.gr    relay:[vmail2.noa.gr]
meteo.noa.gr    relay:[vmail2.noa.gr]
gein.noa.gr relay:[vmail2.noa.gr]
technet.noa.gr  relay:[vmail2.noa.gr]
astro.noa.gr    relay:[vmail2.noa.gr]
hesperia-space.eu   relay:[vmail2.noa.gr]

If any additional information is required, I will be happy to share it 
with you.


Thanks,
Nick

"Alternating" IPv4 / IPv6 connections

[Nikolaos Milas]

Hello,

In our setup we have two mail gateway servers accepting incoming mail 
(mailgw1.noa.gr [primary] and mailgw3.noa.gr), filtering mail (using 
postscreen, amavis, spamassassin, clamav) and forwarding to the internal 
mail server (vmail2.noa.gr) where user mailboxes lie.


All servers are running postfix 3.7.0.

I am trying to investigate why our mail gateway servers (mailgw1 and 
mailgw3) sometimes connect over IPv6 and some other times connect over 
IPv4 to deliver mail to vmail2.


As an example I am listing below some successive log entries (collated, 
usernames modified).


Why does this happen? I would expect all connections to be made using 
IPv6, since it is preferred over IPv4. Why all connections do not use IPv6?


Can you please help me to understand and correct any settings if/where 
needed?


At the bottom I list the output of postconf -n for mailgw1 and vmail2.

Log entries follow:

May 03 07:23:54 vmail2 postfix/smtpd[24699]: connect from 
mailgw1.noa.gr[2001:648:2ffc:1115::27]
May 03 07:23:54 vmail2 postfix/smtpd[24699]: Anonymous TLS connection 
established from mailgw1.noa.gr[2001:648:2ffc:1115::27]: TLSv1.3 with 
cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 
server-signature RSA-PSS (4096 bits) server-digest SHA256
May 03 07:23:54 vmail2 postfix/smtpd[24699]: 3EA3681E8C1DE: 
client=mailgw1.noa.gr[2001:648:2ffc:1115::27]
May 03 07:23:54 vmail2 postfix/cleanup[22675]: 3EA3681E8C1DE: 
message-id=<010001808828f889-bcb7b94b-b241-41c4-879f-353d04ea2966-000...@email.amazonses.com>
May 03 07:23:54 vmail2 postfix/qmgr[27646]: 3EA3681E8C1DE: 
from=<010001808828f889-bcb7b94b-b241-41c4-879f-353d04ea2966-000...@bounce.academia-mail.com>, 
size=63158, nrcpt=1 (queue active)
May 03 07:23:54 vmail2 postfix/smtpd[24699]: disconnect from 
mailgw1.noa.gr[2001:648:2ffc:1115::27] ehlo=2 starttls=1 mail=1 rcpt=1 
data=1 quit=1 commands=7
May 03 07:23:54 vmail2 postfix/lmtp[22677]: 3EA3681E8C1DE: 
to=, relay=vmail2.noa.gr[private/dovecot-lmtp], 
delay=0.35, delays=0.31/0.002/0.001/0.034, dsn=2.0.0, status=sent (250 
2.0.0  YC2SIVqucGJvYgAAcV+qjQ Saved)

May 03 07:23:54 vmail2 postfix/qmgr[27646]: 3EA3681E8C1DE: removed

May 03 07:24:17 vmail2 postfix/smtpd[24699]: connect from 
mailgw1.noa.gr[2001:648:2ffc:1115::27]
May 03 07:24:17 vmail2 postfix/smtpd[24699]: Anonymous TLS connection 
established from mailgw1.noa.gr[2001:648:2ffc:1115::27]: TLSv1.3 with 
cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 
server-signature RSA-PSS (4096 bits) server-digest SHA256
May 03 07:24:17 vmail2 postfix/smtpd[24699]: 5415981E8C1DE: 
client=mailgw1.noa.gr[2001:648:2ffc:1115::27]
May 03 07:24:17 vmail2 postfix/cleanup[22675]: 5415981E8C1DE: 
message-id=
May 03 07:24:17 vmail2 postfix/qmgr[27646]: 5415981E8C1DE: 
from=, size=25840, nrcpt=1 (queue active)
May 03 07:24:17 vmail2 postfix/smtpd[24699]: disconnect from 
mailgw1.noa.gr[2001:648:2ffc:1115::27] ehlo=2 starttls=1 mail=1 rcpt=1 
data=1 quit=1 commands=7
May 03 07:24:17 vmail2 postfix/lmtp[22677]: 5415981E8C1DE: 
to=, relay=vmail2.noa.gr[private/dovecot-lmtp], 
delay=0.1, delays=0.093/0.001/0.001/0.008, dsn=2.0.0, status=sent (250 
2.0.0  aEf1GXGucGJvYgAAcV+qjQ Saved)

May 03 07:24:17 vmail2 postfix/qmgr[27646]: 5415981E8C1DE: removed

May 03 07:24:26 vmail2 postfix/smtpd[24699]: connect from 
mailgw1.noa.gr[83.212.5.27]
May 03 07:24:26 vmail2 postfix/smtpd[24699]: Anonymous TLS connection 
established from mailgw1.noa.gr[83.212.5.27]: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 
server-signature RSA-PSS (4096 bits) server-digest SHA256
May 03 07:24:26 vmail2 postfix/smtpd[24699]: 0FE2A81E8C1DE: 
client=mailgw1.noa.gr[83.212.5.27]
May 03 07:24:26 vmail2 postfix/cleanup[22675]: 0FE2A81E8C1DE: 
message-id=<20220503042418.138f63f...@cl2n038.stanford.edu>
May 03 07:24:26 vmail2 postfix/qmgr[27646]: 0FE2A81E8C1DE: 
from=, size=4807, nrcpt=3 (queue active)
May 03 07:24:26 vmail2 postfix/smtpd[24699]: disconnect from 
mailgw1.noa.gr[83.212.5.27] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 
quit=1 commands=7
May 03 07:24:26 vmail2 postfix/lmtp[22677]: 0FE2A81E8C1DE: 
to=, orig_to=, 
relay=vmail2.noa.gr[private/dovecot-lmtp], delay=0.18, 
delays=0.056/0.003/0.001/0.12, dsn=2.0.0, status=sent (250 2.0.0 
 uABAB3qucGJvYgAAcV+qjQ Saved)

May 03 07:24:26 vmail2 postfix/qmgr[27646]: 0FE2A81E8C1DE: removed

May 03 07:24:40 vmail2 postfix/smtpd[24699]: connect from 
mailgw1.noa.gr[83.212.5.27]
May 03 07:24:40 vmail2 postfix/smtpd[24699]: Anonymous TLS connection 
established from mailgw1.noa.gr[83.212.5.27]: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 
server-signature RSA-PSS (4096 bits) server-digest SHA256
May 03 07:24:40 vmail2 postfix/smtpd[24699]: DC30681E8C1DE: 
client=mailgw1.noa.gr[83.212.5.27]
May 03 07:24:40 vmail2 postfix/cleanup[22675]: DC30681E8C1DE: 
message-id=
May 03 07:24:41 vmail2 postfix/qmgr[27646]: DC30681E8C1DE: 
from=, size=4638210, nrcpt=1 (queue active)

Re: Mail and mail traces lost (?)

[Nikolaos Milas]

On 30/3/2022 8:12 μ.μ., Michael Ströder wrote:


On 3/30/22 18:36, Viktor Dukhovni wrote:

On Wed, Mar 30, 2022 at 06:11:33PM +0200, Michael Ströder wrote:


Or simply set in /etc/systemd/journald.conf:

[Journal]
Storage=none
ForwardToSyslog=yes


That does not fully solve the problem, since IIRC rate limits and
performance limitations still apply, perhaps somewhat improved for the
latter.


And make sure journald does not listen on /dev/log and your favourite
syslog demon listens there.


I don't recall seeing a way to do that, is that configurable?


It's a systemd socket unit creating a symlink:

# systemctl cat systemd-journald-dev-log.socket

[..]
[Socket]
ListenDatagram=/run/systemd/journal/dev-log
[..]
Symlinks=/dev/log


I am a bit confused (not surprisingly, as I am no expert).

In my CentOS 7,in /usr/lib/systemd/system/systemd-journald.socket I see:

[Socket]
ListenStream=/run/systemd/journal/stdout
ListenDatagram=/run/systemd/journal/socket
ListenDatagram=/dev/log
SocketMode=0666
PassCredentials=yes
PassSecurity=yes
ReceiveBuffer=8M

So, in order to achieve logging directly to syslog rather than to the 
systemd journal would we remove the ListenDatagram=/dev/log entry and 
leave the rest untouched?


Would this change affect only services configured to use the journal for 
logging? I mean would this change affect services that are already 
configured to use directly syslog?


Thanks a lot,
Nick

Re: Mail and mail traces lost (?)

[Nikolaos Milas]

On 30/3/2022 7:04 μ.μ., Viktor Dukhovni wrote:


Consider a Linux distribution that does not use systemd, or a recent
version of Postfix that writes its own log files bypassing syslog.


Thanks Victor,

The latter is a more feasible scenario.

I guess you are referring to the maillog_file* set of directives, 
available with Postfix v3.4 and later.


Thanks for the hint!

All the best,
Nick

Re: Mail and mail traces lost (?)

[Nikolaos Milas]

On 30/3/2022 4:56 μ.μ., Nikolaos Milas wrote:

In the meantime, I have identified more mails that users considered 
delivered successfully, but there is no sign of them in the logs; we 
should conclude that these mails were in fact not sent/received at all?


Answering my own question, apparently mail (I cannot determine if ALL of 
it) IS in fact getting delivered, even if not logged in all cases.


Answering to Victor, who replied to me in the meantime and provided 
valuable hints, esp. about the journal, I found that mail that is NOT 
logged in /var/log/maillog IS in fact recorded successfully in the 
systemd journal!


I was wondering if low I/O performance of the virtual Hard Disk could 
lead to log entries not getting written successfully. This VM features a 
large virtual HD (see specs below) that is apparently associated with 
low I/O performance.


I'll have to check how to configure postfix service to NOT use the 
journal but only the rsyslog facility. Would this probably lead to 
having full (i.e. without misses) logging at /var/log/maillog?


For reference:

# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

# uname -r
3.10.0-1160.59.1.el7.x86_64

# mpstat
Linux 3.10.0-1160.59.1.el7.x86_64 (vmail2.noa.gr) 03/30/2022  
_x86_64_    (1 CPU)


05:43:59 PM  CPU    %usr   %nice    %sys %iowait    %irq %soft  %steal  
%guest  %gnice   %idle
05:43:59 PM  all    9.02    0.03    4.09    1.47    0.00 0.17    0.33    
0.00    0.00   84.90


# free -m
  total    used    free  shared buff/cache   
available

Mem:   4797    1036    1167 218 2593    3289
Swap:  4991   0    4991

# df -hT
Filesystem    Type  Size  Used Avail Use% 
Mounted on

devtmpfs  devtmpfs  2.4G 0 2.4G   0% /dev
tmpfs tmpfs 2.4G 0 2.4G   0% 
/dev/shm

tmpfs tmpfs 2.4G  219M 2.2G  10% /run
tmpfs tmpfs 2.4G 0 2.4G   0% 
/sys/fs/cgroup

/dev/mapper/cl-root   xfs   3.0T  1.5T 1.6T  48% /
/dev/vda2 xfs  1014M  311M 704M  31% /boot
10.201.40.34:/data/col1/noc-bkups-1   nfs    19T  9.7T 8.5T  54% 
/mnt/dd2500-1
10.201.40.34:/data/col1/noa-mailboxes nfs    19T  9.7T 8.5T  54% 
/mnt/mailbox-backups
tmpfs tmpfs 480M 0 480M   0% 
/run/user/495
tmpfs tmpfs 480M 0 480M   0% 
/run/user/0


# rpm -qa | grep syslog
rsyslog-8.24.0-57.el7_9.1.x86_64

Many thanks,
Nick

Re: Mail and mail traces lost (?)

[Nikolaos Milas]

On 30/3/2022 4:56 μ.μ., Nikolaos Milas wrote:


...
I actually used postqueue -p to list queue, but I could not identify 
any of the un mail.

...


Correction to my above sentence:

"I actually used postqueue -p to list queue, but I could not identify 
any of the *missing mails*."


By the way, I noticed that all mails I sent TO postfix mailing list were 
NOT logged, but obviously they were delivered successfully.


However, the incoming mails FROM the postfix mailing list were logged.

Nick

Re: Mail and mail traces lost (?)

[Nikolaos Milas]

On 30/3/2022 4:20 μ.μ., Wietse Venema wrote:

- The message was moved to the HOLD queue. It would still show up
with the "mailq" command.


Thank you Wietse,

I actually used postqueue -p to list queue, but I could not identify any 
of the un mail.



- The message was written to the incoming queue, but your file
system is corrupted. Stop Postfix, umount the file system, and keep
running FSCK (or whatever y9our OS calls it) until there are no
more repairs.

Are you using block-level device mirroring?


This is a VM hosted by our VPS provider (using KVM technology, as I 
remember), about which few details are provided here:


https://grnet.gr/en/services/computing-and-storage-services/vima/

Could the problem be isolated to our VM's OS (CentOS 7) and be handled 
by the Guest OS's tools or it could be attributed to the hosting storage 
array and/or hypervisor cluster? In other words could a corruption exist 
in the Virtual File System in the Guest OS or it could be caused by a 
the hypervisor environment?


In the meantime, I have identified more mails that users considered 
delivered successfully, but there is no sign of them in the logs; we 
should conclude that these mails were in fact not sent/received at all?


Thank you for your kind assistance,
Nick

Re: Mail and mail traces lost (?)

[Nikolaos Milas]

On 30/3/2022 3:47 μ.μ., Rob McGee wrote:


syslog_name is your friend.  I noticed none of your log lines had any
syslog_name other than the default. 


Hi Rob,

Everything is (or at least should be) getting logged in /var/log/maillog.

We always find details about any and all mail in this log file.

The problem is that there seems to be a problem with the delivery and/or 
logging of some mails, as with those I have provided logs about.


Any ideas on what is really happening?

Thanks,
Nick

Mail and mail traces lost (?)

[Nikolaos Milas]

Hello,

I am facing the following issue:

I am tracing particular mails. They are delivered (after being filtered 
by amavis) from our mail gateway server (postfix) to our internal 
mailbox server (also postfix).


Here is a full example (collated):

Mar 30 13:06:23 mailgw1 postfix/smtpd[2771407]: connect from 
localhost[127.0.0.1]
Mar 30 13:06:23 mailgw1 postfix/smtpd[2771407]: 4KT2C32sk9zLvyq: 
client=localhost[127.0.0.1]
Mar 30 13:06:33 mailgw1 postfix/smtpd[2771407]: 4KT2CF63YjzLvyq: 
client=localhost[127.0.0.1]
Mar 30 13:06:33 mailgw1 postfix/cleanup[2771510]: 4KT2CF63YjzLvyq: 
message-id=
02d-9232-3ae4d6541e79@RD0050F2A3DEF5>
Mar 30 13:06:33 mailgw1 postfix/qmgr[1272540]: 4KT2CF63YjzLvyq: 
from=, size=12493, nrcpt=1 (queue active)
Mar 30 13:10:48 mailgw1 postfix/smtp[2771425]: 4KT2CF63YjzLvyq: 
to=, relay=vmail2.noa.gr[2001:648:2011:15::166]:25, 
delay=255, delays=0/0.01/0.03/255, dsn=2.0.0, status=sent (250 2.0.0 Ok: 
queued as DB90F8DE9D7CD)

Mar 30 13:10:48 mailgw1 postfix/qmgr[1272540]: 4KT2CF63YjzLvyq: removed

However, in vmail2 logs I cannot find full info about them; for the 
above mail (collated):


Mar 30 13:06:33 vmail2 postfix/smtpd[4021]: connect from 
mailgw1.noa.gr[2001:648:2ffc:1115::27]
Mar 30 13:06:33 vmail2 postfix/smtpd[4021]: Anonymous TLS connection 
established from mailgw1.noa.gr[2001:648:2ffc:1115::27]: TLSv1.2 with 
cipher AECDH-AES256-SHA (256/256 bits)
Mar 30 13:06:33 vmail2 postfix/smtpd[4021]: DB90F8DE9D7CD: 
client=mailgw1.noa.gr[2001:648:2ffc:1115::27]
Mar 30 13:06:33 vmail2 postfix/cleanup[28420]: DB90F8DE9D7CD: 
message-id=
Mar 30 13:12:05 vmail2 postfix/smtpd[4021]: Anonymous TLS connection 
established from mailgw1.noa.gr[83.212.5.27]: TLSv1.2 with cipher 
AECDH-AES256-SHA (256/256 bits)


I also find other seemingly incomplete log entries, like:

Mar 30 12:56:59 vmail2 postfix/smtpd[28291]: connect from 
mailgw1.noa.gr[2001:648:2ffc:1115::27]
Mar 30 12:56:59 vmail2 postfix/smtpd[28291]: Anonymous TLS connection 
established from mailgw1.noa.gr[2001:648:2ffc:1115::27]: TLSv1.2 with 
cipher AECDH-AES256-SHA (256/256 bits)
Mar 30 12:56:59 vmail2 postfix/smtpd[28291]: 7CC8F8DEB18F1: 
client=mailgw1.noa.gr[2001:648:2ffc:1115::27]
Mar 30 12:56:59 vmail2 postfix/cleanup[28468]: 7CC8F8DEB18F1: 
message-id=
Mar 30 13:01:48 vmail2 postfix/smtpd[28291]: Anonymous TLS connection 
established from mailgw1.noa.gr[83.212.5.27]: TLSv1.2 with cipher 
AECDH-AES256-SHA (256/256 bits)


or:

Mar 30 14:49:19 vmail2 postfix/smtpd[16440]: connect from 
mailgw1.noa.gr[83.212.5.27]
Mar 30 14:49:19 vmail2 postfix/smtpd[16440]: Anonymous TLS connection 
established from mailgw1.noa.gr[83.212.5.27]: TLSv1.2 with cipher 
AECDH-AES256-SHA (256/256 bits)
Mar 30 14:49:19 vmail2 postfix/smtpd[16440]: 75D088AE65A8A: 
client=mailgw1.noa.gr[83.212.5.27]
Mar 30 14:49:19 vmail2 postfix/cleanup[16080]: 75D088AE65A8A: 
message-id=


It seems as if these mails are not delivered successfully, but I cannot 
see them in any queue either.


How can I troubleshoot these? What may be going wrong?

Please also note that I also had a report by a user that a mail was sent 
by the same server (vmail2, which is our org's SMTP server) seemingly 
successfully, but I could not find any info in the log about it, nor it 
was ever delivered.


Any help in troubleshooting the issue are appreciated!

Thanks,
Nick

Re: Continuous quick connects / disconnects from some servers

[Nikolaos Milas]

On 4/3/2022 8:55 μ.μ., Bill Cole wrote:

...
Right now, vmail2.noa.gr has no MX record and the IPv4 address for it (which is 
what would be used without any MX) is not accepting connections on port 25, so 
I'm not 100% sure how that relates to this, i.e. it looks like you're already 
dropping port 25 traffic inbound. So, I'm not sure that I understand the 
question correctly...
...
It is also safe, and considered a best practice, to disable authentication on 
port 25 because authenticated mail should be coming in on port 587 or 465.
...


Hi Bill,

Thank you for the analysis. I do appreciate your time.

I decided to drop world connections to port 25 today after Matus' 
feedback (and my poor analysis of the situation), so most probably you 
checked shortly after I did the change.


With regard to disabling AUTH on port 25 only - we need to let AUTH 
available on submission port (587) - what exactly should I do? Would it 
be enough to remove "permit_sasl_authenticated" from 
"smtpd_client_restrictions" in main.cf?


Thanks again to you and to everyone who responded.

Nick

Re: Continuous quick connects / disconnects from some servers

[Nikolaos Milas]

On 4/3/2022 10:22 π.μ., Matus UHLAR - fantomas wrote:

...
Other solution would of course be disabling SMTP connections from the 
world.

...


Thank you Matus for all your advice.

Regarding blocking port 25 from the world, couldn't it cause issues when 
communicating to other SMTP servers since this is our SMTP server (for 
outgoing mail)?


Of course, users connect to port 587 to send mail, but aren't there any 
scenarios when the server needs to be contacted directly by other SMTP 
servers around the world? For example, if a remote server wants to send 
a non-deliverable notification for a mail it received from our server 
(vmail2.noa.gr) will it *always* check our zone MX records to reply 
using the mail gateway servers rather than replying directly to the source?


If it's operationally safe, I'd rather block port 25 from outside on 
this server (using iptables).


Please advise!

Thanks again,
Nick

Continuous quick connects / disconnects from some servers

[Nikolaos Milas]

Hello,

I sometimes find abnormal continuous connects/disconnects which delay 
normal mail deliveries.


Here is an example:

Mar  3 10:06:42 vmail2 postfix/smtpd[22733]: connect from 
unknown[45.148.10.243]
Mar  3 10:06:43 vmail2 postfix/smtpd[22733]: lost connection after AUTH 
from unknown[45.148.10.243]
Mar  3 10:06:43 vmail2 postfix/smtpd[22733]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2
Mar  3 10:06:43 vmail2 postfix/smtpd[22730]: warning: hostname 
edc45.app-autht.com does not resolve to address 45.148.10.243: Name or 
service not known
Mar  3 10:06:43 vmail2 postfix/smtpd[22730]: connect from 
unknown[45.148.10.243]
Mar  3 10:06:43 vmail2 postfix/smtpd[22730]: lost connection after AUTH 
from unknown[45.148.10.243]
Mar  3 10:06:43 vmail2 postfix/smtpd[22730]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2
Mar  3 10:06:44 vmail2 postfix/smtpd[22852]: warning: hostname 
edc45.app-autht.com does not resolve to address 45.148.10.243: Name or 
service not known
Mar  3 10:06:44 vmail2 postfix/smtpd[22852]: connect from 
unknown[45.148.10.243]
Mar  3 10:06:44 vmail2 postfix/smtpd[22852]: lost connection after AUTH 
from unknown[45.148.10.243]
Mar  3 10:06:44 vmail2 postfix/smtpd[22852]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2
Mar  3 10:06:45 vmail2 postfix/smtpd[22480]: warning: hostname 
edc45.app-autht.com does not resolve to address 45.148.10.243: Name or 
service not known
Mar  3 10:06:45 vmail2 postfix/smtpd[22480]: connect from 
unknown[45.148.10.243]
Mar  3 10:06:45 vmail2 postfix/smtpd[22480]: lost connection after AUTH 
from unknown[45.148.10.243]
Mar  3 10:06:45 vmail2 postfix/smtpd[22480]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2
Mar  3 10:06:46 vmail2 postfix/smtpd[24089]: warning: hostname 
edc45.app-autht.com does not resolve to address 45.148.10.243: Name or 
service not known
Mar  3 10:06:46 vmail2 postfix/smtpd[24089]: connect from 
unknown[45.148.10.243]
Mar  3 10:06:46 vmail2 postfix/smtpd[24089]: lost connection after AUTH 
from unknown[45.148.10.243]
Mar  3 10:06:46 vmail2 postfix/smtpd[24089]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2
Mar  3 10:06:46 vmail2 postfix/smtpd[24305]: warning: hostname 
edc45.app-autht.com does not resolve to address 45.148.10.243: Name or 
service not known
Mar  3 10:06:46 vmail2 postfix/smtpd[24305]: connect from 
unknown[45.148.10.243]
Mar  3 10:06:47 vmail2 postfix/smtpd[24305]: lost connection after AUTH 
from unknown[45.148.10.243]
Mar  3 10:06:47 vmail2 postfix/smtpd[24305]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2
Mar  3 10:06:47 vmail2 postfix/smtpd[22733]: warning: hostname 
edc45.app-autht.com does not resolve to address 45.148.10.243: Name or 
service not known
Mar  3 10:06:47 vmail2 postfix/smtpd[22733]: connect from 
unknown[45.148.10.243]
Mar  3 10:06:48 vmail2 postfix/smtpd[22733]: lost connection after AUTH 
from unknown[45.148.10.243]
Mar  3 10:06:48 vmail2 postfix/smtpd[22733]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2
Mar  3 10:06:49 vmail2 postfix/smtpd[22730]: warning: hostname 
edc45.app-autht.com does not resolve to address 45.148.10.243: Name or 
service not known
Mar  3 10:06:49 vmail2 postfix/smtpd[22730]: connect from 
unknown[45.148.10.243]
Mar  3 10:06:49 vmail2 postfix/smtpd[22730]: lost connection after AUTH 
from unknown[45.148.10.243]
Mar  3 10:06:49 vmail2 postfix/smtpd[22730]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2
Mar  3 10:06:50 vmail2 postfix/smtpd[22852]: warning: hostname 
edc45.app-autht.com does not resolve to address 45.148.10.243: Name or 
service not known
Mar  3 10:06:50 vmail2 postfix/smtpd[22852]: connect from 
unknown[45.148.10.243]
Mar  3 10:06:50 vmail2 postfix/smtpd[22852]: lost connection after AUTH 
from unknown[45.148.10.243]
Mar  3 10:06:50 vmail2 postfix/smtpd[22852]: disconnect from 
unknown[45.148.10.243] ehlo=1 auth=0/1 commands=1/2
Mar  3 10:06:51 vmail2 postfix/smtpd[22480]: warning: hostname 
edc45.app-autht.com does not resolve to address 45.148.10.243: Name or 
service not known


...and so on.

Would it be legitimate to ban such servers using fail2ban based on:

   lost connection after AUTH

i.e. when there are multiple such entries within few seconds or minutes 
associated with particular servers?


Any other suggestions for dealing with the problem?

Note: This is an internal server (with user mailboxes, also used as our 
SMTP server for outgoing mail), not accepting incoming mail directly but 
from two mail gateway servers - also running postfix - so we are not 
running postscreen on it. Would you suggest running postscreen too? 
Would postscreen help in a situation like the above, if the remote 
server is in some RBL?


Thanks in advance,
Nick

Re: Assembling log entries for each SMTP session

[Nikolaos Milas]

On 21/12/2021 4:00 μ.μ., Matus UHLAR - fantomas wrote:


collate could help you:


Thanks Matus, that's exactly what I needed! You saved my day!

And the best part of it: Collate was already available on my installation.

Simple, flawless and fast.

Cheers,
Nick

Assembling log entries for each SMTP session

[Nikolaos Milas]

Hello,

A quick question: Can you please suggest a software tool which quickly 
"restructures" postfix mail log in a way that lines pertinent to each 
and every SMTP session are assembled and kept together.


We need this because, otherwise, identifying and analyzing particular 
sessions by assembling all pertinent scattered log lines is tedious, 
unproductive and may miss important log lines which could be important 
in troubleshooting issues.


You may have answered this more than once in the past but my research 
did not produce the results I would hope, so please bear with me.


Thanks,
Nick

Re: Communication between postfix - amavis issues

[Nikolaos Milas]

On 8/2/2021 1:38 μ.μ., Matus UHLAR - fantomas wrote:

that's not how milter works, unless you instructed amavisd-milter to 
deliver

mail by server via "-D server" option.

The default is "-D client", which means, amavisd instructs postfix 
what to
do with the mail - reject/quarantine/pass it, add/remove/modify the 
headers

etc.


Hmm, I see. It seems it's running in client mode, because I don't see 
any -D definition, so the default applies.


So, milter delivers mail back to postfix for final delivery?


1. does amavisd-new listen on port 10028?


Yes.

2. IIUC FILTER applies after message is queued - after milter was 
applied.


Testing shows you are right, please read on.


again, FILTER applies after mail is received, so next lines in log should
show how the mail is delivered to amavis on port 10028


Next lines show that the mail is quarantined (it is an EICAR virus-test 
message, which should be quarantined if it does not by-pass through port 
10028, as desired); here is the whole session:


Feb  8 01:54:53 mailgw1 postfix/smtpd[202464]: connect from 
hedgehog.birch.relay.mailchannels.net[23.83.209.81]
Feb  8 01:54:54 mailgw1 postfix/smtpd[202464]: Anonymous TLS connection 
established from hedgehog.birch.relay.mailchannels.net[23.83.209.81]: 
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb  8 01:54:55 mailgw1 postfix/smtpd[202464]: NOQUEUE: filter: RCPT 
from hedgehog.birch.relay.mailchannels.net[23.83.209.81]: 
: Sender address triggers FILTER 
smtp:[127.0.0.1]:10028; from= to= 
proto=ESMTP helo=
Feb  8 01:54:55 mailgw1 postfix/smtpd[202464]: 4DYmH36X5JzLlrw: 
client=hedgehog.birch.relay.mailchannels.net[23.83.209.81]
Feb  8 01:54:56 mailgw1 postfix/cleanup[202468]: 4DYmH36X5JzLlrw: 
message-id=<464576df-43d0-ecac-5647-99c91a95c...@example.com>
Feb  8 01:54:56 mailgw1 postfix/cleanup[202468]: 4DYmH36X5JzLlrw: 
milter-discard: END-OF-MESSAGE from 
hedgehog.birch.relay.mailchannels.net[23.83.209.81]: milter triggers 
DISCARD action; from= to= 
proto=ESMTP helo=
Feb  8 01:54:56 mailgw1 postfix/smtpd[202464]: disconnect from 
hedgehog.birch.relay.mailchannels.net[23.83.209.81] ehlo=2 starttls=1 
mail=1 rcpt=1 data=1 quit=1 commands=7


The message is not honoring the bypass and gets quarantined.

But if I don't send an infected message, the flow is clearer: First the 
message is delivered via the milter, scanned via the normal policy bank, 
and only AFTER that it is examined by the BYPASS policy bank! Here is a 
log:


Feb  8 15:15:00 mailgw1 postfix/smtpd[219538]: connect from 
black.elm.relay.mailchannels.net[23.83.212.19]
Feb  8 15:15:01 mailgw1 postfix/smtpd[219538]: Anonymous TLS connection 
established from black.elm.relay.mailchannels.net[23.83.212.19]: TLSv1.2 
with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb  8 15:15:03 mailgw1 postfix/smtpd[219538]: NOQUEUE: filter: RCPT 
from black.elm.relay.mailchannels.net[23.83.212.19]: 
: Sender address triggers FILTER 
smtp:[127.0.0.1]:10028; from= to= 
proto=ESMTP helo=
Feb  8 15:15:03 mailgw1 postfix/smtpd[219538]: 4DZ62H32SKzLm4t: 
client=black.elm.relay.mailchannels.net[23.83.212.19]
Feb  8 15:15:04 mailgw1 postfix/cleanup[219533]: 4DZ62H32SKzLm4t: 
message-id=<3692cf3d-0de8-fe26-4541-c5876658b...@example.com>
Feb  8 15:15:04 mailgw1 postfix/qmgr[202450]: 4DZ62H32SKzLm4t: 
from=, size=2167, nrcpt=1 (queue active)
Feb  8 15:15:04 mailgw1 postfix/smtpd[219538]: disconnect from 
black.elm.relay.mailchannels.net[23.83.212.19] ehlo=2 starttls=1 mail=1 
rcpt=1 data=1 quit=1 commands=7
Feb  8 15:15:04 mailgw1 postfix/smtp[219543]: 4DZ62H32SKzLm4t: 
to=, relay=127.0.0.1[127.0.0.1]:10028, delay=2.1, 
delays=1.7/0.03/0.06/0.39, dsn=2.0.0, status=sent (250 2.0.0 from 
MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4DZ62J63CZzLm4w)

Feb  8 15:15:04 mailgw1 postfix/qmgr[202450]: 4DZ62H32SKzLm4t: removed

and in Amavis:

Feb  8 15:15:04 mailgw1 amavis[219136]: loaded policy bank "AM.PDP-SOCK"
Feb  8 15:15:04 mailgw1 amavis[219136]: process_request: fileno sock=19, 
STDIN=0, STDOUT=1

Feb  8 15:15:04 mailgw1 amavis[219136]: policy protocol: request=AM.PDP
Feb  8 15:15:04 mailgw1 amavis[219136]: policy protocol: 
queue_id=4DZ62H32SKzLm4t
Feb  8 15:15:04 mailgw1 amavis[219136]: policy protocol: 
sender=
Feb  8 15:15:04 mailgw1 amavis[219136]: policy protocol: 
recipient=
Feb  8 15:15:04 mailgw1 amavis[219136]: policy protocol: 
tempdir=/var/spool/amavisd/tmp/afO7JePJ
Feb  8 15:15:04 mailgw1 amavis[219136]: policy protocol: 
tempdir_removed_by=client
Feb  8 15:15:04 mailgw1 amavis[219136]: policy protocol: 
mail_file=/var/spool/amavisd/tmp/afO7JePJ/email.txt
Feb  8 15:15:04 mailgw1 amavis[219136]: policy protocol: 
delivery_care_of=client
Feb  8 15:15:04 mailgw1 amavis[219136]: policy protocol: 
client_address=23.83.212.19
Feb  8 15:15:04 mailgw1 amavis[219136]: policy protocol: 
client_name=black.elm.relay.mailchannels.net
Feb  8 15:15:04 mailgw1 amavis[219136]: policy protocol: 

Communication between postfix - amavis issues

[Nikolaos Milas]

Hello,

We have a mail gateway server (for incoming email) with postfix 3.5.8, 
amavisd, clamd on CentOS 8.3.2011.


Postfix sends incoming mail to amavisd via (in main.cf):

   smtpd_milters =
    unix:/run/amavisd/amavisd-milter.sock

After checking, amavisd delivers mail directly using amavisd-milter daemon.

My problem is that under our current setup it seems that amavisd will 
not receive mail to port 10028 (used as a bypass, to disable all 
scanning), although it is listening.


How should I modify postfix config so that it sends successfully mail to 
port 10028 as configured?


I am trying the following mechanism to bypass amavisd scans for 
particular senders:


smtpd_recipient_restrictions =
    check_sender_access hash:/etc/postfix/amavis_bypass_senders
    ...

/etc/postfix/amavis_bypass_senders:

   us...@example.com     FILTER smtp:[127.0.0.1]:10028
   us...@example.com     FILTER smtp:[127.0.0.1]:10028

However, the amavis policy bank listening at 10028 is never triggered. 
The log states:


...
Feb  8 01:54:55 mailgw1 postfix/smtpd[202464]: NOQUEUE: filter: RCPT 
from hedgehog.birch.relay.mailchannels.net[23.83.209.81]: 
: Sender address triggers FILTER 
smtp:[127.0.0.1]:10028; from= to= 
proto=ESMTP helo=
Feb  8 01:54:55 mailgw1 postfix/smtpd[202464]: 4DYmH36X5JzLlrw: 
client=hedgehog.birch.relay.mailchannels.net[23.83.209.81]
Feb  8 01:54:56 mailgw1 postfix/cleanup[202468]: 4DYmH36X5JzLlrw: 
message-id=<464576df-43d0-ecac-5647-99c91a95c...@example.com>

...

I also tried with:

   us...@example.com FILTER smtp-amavis:[127.0.0.1]:10028
   us...@example.com FILTER smtp-amavis:[127.0.0.1]:10028

which produced the same results.

What am I doing wrong?

My master.cf is as follows:

# ==
# service type  private unpriv  chroot  wakeup  maxproc command + args
#   (yes)   (yes)   (yes)   (never) (100)
# ==
#smtp inet  n   -   n   -   -   smtpd -v
smtp  inet  n   -   n   -   1 postscreen
smtpd pass  -   -   n   -   -   smtpd
dnsblog   unix  -   -   n   -   0   dnsblog
tlsproxy  unix  -   -   n   -   0   tlsproxy
pickup    fifo  n   -   n   60  1   pickup
cleanup   unix  n   -   n   -   0   cleanup
qmgr  fifo  n   -   n   300 1   qmgr
#qmgr fifo  n   -   n   300 1   oqmgr
tlsmgr    unix  -   -   n   1000?   1   tlsmgr
rewrite   unix  -   -   n   -   - trivial-rewrite
bounce    unix  -   -   n   -   0   bounce
defer unix  -   -   n   -   0   bounce
trace unix  -   -   n   -   0   bounce
verify    unix  -   -   n   -   1   verify
flush unix  n   -   n   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
smtp  unix  -   -   n   -   -   smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay unix  -   -   n   -   -   smtp
    -o smtp_fallback_relay=
#   -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix  n   -   n   -   -   showq
error unix  -   -   n   -   -   error
discard   unix  -   -   n   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   n   -   -   lmtp
anvil unix  -   -   n   -   1   anvil
scache    unix  -   -   n   -   1   scache
retry unix  -   -   n   -   -   error
proxywrite unix -   -   n   -   1   proxymap

smtp-amavis unix -  -   n   -   2   lmtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes
    -o disable_dns_lookups=yes
    -o max_use=20

127.0.0.1:10025 inet n  -   n   -   -   smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_delay_reject=no
    -o smtpd_client_restrictions=permit_mynetworks,reject
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o mynetworks=127.0.0.0/8
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o 

Re: Gateway to Internal Server random "Connection refused"

[Nikolaos Milas]

On 13/1/2021 4:41 μ.μ., Wietse Venema wrote:


This is a TCP-level problem.  The remote server's TCP/IP stack, or
some middle box, is refusing connections at the TCP level.


Thanks Wietse,

We'll be checking this out. Although I have done some connectivity 
testing with repeated netcat (nc) polling to port 25 over IPv6 between 
the two servers, I have not been able to find any issues, at least not yet.


Continuous ping6 shows stable connection at around 7ms; for example:

   rtt min/avg/max/mdev = 6.887/7.152/7.432/0.130 ms

In the last 12 hours I have noticed only one occurrence of the problem, 
after I whitelisted all our mail servers (2 mail gateway servers and the 
main one with the mailboxes) on our Cisco ASA firewall (which is the 
main suspect I can think of for disrupting the communication). This only 
occurrence did NOT happen at a time with high network load.


It seems to me difficult to troubleshoot since it is a so infrequent 
event. The problem is how I can isolate and examine closely the TCP/IP 
state at the moment when the problem occurs. Should I tcpdump IPv6 smtp 
communication between two mail servers over many hours?


In any case, our mail traffic is low, so I think that reducing postfix 
connection limit might not be needed.


If you or anyone else can provide suggestions/hints/thoughts for 
troubleshooting at the TCP/IP layer, esp. IPv6, I would appreciate that.


A next move could be closer examination of dropped packets by our 
firewall. I found this article for a start:


https://networklessons.com/cisco/asa-firewall/cisco-asa-packet-drop-troubleshooting

Thanks again,
Nick

Gateway to Internal Server random "Connection refused"

[Nikolaos Milas]

Hello,

We are building a new mail gateway server (on CentOS 8), which is 
running postfix (v3.5.8) from the GhettoForge Repo.


I noticed the following problem: Sometimes the server seems to not be 
able to connect to our main mail server (Postfix v3.2.5) to verify 
recipients; for example:


Jan 12 15:54:24 mailgw1 postfix/postscreen[2535]: CONNECT from 
[2.228.155.xxx]:64067 to [83.212.5.xxx]:25
Jan 12 15:54:24 mailgw1 postfix/postscreen[2535]: PASS OLD 
[2.228.155.xxx]:64067
Jan 12 15:54:24 mailgw1 postfix/smtpd[2540]: connect from 
mailserver.comune.avellino.xxx[2.228.155.xxx]
Jan 12 15:54:24 mailgw1 postfix/smtpd[2540]: Anonymous TLS connection 
established from mailserver.comune.avellino.xxx[2.228.155.xxx]: TLSv1 
with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
Jan 12 15:54:24 mailgw1 postfix/smtpd[2540]: NOQUEUE: reject: RCPT from 
mailserver.comune.avellino.xxx[2.228.155.xxx]: 450 4.1.1 
: Recipient address rejected: unverified address: 
connect to vmail2.noa.xxx[2001:648:2011:15::xxx]:25: Connection refused; 
from= to= 
proto=ESMTP helo=
Jan 12 15:54:24 mailgw1 postfix/smtpd[2540]: disconnect from 
mailserver.comune.avellino.xxx[2.228.155.xxx] ehlo=2 starttls=1 mail=1 
rcpt=0/1 quit=1 commands=5/6


or:

Jan 12 17:01:30 mailgw1 postfix/postscreen[3644]: CONNECT from 
[2620:109:c006:104::170]:37882 to [2001:648:2ffc:1115::xxx]:25
Jan 12 17:01:31 mailgw1 postfix/postscreen[3644]: PASS OLD 
[2620:109:c006:104::170]:37882
Jan 12 17:01:31 mailgw1 postfix/smtpd[3650]: connect from 
mailc-bb.linkedin.com[2620:109:c006:104::170]
Jan 12 17:01:31 mailgw1 postfix/smtpd[3650]: Anonymous TLS connection 
established from mailc-bb.linkedin.com[2620:109:c006:104::170]: TLSv1.2 
with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jan 12 17:01:32 mailgw1 postfix/cleanup[3655]: 4DFYgc0b5BzLm7T: 
message-id=<4dfygc0b5bzl...@mailgw1.noa.xxx>
Jan 12 17:01:32 mailgw1 postfix/qmgr[1263]: 4DFYgc0b5BzLm7T: 
from=, size=229, nrcpt=1 (queue active)
Jan 12 17:01:32 mailgw1 postfix/smtp[3656]: 4DFYgc0b5BzLm7T: 
to=, relay=vmail2.noa.xxx[194.177.195.xxx]:25, 
delay=0.08, delays=0/0.02/0.05/0.01, dsn=2.1.5, status=deliverable (250 
2.1.5 Ok)

Jan 12 17:01:32 mailgw1 postfix/qmgr[1263]: 4DFYgc0b5BzLm7T: removed
Jan 12 17:01:32 mailgw1 postfix/smtpd[3650]: NOQUEUE: reject: RCPT from 
mailc-bb.linkedin.com[2620:109:c006:104::170]: 450 4.1.1 
: Recipient address rejected: unverified address: 
connect to vmail2.noa.xxx[2001:648:2011:15::xxx]:25: Connection refused; 
from= 
to= proto=ESMTP helo=
Jan 12 17:01:37 mailgw1 postfix/smtpd[3650]: disconnect from 
mailc-bb.linkedin.com[2620:109:c006:104::170] ehlo=2 starttls=1 mail=1 
rcpt=0/1 quit=1 commands=5/6


You can see that: Recipient address rejected: unverified address: 
connect to vmail2.noa.xxx[2001:648:2011:15::xxx]:25: Connection refused


This happens in many cases, for various recipients.

This does not happen to our other mail gateway server (MX), 
mailgw3.noa.xxx, which has in essence the same setup (but older software 
running on CentOS 6).


I cannot see anything related logged in the mail log of the main server 
(vmail2.noa.xxx) which is responsible for user verification.


Can you please guess / trace / give me a hint about the possible cause 
of the problem?


I would appreciate your help!

Follows postconf -n output for your reference:

==

# postconf -n
allowed_list1 = reject
allowed_list2 = reject
command_directory = /usr/sbin
compatibility_level = 2
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 = 20
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 ICXC-NIKA
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 15728640
meta_directory = /etc/postfix
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_reply_map = 
texthash:/etc/postfix/postscreen_dnsbl_reply_map
postscreen_dnsbl_sites = 
c4279dedc01b71e07b5b763485249bcc.combined.mail.abusix.zone, 
b.barracudacentral.org, zen.spamhaus.org*2, psbl.surriel.com

postscreen_dnsbl_threshold = 2
postscreen_greet_action = enforce
queue_directory = /var/spool/postfix
rbl_reply_maps = texthash:/etc/postfix/rbl_reply_map
readme_directory = /usr/share/doc/postfix3-3.5.8/README_FILES
relay_domains = 

CentOS Linux 8 is being practically abolished

[Nikolaos Milas]

As a long-term member of the postfix community, allow me to draw your 
attention to the new serious change in CentOS Linux.


Not quite a postfix issue, but an important (negative IMHO) development 
in the open source community.


You might want to read: 
https://blog.centos.org/2020/12/future-is-centos-stream


A petition has started on this:

https://www.change.org/p/centos-governing-board-do-not-destroy-centos-by-using-it-as-a-rhel-upstream

If you agree, you may want to sign/forward.

With due respect to the community,
Nick Milas
National Observatory of Athens
Greece

Re: Relay access denied to local IPv6 client

[Nikolaos Milas]

On 23/2/2018 9:00 μμ, Bill Cole wrote:

The restriction lists in Postfix are run in a fixed logical order 
(client, helo, sender, relay, recipient, data, end_of_data) and 'OK' 
from an early restriction list (smtpd_client_restrictions) *DOES 
NOT*prevent 'REJECT' by a later restriction list 
(smtpd_recipient_restrictions.) OK only terminates a single 
restriction list, not the whole set of lists, so in this case the 
transaction is exiting the smtpd_client_restrictions list with OK at 
"check_client_access cidr:/etc/postfix/non-tls-clients.cidr" but it 
still must pass through smtpd_recipient_restrictions, where it is 
rejected by "reject_unauth_destination" because you are not the final 
destination for the recipient domain nor do you have the recipient 
domain in $relay_domains.


Thank you all for your feedback and especially Bill for the detailed 
explanation.


The solution was as simple as adding permit_mynetworks to 
smtpd_recipient_restrictions. Since client connectivity is controlled by 
smtpd_client_restrictions, in this scenario there is no reason to not 
allow relay access to all mynetwork.


Best Regards,
Nick

Relay access denied to local IPv6 client

[Nikolaos Milas]

Hello,

We are using Postfix v3.2.4and we arefacing the followingproblem: 
Aclient (a data storage system) with an IPv6 address of 
[2001:648:2011:a21:320e:d5ff:fec6:b55] tries to send an (autosupport) 
email and it's being denied access:


Feb 23 06:22:17 vmail2 postfix/smtpd[16146]: NOQUEUE: reject: RCPT from 
unknown[2001:648:2011:a21:320e:d5ff:fec6:b55]: 554 5.7.1 
: Relay access denied; 
from= to= 
proto=SMTP helo=


All /48 IPv6 address blockis included in mynetworks: ..., 
[2001:648:2011::]/48, ...


The client does not support TLS or authentication. For such clients we 
provide explicit permission:


smtpd_client_restrictions =
  ...
  check_client_access cidr:/etc/postfix/non-tls-clients.cidr
  permit_sasl_authenticated
  reject

where /etc/postfix/non-tls-clients.cidr:

   ...
   [2001:648:2011:a21:320e:d5ff:fec6:b55]   OK
   ...

Please, be kind to help me understand what is causing this client 
rejection and correct my postfix configuration.


postconf -n follows:

# postconf -n
alias_database = hash:/etc/postfix/aliases, 
hash:/etc/postfix/aliases.d/virtual_aliases

alias_maps = hash:/etc/aliases
allowed_list1 = check_sasl_access 
hash:/etc/postfix/allowed_groupmail_users,reject

allowed_list2 = permit_sasl_authenticated,reject
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
controlled_senders = check_sender_access hash:/etc/postfix/blocked_senders
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin 
xxgdb $daemon_directory/$process_name $process_id & sleep 5

default_process_limit = 25
delay_logging_resolution_limit = 3
deliver_lock_attempts = 40
gwcheck = reject_unverified_recipient, reject_unauth_destination
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4, ipv6
local_header_rewrite_clients = static:all
mail_name = IC-XC-NI-KA
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 41943040
meta_directory = /etc/postfix
milter_default_action = accept
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = noa.gr
myhostname = vmail2.noa.gr
mynetworks = 195.251.204.0/24, 195.251.202.0/23, 194.177.194.0/23, 
127.0.0.0/8, 10.201.0.0/16, [2001:648:2011::]/48, 83.212.5.24/29, 
[2001:648:2ffc:1115::]/64, 62.217.124.0/29, [2001:648:2ffc:126::]/64, 
[::1]/128

myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
parent_domain_matches_subdomains =
postfwdcheck = check_policy_service inet:127.0.0.1:10040
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix3-3.2.4/README_FILES
recipient_canonical_maps = hash:/etc/postfix/domainrecipientmap
relay_domains = $mydestination
sample_directory = /usr/share/doc/postfix3-3.2.4/samples
sender_canonical_maps = hash:/etc/postfix/domainsendermap
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib/postfix
smtp_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5
smtp_tls_security_level = may
smtpd_client_restrictions = check_client_access 
cidr:/etc/postfix/localhost.cidr check_client_access 
cidr:/etc/postfix/gwservers.cidr check_client_access 
cidr:/etc/postfix/non-tls-clients.cidr permit_sasl_authenticated reject

smtpd_delay_reject = yes
smtpd_end_of_data_restrictions = check_client_access 
cidr:/etc/postfix/postfwdpolicy.cidr

smtpd_milters = inet:127.0.0.1:8891
smtpd_recipient_restrictions = check_recipient_access 
hash:/etc/postfix/protected_destinations permit_sasl_authenticated 
reject_unverified_recipient reject_unauth_destination
smtpd_restriction_classes = 
controlled_senders,allowed_list1,allowed_list2, postfwdcheck,gwcheck

smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/pki/tls/certs/DigiCertCA.crt
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/star_noa_gr-1243437.crt
smtpd_tls_key_file = /etc/pki/tls/private/star_noa_gr-1243437.key
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/aliases, 
hash:/etc/postfix/aliases.d/virtual_aliases, 
proxy:ldap:/etc/postfix/ldap-alias-vacation.cf, 
proxy:ldap:/etc/postfix/ldap-aliases.cf

virtual_gid_maps = static:500
virtual_mailbox_base = /home/vmail/
virtual_mailbox_domains = $mydomain, space.$mydomain, 

Re: Advice needed on big-sized replies

[Nikolaos Milas]

On 16/2/2018 2:23 πμ, Wietse Venema wrote:


...
And that could be the HTML version of the same content. After
base64 decoding, expect to see a lot of HTML tags, and perhaps
javascript.
...


Thank you Wietse,

I did a base64 decoding of the HTML part and it translated to 6144 lines 
of HTML code, of which the 6082 were style tags and Javascript (i.e. the 
interesting part was only 62 lines = 1% of the whole HTML part)!!


O tempora, o mores!

Cheers,
Nick

Advice needed on big-sized replies

[Nikolaos Milas]

Hello,

Allow me to attract your attention to a NON-Postfix issue, but rather to 
a more generic email issue on which I need to find the right direction 
to search for an explanation. I hope your experience and expertise may 
guide me to a solution.


The problem: I am sending an HTML email (using Thunderbird) to a 
particular recipient; the email has a size of a couple of KB. When I get 
a reply to it from the original recipient, it has grown to a size of 2.5 
MB although I can't see anything that can explain this size. No photos, 
no logos, no visible attachments.


Here is an excerpt from the source of such a message, which may help:

===
...
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [79.131.33.225]
Content-Type: multipart/alternative;
boundary="_000_C8F4E69CA0D6EB47859C539F6B7730BD01123B47B7hge2k10dag2co_"
MIME-Version: 1.0
X-Barracuda-Connect: hge2k10dag1.corp.hygeia-group.com[172.20.253.15]
X-Barracuda-Start-Time: 1518111391
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA
X-Barracuda-URL: https://172.20.253.200:443/cgi-mod/mark.cgi
X-Barracuda-BRTS-Status: 1
X-Virus-Scanned: by bsmtpd at Hygeia.gr
X-Barracuda-Scan-Msg-Size: 1940978

--_000_C8F4E69CA0D6EB47859C539F6B7730BD01123B47B7hge2k10dag2co_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

...contains the main message>


--_000_C8F4E69CA0D6EB47859C539F6B7730BD01123B47B7hge2k10dag2co_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

... seems to me inexplicable>


--_000_C8F4E69CA0D6EB47859C539F6B7730BD01123B47B7hge2k10dag2co_--

===

The whole message is available to anyone who would like to see it. I can 
provide a link to a zipped eml file.


This is a "detective" story to me.

Thanks in advance to anyone who may be able to help!

Cheers,
Nick

Re: Postfix RPMs

[Nikolaos Milas]

On 28/12/2017 2:34 πμ, Peter wrote:


The sources are also freely available from GhettoForge if you want to
look them over.


I am building my own RPMs too, based on GhettoForge src.rpm packages.

Cheers,
Nick

Re: Postfix RPMs

[Nikolaos Milas]

On 27/12/2017 4:34 μμ, Rosenbaum, Larry M. wrote:


Where can I get up-to-date Postfix installation RPMs?



I would suggest you to use GhettoForge repo 
(http://ghettoforge.org/index.php/Main_Page);


See packages: http://ghettoforge.org/index.php/Postfix3

Cheers,
Nick

Re: Access denied when trying to send from localhost

[Nikolaos Milas]

On 1/12/2017 4:09 πμ, Rodrigo Cunha wrote:


Change This:

mynetworks = 195.251.204.0/24 , 
195.251.202.0/23 , 194.177.194.0/23 
, 127.0.0.0/8 , 
10.201.0.0/16 , [2001:648:2011::]/48, 
83.212.5.24/29 , [2001:648:2ffc:1115::]/64, 
62.217.124.0/29 , [2001:648:2ffc:126::]/64


change that for this

mynetworks = 127.0.0.1/8 , 195.251.204.0/24 
, 195.251.202.0/23 , 
194.177.194.0/23 , 127.0.0.0/8 
, 10.201.0.0/16 , 
[2001:648:2011::]/48, 83.212.5.24/29 , 
[2001:648:2ffc:1115::]/64, 62.217.124.0/29 , 
[2001:648:2ffc:126::]/64


Thank you Rodrigo,

As you can see, 127.0.0.0/8 is already included.

However, I tried adding [::1]/128 (which I noticed was missing) and this 
time it worked!


It seems that even though I have explicitly permitted ::1 in 
localhost.cidr ( check_client_access in smtpd_recipient_restrictions ), 
I MUST ALSO include it in mynetworks, although I don't use 
permit_mynetworks!


Obviously, this is due to the implicit (default) setting of:

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, 
defer_unauth_destination


Things are working OK now, thanks everyone!!

Cheers,
Nick

Re: Access denied when trying to send from localhost

[Nikolaos Milas]

On 1/12/2017 1:58 πμ, Benny Pedersen wrote:


change hash to cidr


I have already tried cidr with no luck:

smtpd_recipient_restrictions =
  check_client_access cidr:/etc/postfix/localhost.cidr
  check_recipient_access hash:/etc/postfix/protected_destinations
  permit_sasl_authenticated
  reject_unverified_recipient
  reject_unauth_destination

# cat /etc/postfix/localhost.cidr
194.177.195.166  OK
127.0.0.1    OK
::1  OK
2001:648:2011:15::166    OK

(I also tried to enclose IPv6 addresses in square brackets, which did 
not change things.)



or add permit_mynetworks instead of check_client_access


I don't want to permit_mynetworks, because I want to force clients to 
sasl-authenticate (with the exception of localhost).


Any ideas?

Nick

Access denied when trying to send from localhost

[Nikolaos Milas]

Hello,

On our mail server (running Postfix 3.2.4) I am also using fetchmail to 
read mail from some pop server and deliver it to local users. Yet, mail 
fails to get delivered:


...
Dec  1 01:34:39 vmail2 fetchmail[11447]: POP3> RETR 1
Dec  1 01:34:39 vmail2 fetchmail[11447]: POP3< +OK message 1 (546434 
octets):

Dec  1 01:34:39 vmail2 postfix/smtpd[14506]: connect from localhost[::1]
Dec  1 01:34:39 vmail2 fetchmail[11447]: reading message 
150@195.251.204.117:1 of 1 (546434 octets)Trying to connect to 
::1/25...connected.
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 220 vmail2.noa.gr ESMTP 
IC-XC-NI-KA

Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP> EHLO vmail2.noa.gr
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250-vmail2.noa.gr
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250-PIPELINING
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250-SIZE 41943040
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250-VRFY
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250-ETRN
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250-STARTTLS
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250-ENHANCEDSTATUSCODES
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250-8BITMIME
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250 DSN
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP> MAIL 
FROM: SIZE=546434

Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250 2.1.0 Ok
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP> RCPT TO:
Dec  1 01:34:39 vmail2 postfix/trivial-rewrite[14509]: using 
backwards-compatible default setting append_dot_mydomain=yes to rewrite 
"S8400EAA" to "S8400EAA.noa.gr"
Dec  1 01:34:39 vmail2 postfix/smtpd[14506]: NOQUEUE: reject: RCPT from 
localhost[::1]: 554 5.7.1 : Client host rejected: Access 
denied; from= to= proto=ESMTP 
helo=
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 554 5.7.1 
: Client host rejected: Access denied
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP error: 554 5.7.1 
: Client host rejected: Access denied
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP listener doesn't like 
recipient address `chris...@noa.gr'

Dec  1 01:34:39 vmail2 postfix/smtpd[14510]: connect from localhost[::1]
Dec  1 01:34:39 vmail2 fetchmail[11447]: Trying to connect to 
::1/25...connected.
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 220 vmail2.noa.gr ESMTP 
IC-XC-NI-KA

Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP> HELO vmail2.noa.gr
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250 vmail2.noa.gr
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP> MAIL FROM:<>
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250 2.1.0 Ok
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP> RCPT 
TO:
Dec  1 01:34:39 vmail2 postfix/smtpd[14510]: NOQUEUE: reject: RCPT from 
localhost[::1]: 554 5.7.1 : Client host rejected: Access 
denied; from=<> to= proto=SMTP helo=
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 554 5.7.1 
: Client host rejected: Access denied

Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP> QUIT
Dec  1 01:34:39 vmail2 postfix/smtpd[14510]: disconnect from 
localhost[::1] helo=1 mail=1 rcpt=0/1 quit=1 commands=3/4

Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 221 2.0.0 Bye
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP> RCPT TO:
Dec  1 01:34:39 vmail2 postfix/smtpd[14506]: NOQUEUE: reject: RCPT from 
localhost[::1]: 554 5.7.1 : Client host rejected: Access 
denied; from= to= proto=ESMTP 
helo=
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 554 5.7.1 
: Client host rejected: Access denied
Dec  1 01:34:39 vmail2 fetchmail[11447]: can't even send to 
postmas...@noa.gr!

Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP> RSET
Dec  1 01:34:39 vmail2 fetchmail[11447]: SMTP< 250 2.0.0 Ok
Dec  1 01:34:39 vmail2 fetchmail[11447]: not flushed

Since I have:

smtpd_recipient_restrictions =
  check_client_access hash:/etc/postfix/localhost
  check_recipient_access hash:/etc/postfix/protected_destinations
  permit_sasl_authenticated
  reject_unverified_recipient
  reject_unauth_destination

and /etc/postfix/localhost:

   194.177.195.166  OK
   127.0.0.1    OK
   [::1]    OK
   [2001:648:2011:15::166]  OK

...I wouldn't expect that smtp from localhost would be denied.

What am I doing wrong?

# postconf -n
alias_database = hash:/etc/postfix/aliases, 
hash:/etc/postfix/aliases.d/virtual_aliases

alias_maps = hash:/etc/aliases
allowed_gein = check_client_access 
cidr:/etc/postfix/gein_admin_ips.cidr,reject
allowed_iaasars = check_client_access 
cidr:/etc/postfix/iaasars_admin_ips.cidr,reject
allowed_list1 = check_sasl_access 
hash:/etc/postfix/allowed_groupmail_users,reject

allowed_list2 = permit_sasl_authenticated,reject
allowed_meteo = check_client_access 
cidr:/etc/postfix/meteo_admin_ips.cidr,reject

Re: TLS Handshake Problems

[Nikolaos Milas]

On 28/11/2017 9:57 μμ, Viktor Dukhovni wrote:


This is expected.
...


Thank you Viktor for the detailed analysis and for your time.

I appreciate it very much.

All the best,
Nick

TLS Handshake Problems

[Nikolaos Milas]

Hello,

I have just started using in production a mail server running Postfix 
3.2.4 on CentOS 7.4 (fully patched) with openssl 1.0.2k.


This is a new server, replacing an old CentOS 5.11 with Postfix 2.6.11 
and OpenSSL 0.9.8e.


On the new server I see errors on particular servers as follows; the 
mail is finally delivered but with delay, after being deferred:


Nov 28 12:55:43 vmail2 postfix/submission/smtpd[31782]: 4623A80004F2F: 
client=zeus.admin.noa.gr[195.251.204.18], sasl_method=login, 
sasl_username=elke.rescom
Nov 28 12:55:43 vmail2 postfix/cleanup[30388]: 4623A80004F2F: 
message-id=<20171128105543.4623a80004...@vmail2.noa.gr>
Nov 28 12:55:43 vmail2 opendkim[4708]: 4623A80004F2F: DKIM-Signature 
field added (s=default, d=noa.gr)
Nov 28 12:55:43 vmail2 postfix/qmgr[6529]: 4623A80004F2F: 
from=, size=747, nrcpt=1 (queue active)
Nov 28 12:55:43 vmail2 postfix/smtp[782]: SSL_connect error to 
rcs12.rc.auth.gr[155.207.51.12]:25: lost connection
Nov 28 12:55:43 vmail2 postfix/smtp[782]: 4623A80004F2F: Cannot start 
TLS: handshake failure
Nov 28 12:55:43 vmail2 postfix/smtp[782]: SSL_connect error to 
rcs13.rc.auth.gr[155.207.144.13]:25: lost connection
Nov 28 12:55:43 vmail2 postfix/smtp[782]: 4623A80004F2F: Cannot start 
TLS: handshake failure
Nov 28 12:55:44 vmail2 postfix/smtp[782]: 4623A80004F2F: host 
mailsrv1.ccf.auth.gr[155.207.1.1] said: 450 4.7.1 try again later (in 
reply to DATA command)
Nov 28 12:55:45 vmail2 postfix/smtp[782]: 4623A80004F2F: 
to=, relay=mailsrv2.ccf.auth.gr[155.207.1.2]:25, 
delay=2.4, delays=0.096/0.001/1
.8/0.52, dsn=4.7.1, status=deferred (host 
mailsrv2.ccf.auth.gr[155.207.1.2] said: 450 4.7.1 try again later (in 
reply to DATA command))

...
Nov 28 13:01:22 vmail2 postfix/qmgr[6529]: 4623A80004F2F: 
from=, size=747, nrcpt=1 (queue active)
Nov 28 13:01:22 vmail2 postfix/smtp[782]: SSL_connect error to 
rcs12.rc.auth.gr[155.207.51.12]:25: lost connection
Nov 28 13:01:22 vmail2 postfix/smtp[782]: 4623A80004F2F: Cannot start 
TLS: handshake failure
Nov 28 13:01:22 vmail2 postfix/smtp[782]: 4623A80004F2F: 
to=, relay=rcs12.rc.auth.gr[155.207.51.12]:25, 
delay=340, delays=339/0.002/0.15/0.35, dsn=2.6.0, status=sent (250 2.6.0 
<20171128105543.4623a80004...@vmail2.noa.gr> Queued mail for delivery)

Nov 28 13:01:22 vmail2 postfix/qmgr[6529]: 4623A80004F2F: removed

On the older server, I didn't see such errors.

Can you please help me understand why this happens and if I can resolve 
it by using specific settings?


Here is postconf -n:

# postconf -n
alias_database = hash:/etc/postfix/aliases, 
hash:/etc/postfix/aliases.d/virtual_aliases

alias_maps = hash:/etc/aliases
allowed_gein = check_client_access 
cidr:/etc/postfix/gein_admin_ips.cidr,reject
allowed_iaasars = check_client_access 
cidr:/etc/postfix/iaasars_admin_ips.cidr,reject
allowed_list1 = check_sasl_access 
hash:/etc/postfix/allowed_groupmail_users,reject

allowed_list2 = permit_sasl_authenticated,reject
allowed_meteo = check_client_access 
cidr:/etc/postfix/meteo_admin_ips.cidr,reject

broken_sasl_auth_clients = yes
command_directory = /usr/sbin
controlled_senders = check_sender_access hash:/etc/postfix/blocked_senders
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin 
xxgdb $daemon_directory/$process_name $process_id & sleep 5

default_process_limit = 25
delay_logging_resolution_limit = 3
deliver_lock_attempts = 40
gwcheck = reject_unverified_recipient, reject_unauth_destination
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4, ipv6
local_header_rewrite_clients = static:all
mail_name = IC-XC-NI-KA
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 41943040
meta_directory = /etc/postfix
milter_default_action = accept
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = noa.gr
myhostname = vmail2.noa.gr
mynetworks = 195.251.204.0/24, 195.251.202.0/23, 194.177.194.0/23, 
127.0.0.0/8, 10.201.0.0/16, [2001:648:2011::]/48, 83.212.5.24/29, 
[2001:648:2ffc:1115::]/64, 62.217.124.0/29, [2001:648:2ffc:126::]/64

myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
parent_domain_matches_subdomains =
postfwdcheck = check_policy_service inet:127.0.0.1:10040
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix3-3.2.4/README_FILES
recipient_canonical_maps = hash:/etc/postfix/domainrecipientmap
relay_domains = $mydestination
sample_directory = /usr/share/doc/postfix3-3.2.4/samples
sender_canonical_maps = hash:/etc/postfix/domainsendermap
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib/postfix
smtp_tls_security_level = may
smtpd_client_restrictions = 

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

[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: 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: 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: 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

Re: Switch from LDA to Postfix - Dovecot LMTP delivery (with virtual users)

[Nikolaos Milas]

On 4/8/2017 1:59 μμ, Alex JOST wrote:

Dovecot needs to know about the user. What does 'doveadm user -u 
imaptes...@noa.gr' print?


Thank you Alex,

I just found the problem. After switching to LMTP, Dovecot receives from 
Postfix a fully qualified username, whereas with LDA it was receiving a 
'naked' username.


Thus, although I had %u (instead of %n, see below), it was working right 
with LDA.


So, I had to change my dovecot ldap component so that it uses only the 
username, i.e.:


   hosts = localhost
   tls = no
   base = ou=people, dc=noa, dc=gr
   scope = onelevel
   ldap_version = 3
   dn = uid=auth,ou=Sys,dc=noa,dc=gr
   dnpass = secret
   auth_bind = yes
   user_filter = (uid=%n)
   pass_filter = (uid=%n)
   pass_attrs = uid=user,userPassword=password
   auth_bind_userdn = uid=%n,ou=people,dc=noa,dc=gr
   user_attrs = roomNumber=quota_rule=*:bytes=%$,uid=home=/home/vmail/%n
   iterate_filter = (objectClass=*)

Cheers,
Nick

Switch from LDA to Postfix - Dovecot LMTP delivery (with virtual users)

[Nikolaos Milas]

Hello,

I am setting up a new box with Postfix 3.2.2 and Dovecot.

Until now I have been using LDA delivery successfully. On the new server 
LDA setup works fine too, but I am considering to move to LMTP.


IMPORTANT NOTE: It is important in my setup to keep functional all 
virtual_alias_maps & virtual_mailbox_maps.


I've followed the directions at: 
https://wiki.dovecot.org/HowTo/PostfixDovecotLMTP but LMTP delivery does 
not work.


Here is a session:

Aug  4 12:19:42 vmail2 postfix/submission/smtpd[3145]: connect from 
admin3.astro.noa.gr[195.251.202.163]
Aug  4 12:19:42 vmail2 postfix/submission/smtpd[3145]: Anonymous TLS 
connection established from admin3.astro.noa.gr[195.251.202.163]: 
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug  4 12:19:42 vmail2 postfix/submission/smtpd[3145]: 64EF58EE1BCBE: 
client=admin3.astro.noa.gr[195.251.202.163], sasl_method=PLAIN, 
sasl_username=nmilas
Aug  4 12:19:42 vmail2 postfix/cleanup[3150]: 64EF58EE1BCBE: 
message-id=
Aug  4 12:19:42 vmail2 opendkim[20675]: 64EF58EE1BCBE: DKIM-Signature 
field added (s=default, d=noa.gr)
Aug  4 12:19:42 vmail2 postfix/qmgr[3131]: 64EF58EE1BCBE: 
from=, size=821, nrcpt=1 (queue active)
Aug  4 12:19:42 vmail2 postfix/lmtp[3151]: 64EF58EE1BCBE: 
to=, relay=vmail2.noa.gr[private/dovecot-lmtp], 
delay=0.21, delays=0.17/0.015/0.01/0.015, dsn=5.1.1, status=bounced 
(host vmail2.noa.gr[private/dovecot-lmtp] said: 550 5.1.1 
 User doesn't exist: imaptes...@noa.gr (in reply to 
RCPT TO command))
Aug  4 12:19:42 vmail2 postfix/cleanup[3150]: 8DDF28EE1BCC6: 
message-id=<20170804091942.8ddf28ee1b...@vmail2.noa.gr>
Aug  4 12:19:42 vmail2 postfix/qmgr[3131]: 8DDF28EE1BCC6: from=<>, 
size=3275, nrcpt=1 (queue active)
Aug  4 12:19:42 vmail2 postfix/bounce[3153]: 64EF58EE1BCBE: sender 
non-delivery notification: 8DDF28EE1BCC6

Aug  4 12:19:42 vmail2 postfix/qmgr[3131]: 64EF58EE1BCBE: removed
Aug  4 12:19:42 vmail2 postfix/lmtp[3151]: 8DDF28EE1BCC6: 
to=, relay=vmail2.noa.gr[private/dovecot-lmtp], 
delay=0.015, delays=0.004/0.001/0.001/0.01, dsn=5.1.1, status=bounced 
(host vmail2.noa.gr[private/dovecot-lmtp] said: 550 5.1.1 
 User doesn't exist: nmi...@noa.gr (in reply to RCPT TO 
command))

Aug  4 12:19:42 vmail2 postfix/qmgr[3131]: 8DDF28EE1BCC6: removed
Aug  4 12:19:42 vmail2 postfix/submission/smtpd[3145]: disconnect from 
admin3.astro.noa.gr[195.251.202.163] ehlo=2 starttls=1 auth=1 mail=1 
rcpt=1 data=1 quit=1 commands=8


Can you please help me with figuring out what I am doing wrong?

The setup (postconf -n) with LDA, follows below (working correctly).

# postconf -n
alias_database = hash:/etc/postfix/aliases, 
hash:/etc/postfix/aliases.d/virtual_aliases

alias_maps = hash:/etc/aliases
allowed_gein = check_client_access 
cidr:/etc/postfix/gein_admin_ips.cidr,reject
allowed_iaasars = check_client_access 
cidr:/etc/postfix/iaasars_admin_ips.cidr,reject
allowed_list1 = check_sasl_access 
hash:/etc/postfix/allowed_groupmail_users,reject
allowed_list2 = check_sasl_access 
hash:/etc/postfix/allowed_groupmail_users2,reject
allowed_meteo = check_client_access 
cidr:/etc/postfix/meteo_admin_ips.cidr,reject

broken_sasl_auth_clients = yes
command_directory = /usr/sbin
controlled_senders = check_sender_access hash:/etc/postfix/blocked_senders
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin 
xxgdb $daemon_directory/$process_name $process_id & sleep 5

default_process_limit = 25
delay_logging_resolution_limit = 3
deliver_lock_attempts = 40
dovecot_destination_recipient_limit = 1
gwcheck = reject_unverified_recipient, reject_unauth_destination
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4, ipv6
local_header_rewrite_clients = static:all
mail_name = NOA Mail Srv XAPITI XPICTOY
mail_owner = postfix
mailbox_command = /usr/lib/dovecot/deliver
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 41943040
milter_default_action = accept
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = noa.gr
myhostname = vmail2.noa.gr
mynetworks = 195.251.204.0/24, 195.251.202.0/23, 194.177.194.0/23, 
127.0.0.0/8, 10.201.0.0/16, [2001:648:2011::]/48, 83.212.5.24/29, 
[2001:648:2ffc:1115::]/64, 62.217.124.0/29, [2001:648:2ffc:126::]/64

myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
parent_domain_matches_subdomains =
postfwdcheck = check_policy_service inet:127.0.0.1:10040
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
recipient_canonical_maps = hash:/etc/postfix/domainrecipientmap
relay_domains = $mydestination
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sender_canonical_maps = 

Re: Migrating 2.11 to 3.2

[Nikolaos Milas]

On 27/7/2017 10:45 μμ, Peter wrote:


You don't have to actually rebuild the src.rpms, although you certainly
can if you want.  There are binary rpms you can just install as per the
directions at:

http://ghettoforge.org/index.php/Postfix3


Yep, I know; As I've mentioned, I prefer to build against ltb openldap, 
which has proved to be well-updated and trustworthy.


[Additionally, I like to maintain my (slight) rpm-build know-how; it has 
been very useful in various occasions.]


[I must pay my respect to GhettoForge who are providing reliable updated 
packages for numerous software projects.]


Interestingly, I've also noticed that postfix binaries are built against 
original mysql, although CentOS 7 now uses mariadb as standard.


I've tried switching the dependency to mariadb instead, and building 
using mariadb works fine as well.


Is there a particular reason why mysql is used in the spec file rather 
than mariadb (both in the GhettoForge and in the Oostergo versions)?



The main thing to be concerned about here is the possibility of
different versions of the compiled berkley db files.  Simply re-running
postmap on the source files should correct those issues.


I haven't noticed any such issues, but I'll keep an eye for possible 
problems.


My concern was that by switching the whole directory I might have missed 
some files that may have been needed, although I did not notice any such 
files (by comparing the content of the /etc/postfix/ directories on the 
two servers) when I tried to resolve the issue.


I am still wondering about the possible cause of the startup problem I 
faced.


Cheers,
Nick

Re: Protecting mail addresses using check_sasl_access

[Nikolaos Milas]

On 26/7/2017 2:09 μμ, Nikolaos Milas wrote:


Can you please confirm that this is a valid configuration?


In the meantime I tested this configuration and it does work fine (as I 
expected)!



Any other suggestions, pitfalls and/or comments?


I surely appreciate any suggestions, pitfalls and/or comments on this 
approach!


Cheers,
Nick

Re: Migrating 2.11 to 3.2

[Nikolaos Milas]

On 27/7/2017 1:50 μμ, Peter wrote:


http://ghettoforge.org/index.php/Packages

Right, that one is highly recommended, much better than attempting to
install from source.


OK, I followed your advice and I rebuilt the rpm(s) using:

   
http://mirror.ghettoforge.org/distributions/gf/el/7Server/plus/SRPMS/postfix3-3.2.2-4.gf.el7.src.rpm

I uninstalled postfix and re-installed using the new builds; then I 
copied the migrated (simply transferred from the original server) custom 
config files to the new config directory (/etc/postfix/).


Postfix started fine this time. Things appear running smoothly until now.

It may have been wrong from my side to simply replace the whole 
/etc/postfix/ directory with the one from the original server (as I 
initially did). This time I have been more cautious (as I explained above).


Thanks,
Nick

Re: Migrating 2.11 to 3.2

[Nikolaos Milas]

On 27/7/2017 1:02 μμ, Pinter Tibor wrote:


# rpm -ql postfix | grep files
/usr/libexec/postfix/postfix-files 


Thank you all for your responses. Please see below:

   # rpm -ql postfix | grep files
   /usr/share/postfix/postfix-files

   rpm -qa postfix | grep postfix
   postfix-3.2.2-2.el7.centos.appletech.x86_64

I've built postfix myself, using:

   http://repos.oostergo.net/7/SRPMS/postfix-3.2.2-1.el7.centos.src.rpm

having adapted it slightly to get built using the ltb openldap libraries 
(see https://ltb-project.org/download) which I use on all my systems for 
years.


Postfix worked fine after the package installation (with the default 
config); However it presents this problem when I try to start it with 
the config I copied from the initial server.


Any suggestions on how to correct things without having to rebuild the 
software?


Cheers,
Nick

Migrating 2.11 to 3.2

[Nikolaos Milas]

Hello,

We are moving to a new (virtual) server (from CentOS 5 with Postfix 
2.11.6 to CentOS 7 with Postfix 3.2.2).


I have moved the original configuration to the new server and Postfix 
won't start; I am getting:


# systemctl status postfix
 postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; 
vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2017-07-27 12:25:14 
EEST; 12min ago
  Process: 21895 ExecStart=/usr/sbin/postfix start (code=exited, 
status=1/FAILURE)
  Process: 21893 ExecStartPre=/usr/libexec/postfix/chroot-update 
(code=exited, status=0/SUCCESS)
  Process: 21890 ExecStartPre=/usr/libexec/postfix/aliasesdb 
(code=exited, status=0/SUCCESS)

 Main PID: 14815 (code=killed, signal=TERM)

Jul 27 12:25:12 vmail2.noa.gr postfix[21895]: /usr/sbin/postconf: 
warning: /etc/postfix/main.cf: unused parameter: 
127.0.0.1:10040_time_limit=3600
Jul 27 12:25:12 vmail2.noa.gr postfix[21895]: /usr/sbin/postconf: 
warning: /etc/postfix/main.cf: unused parameter: 
127.0.0.1:10040_time_limit=3600
Jul 27 12:25:12 vmail2.noa.gr postfix[21895]: /usr/sbin/postconf: 
warning: /etc/postfix/main.cf: unused parameter: 
127.0.0.1:10040_time_limit=3600
Jul 27 12:25:12 vmail2.noa.gr postfix[21895]: 
/usr/libexec/postfix/post-install: Error: /etc/postfix/postfix-files is 
not a file.
Jul 27 12:25:12 vmail2.noa.gr postfix/postfix-script[21913]: fatal: 
unable to create missing queue directories
Jul 27 12:25:13 vmail2.noa.gr postfix/postfix-script[21914]: fatal: 
Postfix integrity check failed!
Jul 27 12:25:14 vmail2.noa.gr systemd[1]: postfix.service: control 
process exited, code=exited status=1
Jul 27 12:25:14 vmail2.noa.gr systemd[1]: Failed to start Postfix Mail 
Transport Agent.
Jul 27 12:25:14 vmail2.noa.gr systemd[1]: Unit postfix.service entered 
failed state.

Jul 27 12:25:14 vmail2.noa.gr systemd[1]: postfix.service failed.

I also tried:

# /usr/libexec/postfix/post-install create-missing
postconf: warning: /etc/postfix/main.cf: unused parameter: 
127.0.0.1:10040_time_limit=3600

/usr/libexec/postfix/post-install: Error: /postfix-files is not a file.

Can you please let me know what may be the issue here?

I have checked the queue directory: /var/spool/postfix/ and I don't see 
anything different between the two installations.


Here is my config details:

# postconf -n
alias_database = hash:/etc/postfix/aliases, 
hash:/etc/postfix/aliases.d/virtual_aliases

alias_maps = hash:/etc/aliases
allowed_gein = check_client_access 
cidr:/etc/postfix/gein_admin_ips.cidr,reject
allowed_iaasars = check_client_access 
cidr:/etc/postfix/iaasars_admin_ips.cidr,reject
allowed_list1 = check_sasl_access 
hash:/etc/postfix/allowed_groupmail_users,reject

allowed_list2 = permit_mynetworks,reject
allowed_meteo = check_client_access 
cidr:/etc/postfix/meteo_admin_ips.cidr,reject

broken_sasl_auth_clients = yes
command_directory = /usr/sbin
controlled_senders = check_sender_access hash:/etc/postfix/blocked_senders
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin 
xxgdb $daemon_directory/$process_name $process_id & sleep 5

default_process_limit = 25
delay_logging_resolution_limit = 3
deliver_lock_attempts = 40
dovecot_destination_recipient_limit = 1
gwcheck = reject_unverified_recipient, reject_unauth_destination
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4, ipv6
local_header_rewrite_clients = static:all
mail_name = NOA Mail Srv XAPITI XPICTOY
mail_owner = postfix
mailbox_command = /usr/lib/dovecot/deliver
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 41943040
milter_default_action = accept
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = noa.gr
myhostname = vmail2.noa.gr
mynetworks = 195.251.204.0/24, 195.251.202.0/23, 194.177.194.0/23, 
127.0.0.0/8, 10.201.0.0/16, [2001:648:2011::]/48, 83.212.5.24/29, 
[2001:648:2ffc:1115::]/64, 62.217.124.0/29, [2001:648:2ffc:126::]/64

myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
parent_domain_matches_subdomains =
postfwdcheck = check_policy_service inet:127.0.0.1:10040
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
recipient_canonical_maps = hash:/etc/postfix/domainrecipientmap
relay_domains = $mydestination
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sender_canonical_maps = hash:/etc/postfix/domainsendermap
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_security_level = may
smtpd_client_restrictions = 
permit_mynetworks,permit_sasl_authenticated,reject

smtpd_delay_reject = yes
smtpd_end_of_data_restrictions = check_client_access 
cidr:/etc/postfix/postfwdpolicy.cidr

smtpd_milters = inet:127.0.0.1:8891
smtpd_recipient_restrictions = 

Re: Protecting mail addresses using check_sasl_access

[Nikolaos Milas]

On 26/7/2017 2:09 μμ, Nikolaos Milas wrote:


/etc/postfix/protected_destinations:
privlist1@example.comallowed_list1
privlist1@example.comallowed_list1
privlist1@example.comallowed_list1 


Hmm, sorry, this part was meant to be:

/etc/postfix/protected_destinations:
   privli...@example.comallowed_list1
   privli...@example.comallowed_list1
   privli...@example.comallowed_list1

Nick

Protecting mail addresses using check_sasl_access

[Nikolaos Milas]

Hello,

Since Postfix is now (since v2.11) providing more extensive sasl access 
restrictions, we are considering using the following model to protect 
particular addresses so that only specific users can send mail to them:


   /etc/postfix/main.cf:
  ...
  allowed_list1= check_sasl_access
   hash:/etc/postfix/allowed_users,reject

  smtpd_recipient_restrictions =
check_recipient_access hash:/etc/postfix/protected_destinations
permit_sasl_authenticated
reject_unverified_recipient
reject_unauth_destination
  ...

   /etc/postfix/protected_destinations:
  privli...@example.comallowed_list1
  privli...@example.comallowed_list1
  privli...@example.comallowed_list1
  ...

   /etc/postfix/allowed_users:
  john.doeOK
  jackpot OK
  thechiefOK

All users will be required to be SASL-authenticated, and, consequently, 
the above approach (restricting via check_sasl_access) would be much 
better/versatile than the one we are currently using (restricting via 
check_client_access and associated lists of allowed IP Addresses), 
because it would focus on individual users, wherever they may be, and 
not on their (network) location.


Can you please confirm that this is a valid configuration?

Any other suggestions, pitfalls and/or comments?

Thanks in advance,
Nick

Re: Domain loops to itself

[Nikolaos Milas]

On 17/2/2017 4:12 μμ, Wietse Venema wrote:


You missed the preceding warning that says why.

- The server greets with the same hostname (in the 220 line)
as the client wants to use (in the EHLO cdommand).

- The server IP address matches $mydestination or $proxy_interfaces.


Thanks Wietse,

I didn't change anything, but it has now started working properly.

I am also getting all those test emails I sent earlier and had not been 
delivered until now (and they were obviously in the sending servers' 
queues).


I can't tell for sure what the problem may have been.

Could it be due to transport_maps caching (or something like that)? I 
had initially forgotten to add the


   hesperia-space.eu   relay:[vmail.noa.gr]

line, but even when I added it and restarted postfix (service postfix 
restart), it wouldn't work.


Thanks anyway,
Nick

Domain loops to itself

[Nikolaos Milas]

Hello,

I have been using the following config without problems, but after I 
added the domain: hesperia-space.eu, mail to the new domain becomes 
undelivered with the error (example from one attempt to send mail):


Feb 17 15:21:38 mailgw3 postfix/smtpd[17664]: NOQUEUE: reject: RCPT from 
mail-wr0-x242.google.com[2a00:1450:400c:c0c::242]: 450 4.1.1 
: Recipient address rejected: unverified 
address: mail for hesperia-space.eu loops back to myself; 
from= to= proto=ESMTP 
helo=


The sent email never makes it to the final (relayed) destination.

I have added the domain in the relay_domains setting and in the 
/etc/postfix/transportmap file, as you can see below.


Can you please notice what is wrong? I have spent quite some time, but I 
can't tell where the problem is.


I post the config, as is, including the new domain:

# 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
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 
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre 
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
transport_maps = hash:/etc/postfix/transportmap
unknown_local_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtualmap

# cat /etc/postfix/transportmap
noa.gr  relay:[vmail.noa.gr]
admin.noa.grrelay:[vmail.noa.gr]
nestor.noa.gr   relay:[vmail.noa.gr]
space.noa.grrelay:[vmail.noa.gr]
meteo.noa.grrelay:[vmail.noa.gr]
gein.noa.gr relay:[vmail.noa.gr]
technet.noa.gr  relay:[vmail.noa.gr]
astro.noa.grrelay:[vmail.noa.gr]
hesperia-space.eu   relay:[vmail.noa.gr]

Thanks in advance,
Nick

Re: Blacklisting googlegroups

[Nikolaos Milas]

On 24/10/2016 6:46 μμ, Noel Jones wrote:


header_checks can't be used there.  Use a second check_sender_access
instead.


Thank you Noel,

Your suggestion worked fine!

The only change I did was to escape the + sign:

/^oursuperclub-members\+bnc(.*)@googlegroups\.com$/  REJECT

All the best,
Nick

Re: Blacklisting googlegroups

[Nikolaos Milas]

On 24/10/2016 5:15 μμ, Fazzina, Angelo wrote:


Can't you use REGEX to write a rule to catch them, and then decide what you 
want to do with those emails ?


Would the following be valid?

smtpd_recipient_restrictions =
...
check_sender_access hash:/etc/postfix/blacklisted_senders
header_checks pcre:/etc/postfix/blacklisted_maillists
...

/etc/postfix/blacklisted_maillists

/^Return-Path: / REJECT

Nick

Blacklisting googlegroups

[Nikolaos Milas]

Hello,

I am using:

smtpd_recipient_restrictions =
...
check_sender_access hash:/etc/postfix/blacklisted_senders
...

to blacklist certain senders in blacklisted_senders file.

I would like to block a certain spam googlegroups mailing list but 
sender is not constant; it's like:


   oursuperclub-members+bncbcg7bjnotikrbewdwpaakgqeabvw...@googlegroups.com

and the  part is constantly changing.

Which would be the best way to block this?

Please advise.

Thanks,
Nick

Re: Complaints due to helo restrictions

[Nikolaos Milas]

On 13/9/2016 8:52 μμ, Wietse Venema wrote:


I'd use none of these.


Thank you all for your feedback. Following Wietse's advice, I have 
removed these directives from the config.


All the best,
Nick

Complaints due to helo restrictions

[Nikolaos Milas]

Hello,

We are running postfix v2.11.0 on CentOS 6.8 as a gateway server and we 
have recently imposed helo restrictions.


Few servers have problems sending us mail due to the helo restrictions:

Sep  8 09:35:37 mailgw1 postfix/smtpd[18791]: NOQUEUE: reject: RCPT from 
mail.ipta.demokritos.gr[143.233.230.2]: 450 4.7.1 : Helo 
command rejected: Host not found;
from= to= proto=ESMTP 
helo=


We have notified them that their helo answer is different than their 
mail server name / FQDN (so as to change it) and they say that we should 
not be restricting access due to this:


"The HELO receiver MAY verify that the HELO parameter really corresponds 
to the IP address of the sender. However, the receiver MUST NOT refuse 
to accept a message, even if the sender's HELO command fails 
verification. http://www.ietf.org/rfc/rfc1123.txt (section 5.2.5)"


From your experience and knowledge:

1. How should we treat this issue?

2. How should we respond to the complaints?

3. If we are supposed to remove these restrictions, which settings 
should we remove from our config to resolve the problem? Should we 
remove all of: reject_unknown_helo_hostname, 
reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname ?


Here is our postconf -n:

# 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
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

relay_recipient_maps =
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_helo_required = yes
smtpd_recipient_restrictions = check_client_access 
hash:/etc/postfix/amavis_bypass check_sender_access 
hash:/etc/postfix/blacklisted_senders reject_unverified_recipient 
reject_unauth_destination check_recipient_access 
hash:/etc/postfix/protected_destinations 
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre 
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_unknown_helo_hostname reject_invalid_helo_hostname 
reject_non_fqdn_helo_hostname 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
transport_maps = hash:/etc/postfix/transportmap
unknown_local_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtualmap

Thanks in advance,
Nick

Re: Porn spam killer PCRE

[Nikolaos Milas]

On 25/8/2016 7:46 μμ, Sean Greenslade wrote:


Make sure the SPF rules have weights set, then check the spam report for
a message. If SPF is working, you should see at least one of the SPF
rules trigger for every message.


Thank you Sean for all your help.

I am focusing on amavisd-new / spamassassin for my efforts.

I have started a thread in the amavisd-new users mailing list, since 
bayesian filtering is off-topic here.


However, before ending this thread, I would like to ask: all these rules 
for which you have defined scores:


   score LOTS_OF_MONEY 0.9
   score FREEMAIL_FORGED_FROMDOMAIN 0.5
   score WEIRD_PORT 1.5
   score TO_IN_SUBJ 1.0

   score RCVD_IN_MSPIKE_BL 1.0
   score RCVD_IN_MSPIKE_L5 2.5
   score RCVD_IN_MSPIKE_L4 2.0
   ...

...are custom rules you have set up? If so, what do they look like?(You 
may want to reply off-list, if you deem it is more approrpriate.)


The same question goes for the SPF rules.

I am asking because I see:

   # spamassassin -D --lint
   ...
   Aug 27 17:13:56.860 [10384] dbg: config: warning: score set for
   non-existent rule RCVD_IN_MSPIKE_H4
   Aug 27 17:13:56.860 [10384] dbg: config: warning: score set for
   non-existent rule RCVD_IN_MSPIKE_WL
   Aug 27 17:13:56.861 [10384] dbg: config: warning: score set for
   non-existent rule FREEMAIL_FORGED_FROMDOMAIN
   Aug 27 17:13:56.861 [10384] dbg: config: warning: score set for
   non-existent rule RCVD_IN_MSPIKE_L5
   Aug 27 17:13:56.861 [10384] dbg: config: warning: score set for
   non-existent rule RCVD_IN_MSPIKE_H3
   Aug 27 17:13:56.861 [10384] dbg: config: warning: score set for
   non-existent rule PP_TOO_MUCH_UNICODE02
   Aug 27 17:13:56.861 [10384] dbg: config: warning: score set for
   non-existent rule HEADER_HOST_IN_WHITELIST
   Aug 27 17:13:56.861 [10384] dbg: config: warning: score set for
   non-existent rule URI_HOST_IN_BLACKLIST
   Aug 27 17:13:56.861 [10384] dbg: config: warning: score set for
   non-existent rule RCVD_IN_MSPIKE_H2
   Aug 27 17:13:56.861 [10384] dbg: config: warning: score set for
   non-existent rule HEADER_FROM_DIFFERENT_DOMAINS
   Aug 27 17:13:56.861 [10384] dbg: config: warning: score set for
   non-existent rule URI_HOST_IN_WHITELIST
   Aug 27 17:13:56.862 [10384] dbg: config: warning: score set for
   non-existent rule HELO_LH_HOME
   Aug 27 17:13:56.862 [10384] dbg: config: warning: score set for
   non-existent rule HEADER_HOST_IN_BLACKLIST
   Aug 27 17:13:56.862 [10384] dbg: config: warning: score set for
   non-existent rule RCVD_IN_MSPIKE_ZBI
   Aug 27 17:13:56.862 [10384] dbg: config: warning: score set for
   non-existent rule RCVD_IN_MSPIKE_L2
   Aug 27 17:13:56.862 [10384] dbg: config: warning: score set for
   non-existent rule HK_NAME_MR_MRS
   Aug 27 17:13:56.862 [10384] dbg: config: warning: score set for
   non-existent rule RCVD_IN_MSPIKE_BL
   Aug 27 17:13:56.862 [10384] dbg: config: warning: score set for
   non-existent rule PP_TOO_MUCH_UNICODE05
   Aug 27 17:13:56.862 [10384] dbg: config: warning: score set for
   non-existent rule RCVD_IN_MSPIKE_L4
   Aug 27 17:13:56.862 [10384] dbg: config: warning: score set for
   non-existent rule RCVD_IN_MSPIKE_H5
   Aug 27 17:13:56.863 [10384] dbg: config: warning: score set for
   non-existent rule URIBL_SBL_A
   Aug 27 17:13:56.863 [10384] dbg: config: warning: score set for
   non-existent rule PP_MIME_FAKE_ASCII_TEXT
   Aug 27 17:13:56.863 [10384] dbg: config: warning: score set for
   non-existent rule RCVD_IN_MSPIKE_L3
   ...

Also note that re. SPF tests, I see:

   # spamassassin -D --lint
   ...
   Aug 27 17:13:58.228 [10384] warn: rules: failed to run SPF_NONE
   test, skipping:
   Aug 27 17:13:58.229 [10384] warn:  (Can't locate object method
   "check_for_spf_none" via package "Mail:
   [...]:SpamAssassin::PerMsgStatus" at (eval 1241) line 343.
   Aug 27 17:13:58.229 [10384] warn: )
   ...
   Aug 27 17:13:58.231 [10384] warn: rules: failed to run SPF_HELO_NONE
   test, skipping:
   Aug 27 17:13:58.231 [10384] warn:  (Can't locate object method
   "check_for_spf_helo_none" via package "Mail:
   [...]:SpamAssassin::PerMsgStatus" at (eval 1241) line 959.
   Aug 27 17:13:58.231 [10384] warn: )
   ...

What may be a problem here?

Nick

Re: Porn spam killer PCRE

[Nikolaos Milas]

On 23/8/2016 11:58 μμ, Sean Greenslade wrote:


Hope this is helpful,


Thanks Sean for your time and eagerness to help. I appreciate it.

I am planning to try your suggestions.

I am using CentOS 6. Can you please let me know about the perl package 
SPF-related bug you mentioned?


I have installed:

   yum --enablerepo=epel install perl-Mail-SPF perl-Sys-Hostname-Long

Would this be OK, or I should add/change something?

Finally, I note that in my setup I am loading/running spamassassin from 
within amavis and not directly in postfix.


Thanks again,
Nick

Re: Porn spam killer PCRE

[Nikolaos Milas]

On 20/8/2016 7:56 μμ, Sean Greenslade wrote:


...
- Enable & configure per-user bayesan filtering
- Increase allowed storage space for bayesan databases
- Update a particular perl package to make SPF work (CentOS / RHEL
   specific bug)
...
- Re-weight a bunch of internal rules, in particular the bayes, SPF,
   and mailspike rules

Another thing I did was enable the spam report to be added to all
messages, that way I could more easily debug why spam that was getting
past the filter didn't trigger it.

...I slowly ramped up rule weights and waited to see what would happen. ...


Thank you Sean for your advice. I would appreciate if you provide more 
technical details on how to try the above and/or indicate documentation 
links with associated guide(s).


Your experience might help avoid re-inventing the wheel while trying to 
make users life easier in our really congested daily routine.


Thanks in advance,
Nick

Re: Porn spam killer PCRE

[Nikolaos Milas]

On 19/8/2016 5:29 μμ, Benny Pedersen wrote:


fail2ban ?


Thank you,

I am already using fail2ban directly with the following rules:

  /etc/fail2ban/filter.d/:

   failregex = reject: RCPT from (.*)\[\]: 554
reject: RCPT from (.*)\[\]: 450
reject: RCPT from (.*)\[\]:([0-9]{4,5}:)? 550
too many errors after AUTH from (.*)\[\]

   ignoreregex =

  /etc/fail2ban/jail.conf:

   [postfix]

   enabled  = true
   filter   = postfix
   action   = iptables-multiport[name=Postfix, port="smtp,submission",
   protocol=tcp]
   logpath  = /var/log/maillog
   maxretry = 6
   findtime = 1200
   bantime  = 7200

I understand your suggestion to query the fail2ban db directly from 
postfix but I need to research more on how to implement that.


Yet, I guess we could get better results by fail2ban itself? Could you 
suggest how to expand/improve filtering rules and policy so as to get 
better results from fail2ban itself?


Any directions on how to better leverage fail2ban with any or both ways 
will be appreciated!


All the best,
Nick

Porn spam killer PCRE

[Nikolaos Milas]

Hello,

Has anyone developed and/or maintains PCRE filtering for porn spam senders?

(Something like 
https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre)


I guess many sender / client domains could be filtered-away if they 
include keywords like "kiss", "girl", "date", "adult", "cute", etc.


Any advice on that? (Note: Some users suffer more than others by porn spam.)

We are already using postscreen, many RBLs, the fqrdns.pcre, amavis, 
spamassassin with scamp and we are filtering about 60-70% of total 
incoming mail as spam, but there is still much more that should be 
filtered out.


Any additional suggestions?

Thanks,
Nick

Re: Block certain prefixes/TLDs from accessing

[Nikolaos Milas]

On 12/8/2016 12:01 πμ, Nikolaos Milas wrote:


The following works for me:

   smtpd_restriction_classes ...
...


Forget this suggestion, it's used in a different context; and it's not 
complete either.


Sorry for the confusion.

Nick

Re: Block certain prefixes/TLDs from accessing

[Nikolaos Milas]

On 11/8/2016 11:49 μμ, Richard Klingler wrote:


I've put it also now on the client restriction..but the message looks the 
same...
Clients still can try to do SMTP AUTH...


The following works for me:

   smtpd_restriction_classes = controlled_senders,allowed_list1

   controlled_senders = check_sender_access
   hash:/etc/postfix/blocked_senders
   allowed_list1= check_client_access cidr:/etc/postfix/clients.cidr,reject

Of course it's vice versa than what you want to do with clients: 
clients.cidr includes only OK clients. If you do it your way (with 
REJECTs in cidr file), remove reject from the end.


...and keep:

   smtpd_recipient_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  reject_unverified_recipient
  reject_unauth_destination
  ...

Nick

Re: Block certain prefixes/TLDs from accessing

[Nikolaos Milas]

On 11/8/2016 11:34 μμ, Richard Klingler wrote:


I have in the blacklist:

60.166.0.0/15   REJECT


Have you restarted postfix after updating the cidr file?

Nick

Re: Block certain prefixes/TLDs from accessing

[Nikolaos Milas]

On 11/8/2016 10:56 μμ, Richard Klingler wrote:


Well I would have expected that the first entry in 
smtpd_recipient_restrictions...


Actually, it seems you are confusing restrictions at different phases of 
mail handling. Read more carefully Noel's notes! (He explains things 
clearly!)


Reading http://www.postfix.org/SMTPD_ACCESS_README.html for 
explanation/guidance may help you too!


All the best,
Nick

Re: Block certain prefixes/TLDs from accessing

[Nikolaos Milas]

On 11/8/2016 1:25 μμ, Richard Klingler wrote:


Is there an easy way to block a list of prefixes from accessing postfix?
...
Preferably I would like to combine prefix and domain filtering
as plain helo_checks won't allow regular expression for hostnames.


I think you can use:

smtpd_recipient_restrictions =
...
check_sender_access hash:/etc/postfix/blacklisted_senders
check_client_access cidr:/etc/postfix/blacklisted_prefixes
reject_unverified_recipient
reject_unauth_destination
...

where /etc/postfix/blacklisted_senders:

m...@example.comREJECT
example.net REJECT
subd.example.orgREJECT
...

and /etc/postfix/blacklisted_prefixes:

192.168.1.1 REJECT
192.168.0.0/16  REJECT
2001:db8::1 REJECT
2001:db8::/32   REJECT

Nick

Re: RHEL / CentOS 7 RPMs

[Nikolaos Milas]

On 15/3/2016 9:26 μμ, Peter wrote:


All you're doing here is doubling up on -DUSE_SASL_AUTH and changing
hard-coded defaults to dovecot.  Leave well enough alone and put your
dovecot SASL settings in main.cf where they belong.


Sorry for my ignorance,

Thank you very much for all the clarifications and valuable information!

All the best,
Nick

Re: RHEL / CentOS 7 RPMs

[Nikolaos Milas]

On 15/3/2016 11:44 πμ, Nikolaos Milas wrote:

So, it seems that initially the above compilation options are 
disabled. Right?




To answer my own question, in fact, it's the other way round! For example:

   %bcond_without ldap

means ldap is enabled by default!

And a second question: Could we build the package as postfix (not 
postfix3) so as to be able to replace the default OS postfix package 
on installation (automatic upgrade)?


This question remains open, so please advise.

By the way, it seems to me that an important option to add to the spec 
file is Dovecot SASL (used quite extensively these days).


So, I "merged" some stuff from S. J. Mudd's RPMs and the build rolled 
fine. (Note however that I did not try to build without sasl support.)


You may want to merge it more intelligently -as I am not proficient in 
spec files-.
You may find the modifed file at: 
http://iweb.noa.gr/files/postfix3.1.0-1.noanet.spec


Added sections are marked using:

   # Added by Nick - Section x of 4
   #
   
   #
   # End of Nick Section x

   where x = 1 - 4

A final query: S.J. Mudd's SRPMs included an SPF option. Is this option 
still valid/meaningful/useful in latest postfix versions?


All the best,
Nick

Re: RHEL / CentOS 7 RPMs

[Nikolaos Milas]

On 14/3/2016 8:56 μμ, Peter wrote:


The -release RPM for CentOS 7 is at:
http://mirror.symnds.com/distributions/gf/el/7/gf/x86_64/gf-release-7-8.gf.el7.noarch.rpm


Thank you Peter,

I took a first look at your Postfix3 SRPM package today. It looks well 
organized and updated.


Before I move on with building experimentation, a very basic question:

The SPEC file, starts with:

   %bcond_without mysql
   %bcond_without pgsql
   %bcond_without sqlite
   %bcond_without ldap
   %bcond_without pcre
   %bcond_without sasl
   %bcond_without tls
   %bcond_without ipv6
   %bcond_without pflogsumm

So, it seems that initially the above compilation options are disabled. 
Right?


To enable particular options, should it be enough to change the above 
entries to (example, to enable all options except sql*):


   %bcond_without mysql
   %bcond_without pgsql
   %bcond_without sqlite
   %bcond_with ldap
   %bcond_with pcre
   %bcond_with sasl
   %bcond_with tls
   %bcond_with ipv6
   %bcond_with pflogsumm

...?

And a second question: Could we build the package as postfix (not 
postfix3) so as to be able to replace the default OS postfix package on 
installation (automatic upgrade)?


Why Postfix v3 should be treated differently than the standard postfix 
packages (currently v2.10.1 on CentOS 7)? Wouldn't an upgrade-in-place 
be possible?


Please clarify.

Thanks,
Nick

Re: RHEL / CentOS 7 RPMs

[Nikolaos Milas]

Thank you all for the feedback.

Unfortunately, it seems that GhettoForge is currently (14 March) down 
(it shows some errors with a backtrace), while repo.mailserver.guru does 
not appear to include source rpms (SRPMs). If I am missing something, 
please point me to the right direction.


It is important to us to be able to have SRPMs, because we are modifying 
SPEC files to compile with LDAP support against LTB packages 
(http://ltb-project.org/wiki/download#openldap).


I have also found http://repos.oostergo.net/7/ packages which I have not 
tried yet. I have tried oostergo's RHEL 5 Postfix 3 sRPMs, but I have 
not had good results trying to change compilation options in the spec 
file to fit our build needs. (Yet, I cannot pretend I am the best of 
builders around. If I continue with these sRPMs, I might have to contact 
the author for some assistance.)


So, the issue still remains open to me.

All the best,
Nick

RHEL / CentOS 7 RPMs

[Nikolaos Milas]

Hello,

I would like to ask whether someone has worked on J. Mudd's RPMs 
(http://postfix.wl0.org/) to produce RHEL / CentOS 7 versions.


The above site includes code for RHEL / CentOS versions 5 and 6 (not for 
all Postfix versions, but which can be adapted more or less easily for 
current Postfix versions).


However, since RHEL / CentOS 7 is different in many aspects from older 
versions, I believe J. Mudd's sources might need more changes on it.


I have reached the point to like J. Mudd's sources, because they're 
quite versatile, offering many compilation options, covering practically 
most of admins' needs and for years I've always had good results using 
them as basis for our (production and test) RPMs on CentOS 5 and 6.


If someone can advise me on this subject, I would appreciate any and all 
feedback.


Thanks in advance.

All the best,
Nick

Re: haproxy enablement issues

[Nikolaos Milas]

On 20/8/2015 10:48 μμ, Viktor Dukhovni wrote:


Have the proxy connect to a dedicated smtpd(8) instance in master.cf
listening on a dedicated ip/port.  Allow only the proxy to connect
there, and turn on haproxy support for just that instance.


Thank you Wietse and Victor for your help.

I've modified configuration accordingly and it works fine.

Thanks again.
Nick

haproxy enablement issues

[Nikolaos Milas]

Hello,

I am using v2.11.6 on CentOS 5 (and 6 and 7), without postscreen (it's a 
final destination server, not accepting mail from the Internet).


I have tried enabling the proxy protocol to make postfix log correctly 
user data when connections arrive from our haproxy proxy (currently in 
test mode).


So, I added (in main.cf) the directive:

   smtpd_upstream_proxy_protocol = haproxy

and I expected that things would continue as they normally do, except 
when a connection originates from our haproxy server (which lies on a 
different network), in which case postfix would log the client IP 
Address rather than the proxy's address.


But as soon as I reloaded postfix (after the above change), postfix 
stopped accepting normal connections:


Aug 19 17:13:54 vmail postfix/postfix-script[24279]: refreshing the 
Postfix mail system
Aug 19 17:13:55 vmail postfix/master[22272]: reload -- version 2.11.6, 
configuration /etc/postfix
Aug 19 17:14:09 vmail postfix/smtpd[24327]: warning: haproxy read: 
timeout error

Aug 19 17:14:09 vmail postfix/smtpd[24327]: connect from unknown[unknown]
Aug 19 17:14:09 vmail postfix/smtpd[24327]: disconnect from unknown[unknown]
Aug 19 17:14:12 vmail postfix/smtpd[24330]: warning: haproxy read: 
timeout error

Aug 19 17:14:12 vmail postfix/smtpd[24330]: connect from unknown[unknown]
Aug 19 17:14:12 vmail postfix/smtpd[24330]: disconnect from unknown[unknown]
...

If I understand right, it seems as if postfix is trying to read from a 
haproxy each and every time, whereas in fact it should do so only when a 
connection originates from a haproxy proxy.


Am I doing something wrong? Should I configure things differently?

Please advise.

Thanks in advance,
Nick

Re: haproxy enablement issues

[Nikolaos Milas]

On 20/8/2015 2:41 μμ, Wietse Venema wrote:


Postfix does not receive text followed by newline within the
time limit (1 second).

In other words the proxy doesn't send the HAPROXY header line.
That does not happen automatically. You need to turn it on.


It is turned on the proxy itself, but the log lines listed are from 
other clients, not from the proxy!


With the setting:

   smtpd_upstream_proxy_protocol = haproxy

does postfix expect the HAPROXY header line from ALL clients? If so, how 
can we enforce the above setting e.g. ONLY for the ip address(es) of the 
proxy?


Please clarify.

Thanks,
Nick

MX Points to Loopback error

[Nikolaos Milas]

Hi,

We have set up one (of many) mailing lists using Postfix / LDAP as an alias.

In one case, one of the members of the mailing list, has tried to send a 
message to the mailing list and it was delivered fine to all other 
members except to his own mail address:


   mikebl...@lcc.uma.es (expanded from project-...@noa.gr): host
 correoe1.uma.es[150.214.47.230] said: 554 5.7.1
   mikebl...@lcc.uma.es:
   Senderaddress rejected: MX points to Loopback address [RFC1700] (in
   replyto RCPTTO command)

Delivery Report:

   Reporting-MTA: dns; vmail.noa.gr
   X-NOA-Mail-Srv-XAPITI-XPICTOY-Queue-ID: DE9006D6770
   X-NOA-Mail-Srv-XAPITI-XPICTOY-Sender: rfc822; mikebl...@lcc.uma.es
   Arrival-Date: Sun, 17 May 2015 00:47:15 +0300 (EEST)

   Final-Recipient: rfc822; mikebl...@lcc.uma.es
   Original-Recipient: rfc822;project-...@noa.gr
   Action: failed
   Status: 5.7.1
   Remote-MTA: dns; correoe1.uma.es
   Diagnostic-Code: smtp; 554 5.7.1 mikebl...@lcc.uma.es: Sender
   address rejected:
MX points to Loopback address [RFC1700]

This does not seem to have happened in other cases that I know of.

Can you please suggest a reason of this rejection or suggest a way to 
further investigate?


The error message is not meaningful to me (and an Internet search did 
not help me).


The full log from the server is:

May 17 00:47:15 vmail postfix/smtpd[4332]: DE9006D6770: 
client=mailgw3.noa.gr[2001:648:2ffc:126::2]
May 17 00:47:15 vmail postfix/cleanup[4370]: DE9006D6770: 
message-id=5d7d3d48fa5d44d2e7e49d5d2352f...@lcc.uma.es
May 17 00:47:16 vmail postfix/qmgr[2603]: DE9006D6770: 
from=mikebl...@lcc.uma.es, size=3406, nrcpt=11 (queue active)
May 17 00:47:16 vmail postfix/smtpd[4332]: disconnect from 
mailgw3.noa.gr[2001:648:2ffc:126::2]
May 17 00:47:16 vmail postfix/pipe[4371]: DE9006D6770: 
to=us...@noa.gr, orig_to=project-...@noa.gr, relay=dovecot, 
delay=0.81, delays=0.28/0.014/0/0.52, dsn=2.0.0, status=sent (delivered 
via dovecot service)

... other list members...
May 17 00:47:18 vmail postfix/smtp[4484]: DE9006D6770: 
to=mikebl...@lcc.uma.es, orig_to=project-...@noa.gr, 
relay=correoe1.uma.es[150.214.47.230]:25, delay=2.4, 
delays=0.28/0.024/1.6/0.55, dsn=5.7.1, status=bounced (host 
correoe1.uma.es[150.214.47.230] said: 554 5.7.1 mikebl...@lcc.uma.es: 
Sender address rejected: MX points to Loopback address [RFC1700] (in 
reply to RCPT TO command))

... other list members...

Although IMHO it should not be of any importance to resolve this case, 
the alias is set up (in LDAP) as follows:


   dn: cn=project-wp2,ou=Aliases,dc=noa,dc=gr
   objectClass: maillist
   owner: cn=AstroAdmins,ou=Groups,dc=noa,dc=gr
   mailacceptinggeneralid: project-...@noa.gr
   cn: project-wp2
   maildrop: us...@noa.gr
   maildrop: mikebl...@lcc.uma.es
   maildrop: ...

Please advise.

Thanks in advance,
Nick

Re: MX Points to Loopback error

[Nikolaos Milas]

On 18/5/2015 2:05 μμ, Wietse Venema wrote:


The problem in this case is that you should send mailing list mail
with a list-specific envelope sender address (for example,
owner-project-...@noa.gr), instead of the original poster's sender
address (mx...@lcc.uma.es).

Don't use the list submission address (project-...@noa.gr) as the
envelope sender address: that may cause mail delivery loops.


Thank you for the reply.

Please let me ask for a clarification: Since list members always use the 
mailing list name (owner-project-...@noa.gr) as the recipient and their 
own mail address as the sender, and it is important that the sender's 
actual identity (name, email) be used as the sender, how can can this be 
resolved?


The situation is complicated by the fact that the members of the mailing 
list send mail to this address through their own mailing servers and not 
by using our mail server as their initial SMTP (outgoing) server.


Should postfix be configured in a particular way to send these messages 
properly constructed? If so, how?


Thanks,
Nick

Re: MX Points to Loopback error

[Nikolaos Milas]

On 18/5/2015 8:41 μμ, Wietse Venema wrote:


You need to distribute those submissions with an envelope adress sender set to
a list-specific envelope sender address


OK, as I understand I should use sender_canonical_maps to rewrite 
envelope sender.


Should this new (rewritten) mail sender address be a real address (alias 
or local account) or it can be a dummy one?


I would assume that it should better be a real address/alias. If so, 
shouldn't it be somehow dynamically (since the real sender is always 
different) associated to the real sender address, so that possible 
server (error etc.) messages can be returned to it? How can this be done?


Thanks again,
Nick

Re: MX Points to Loopback error

[Nikolaos Milas]

On 18/5/2015 9:54 μμ, Wietse Venema wrote:


You should configure the MAILING LIST, so that it sends all
mail, from all senders, with its own envelope sender address (for
example, an envelope sender of owner-listn...@example.com).

In the case of Postfix, and a mailing list that is configured in
a Postfix aliases(5) file,  see the aliases(5) manpage and look for
the owner alias.

With other mailing list systems, see the corresponding documentation.

Wietse



If I understand right, it would be enough to create another alias (in 
LDAP in our case) as the following:


   dn: cn=owner-project-wp2,ou=Aliases,dc=noa,dc=gr
   objectClass: virtualaccount
   cn: owner-project-wp2
   mailacceptinggeneralid: owner-project-...@noa.gr
   maildrop: maillistsad...@noa.gr
   owner: cn=TechAdmins,ou=Groups,dc=noa,dc=gr

I expected that Postfix should automatically pick the above alias as 
envelope sender of messages directed to project-...@noa.gr.


However I am not seeing this behavior. Am I still missing something 
(quite possible)?


A couple of settings in our setup:

   owner_request_special = yes
   expand_owner_alias = no
   recipient_delimiter =

The only possible problem I can think of is that the alias name 
(mailacceptinggeneralid) of both the list and the owner might need to be 
local-part-only (without a domain specification).


However, I remember that I had problems when setting up aliases on this 
system (some years ago) without domain names, so all aliases configured 
are designated with domains (and, thankfully, they work flawlessly).


Could this be the problem and if so, is there a way to make owner- 
alias work using domain names in the alias specifications?


Thanks,
Nick

Building a mail service with redundancy

[Nikolaos Milas]

Hello,

In the past I have discussed some failover options for incoming mail.

Now, I would appreciate your advice on outgoing mail (and POP3/IMAP 
mailbox access) in building a mail service with redundancy.


We already have two production mail servers, vmail1 and vmail2, running 
postfix/dovecot (with virtual users on LDAP), each running on a separate 
data center.


vmail1 is the main one (i.e. the one used to send mail and host users' 
mailboxes), vmail2 is only used as a backup.


Mailboxes are using Maildir format and are being synced (in near 
real-time) using dovecot dsync service.


IMPORTANT: Each of the two servers has its own distinct server name and 
its own separate certificate. This allows proper operation of IMAP syncing.


Our goal is to allow our users to always use one address, say 
*vmail.example.com*, to automatically access SMTP/POP3/IMAP services at 
vmail1 and, only if vmail1 is down, at vmail2.


DNS could offer a solution: creating, for example, a CNAME 
vmail.example.com pointing to vmail1 would probably solve the problem 
by using a very low DNS record refresh time and use a script to monitor 
vmail1 availability; if vmail1 is down, the script could update the 
CNAME to point to vmail2 instead (and force a zone refresh). This could 
leave a small downtime window (depending on the refresh time configured).


Yet, I am thinking that it may be more advantageous to use another two 
*identical* VMs (one on each data center, for redundancy) running NGINX, 
with the common name (and a common certificate for) vmail.example.com 
(in DNS: an A record with two IP Addresses). Both proxies would 
automatically redirect (via NGINX) all SMTP/POP3/IMAP requests to vmail1 
and, only if vmail1 is down, to vmail2, while the user will always 
see/configure vmail.example.com as their mail server.


Is this a feasible/suggested scenario? Any hints, experiences, 
configuration advice, pitfalls, alternative approaches etc. would be 
greatly appreciated.


Please advise.

Thanks in advance,
Nick

Re: High Availability

[Nikolaos Milas]

On 7/4/2014 8:17 πμ, Patrick Ben Koetter wrote:


On Linux use DRBD to replicate mail queues between a pair of machines and crm
to control a second Postfix instance that will be started locally to pickup
any remaining mails once the partner machine dies.


Hmm, I think DRBD is only advised in cases where the net link between 
the replicated boxes is guaranteed and low-latency; so I guess probably 
this is not a working solution between different data centers as 
discussed here.


However, I can't suggest alternatives, I am afraid...

My instinct (though not always correct :-) ) tells me also that 
near-real-time file sync (like using lsyncd with rsync) should not be a 
suggested solution for queue replication.


One could investigate whether Apache Helix (http://helix.apache.org/) 
can be a viable solution.


All the best,
Nick

Backup relay possible?

[Nikolaos Milas]

Hello,

On our gateway server, we have:

   transport_maps = hash:/etc/postfix/transportmap

   /etc/postfix/transportmap
   noa.gr  relay:[vmail.noa.gr]
   admin.noa.grrelay:[vmail.noa.gr]
   nestor.noa.gr   relay:[vmail.noa.gr]
   space.noa.grrelay:[vmail.noa.gr]
   meteo.noa.grrelay:[vmail.noa.gr]
   gein.noa.gr relay:[vmail.noa.gr]
   technet.noa.gr  relay:[vmail.noa.gr]
   astro.noa.grrelay:[vmail.noa.gr]

Is there a way to configure a backup relay (i.e. a secondary next 
hop), so as to, if vmail.noa.gr does not respond, then incoming mail can 
be attempted to be delivered to the backup relay (for example to 
vmail1.noa.gr)?


I understand that this complicates delivery in the sense that if the 
backup relay does not respond as well, postfix should decide what to do; 
I would think that it would keep it in the queue and retry both relay 
points each time, with the same sequence.


Please advise on possible ways in which we can configure such a 
secondary relay.


Thanks and best regards,
Nick

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 2:04 μμ, Birta Levente wrote:



http://www.postfix.org/postconf.5.html#fallback_relay



Oh, thanks!

So, since the two conditions are by default fulfilled:

 * In main.cf specify relay_transport = relay,
 * In master.cf specify -o fallback_relay = (i.e., empty) at the end
   of the relay entry.

...it is enough to specify in transport maps:

   noa.gr relay:[vmail.noa.gr]
   noa.gr relay:[vmail1.noa.gr]
   admin.noa.gr relay:[vmail.noa.gr]
   admin.noa.gr relay:[vmail1.noa.gr]
   ...

Right?

Thanks,
Nick

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 4:10 μμ, Birta Levente wrote:


Not really IMHO

AFAIK since you have two entries with same key in transport map, 
postfix will choose the first.


I think this is the way:

main.cf:
fallback_relay=[vmail1.noa.gr]

transport_map:
noa.gr relay:[vmail.noa.gr]
admin.noa.gr relay:[vmail.noa.gr] 


Hmm, yes; reading the docs, I understand you are right. This is the way 
it should be. (It was careless on my part to draw hastily a wrong 
conclusion.)


Yet, this means that a fallback relay will be common for all entries in 
transport_maps (which is fine in my case), but there is no way to define 
fallback relays per domain as in transport_maps?


Nick

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 4:32 μμ, James Day wrote:


noa.gr relay:noa.gr.local

I have then configured A records for the multiple relay destinations, queries 
are then balanced in a DNS round robin fashion.


Yes, I undertand. However, we don't want balancing (our traffic is low - 
but we want failover).


In my case, this scenario could be implemented by using a very low TTL 
for vmail.noa.gr and then use a script to monitor target and, in case it 
does not respond, then update the A record to point to another IP address.


This assumes that Postfix observes the TTL for DNS lookups (on names 
used in transport maps).


However, in my case I would not go for this solution because we want 
vmail and vmail1 to have different host names (they include Dovecot IMAP 
servers replicated using dsync). They cannot behave to others as being 
the same host.


One thing that could be done would be to monitor vmail.noa.gr on the 
gateway servers and if it does not respond, then use a script to update 
transport maps and reload postfix. It does not sound very elegant to me...


(Nor can we employ multiple IP addresses per server; it is a VPS service 
offering a single IP address per VM.)


Nick

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 5:04 μμ, Robert Sander wrote:


You do not need A records, but you can instead add MX records with
priority. This way your use case is implemented.


No, these are not MXs. They are internal (final destination) servers. 
MXs are gateway servers relaying to the internal one (for which we are 
trying to setup failover).


Nick

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 4:47 μμ, Birta Levente wrote:


I'm not sure and this is not tested, but maybe you can:

transport_map:
noa.gr relay1:[vmail.noa.gr]
admin.noa.gr relay2:[vmail.noa.gr]

add to master.cf:
relay1 unix - - n - - smtp
-o fallback_relay=[firstwhateverhost]
relay2 unix - - n - - smtp
-o fallback_relay=[secondwhateverhost] 


Interesting! It might work. I'll try to find an opportunity to test it.

Yet, IMHO it might be a good idea for some future version to support 
full lookup tables in fallback_relay e.g. in the form (just speculating):


---
fallback_relay_map:
---
noa.gr relay:[vmail1.noa.gr,vmail2.noa.gr]
tech.noa.gr relay:[vmail1.noa.gr,vmail5.noa.gr]
...

All the best,
Nick

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 6:18 μμ, Robert Sander wrote:


I know that they are not official MX. The whole point is that you
create an internal domain name with two MX records pointing to these
servers. This is then used in your transport map and nowhere else.


Hmm, interesting. It sounds a good idea!

Thank you!

All the best,
Nick

Re: Spam email containing Hidden Text

[Nikolaos Milas]

What software are you using?

For example, are you using amavisd-new, clamav, spam-assassin ?

...And additionally, postscreen (with dnsbl !), perhaps sane-security 
(as part of clamav), fail2ban (to block repetiive unsuccessful 
connections) etc. ?


Use sa-learn too!

Perhaps this is more an amavisd question rather than a postfix one!

All the best,
Nick

On 15/3/2014 5:35 μμ, jason hirsh wrote:


I have been noting an big increase in spam that contains html and images   One 
common feature is that these emails contain hidden text that only shows up when 
I look at the source

I found samples of this at http://www.hoax-slayer.com/hidden-text-spam.html

Right now I have been having some success by blocking a country , in the most 
common instance .eu, in the header checks

but can’t think of a body check to catch this when it spread further


I would appreciate any suggestions

Re: Spam email containing Hidden Text

[Nikolaos Milas]

On 15/3/2014 8:28 μμ, David Mehler wrote:


Hello,

I'm also interested in this. I'm using Postfix with DSpam and I would
like to avoid this type of spam.

Thanks.
Dave.


Please, stay on the list.

From experience, I'd advise to use an internal mail server as a final 
destination, then setup at least one mailgateway for filtering your 
incoming mail.


I don't know about DSpam or other software, we are using a solution as 
the one I described.


You may find a lot of guides on the Internet for setting things up. For 
example, on CentOS:


http://wiki.centos.org/HowTos/Amavisd
http://andrewpuschak.com/dokuwiki/doku.php?id=centos_6_email_server
http://nolabnoparty.com/en/secure-postfix-amavisd-clamav-spamassassin/

The links are simply indicative (from googling). As usual, YMMV...

All the best,
Nick

Gateway Server queues too many mails

[Nikolaos Milas]

Hello,

I am running Postfix 2.9.4 (for more than a year now) on CentOS 6.5 
x86_64 as a gateway server with postscreen, amavis, spamassassin. The 
server receives mail from the Internet and forwards (relays) clean mail 
to the final internal mail server (also running postfix).


Today, I am facing the following problem, which I have not faced again:

Mail is received, but most of it is queued up on the active queue, 
without it being delivered. However, some mails do get through.


I tried postqueue -f but without success; in the log I see:

Feb 27 14:06:08 mailgw1 postfix/postqueue[26088]: name_mask: ipv4
Feb 27 14:06:08 mailgw1 postfix/postqueue[26088]: name_mask: ipv6
Feb 27 14:06:08 mailgw1 postfix/postqueue[26088]: inet_addr_local: 
configured 2 IPv4 addresses
Feb 27 14:06:08 mailgw1 postfix/postqueue[26088]: inet_addr_local: 
configured 3 IPv6 addresses


 I have now more than 1700 messages on the active queue, which is 
usually empty (we receive low mail volumes).


What can I do to resolve the situation? Can I safely restart postfix 
(e.g. service postfix restart) (without risking losing the queued 
mails)? Please advise!


Thanks in advance,
Nick

Re: Gateway Server queues too many mails

[Nikolaos Milas]

Thanks Wietse,

I am following on this thread, replying to my own sent mail, because 
your reply is still in the queue... (I read it with pfqueue).


I did not see anything suspicious looking for 
errors/fatals/warnings/panics, except perhaps:


Feb 27 05:27:02 mailgw1 postfix/postscreen[16639]: warning: getpeername: 
Transport endpoint is not connected -- dropping this connection


Could this point to a problem? And how should I deal with it?

Additional info:

qshape shows:

   T  5 10 20  40  80 160 320 640 
1280 1280+
  TOTAL 2217 11 31 44 105 297 484 829 
4160 0
   astro.noa.gr  813  3  2 24  39 106 187 268 
1840 0
 noa.gr  673  2 23 12  35  81 154 257 
1090 0
   meteo.noa.gr  353  3  1  4  11  60  67 140 67
0 0
   space.noa.gr  192  2  2  4   7  40  34  77 26
0 0
gein.noa.gr  165  1  3  0  10   8  37  80 26
0 0
   admin.noa.gr   21  0  0  0   3   2   5 7   4
0 0


All destination domains are the internally hosted ones (on our final 
destination server) to which the gateway should relay all (clean) 
incoming mail.


For your information, here are the postfix processes running (excerpt 
from ps axjf):


1  5698  5698  5698 ?   -1 Ss   0   6:17 
/usr/libexec/postfix/master
 5698  5707  5698  5698 ?   -1 S   89   3:56  \_ qmgr -l -t 
fifo -u
 5698 13360  5698  5698 ?   -1 S   89   0:17  \_ anvil -l 
-t unix -u
 5698 16639 16639 16639 ?   -1 Ss  89   0:46  \_ postscreen 
-l -n smtp -t inet -u -s 2
 5698  4726  5698  5698 ?   -1 S   89   0:01  \_ scache -l 
-t unix -u
 5698 20848  5698  5698 ?   -1 S   89   0:00  \_ dnsblog -z 
-t unix -u
 5698 22554  5698  5698 ?   -1 S   89   0:00  \_ dnsblog -z 
-t unix -u
 5698 23736  5698  5698 ?   -1 S   89   0:00  \_ dnsblog -z 
-t unix -u
 5698 24112  5698  5698 ?   -1 S   89   0:00  \_ dnsblog -z 
-t unix -u
 5698 24197  5698  5698 ?   -1 S   89   0:00  \_ dnsblog -z 
-t unix -u
 5698 24744  5698  5698 ?   -1 S   89   0:00  \_ dnsblog -z 
-t unix -u
 5698 24956  5698  5698 ?   -1 S   89   0:01  \_ 
trivial-rewrite -n rewrite -t unix -u
 5698 26604 26604 26604 ?   -1 Ss  89   0:00  \_ verify -l 
-t unix -u
 5698 26647  5698  5698 ?   -1 S   89   0:00  \_ smtpd -t 
pass -u -o stress=
 5698 26664  5698  5698 ?   -1 S   89   0:00  \_ smtpd -t 
pass -u -o stress=
 5698 2  5698  5698 ?   -1 S   89   0:00  \_ smtpd -t 
pass -u -o stress=
 5698 26726  5698  5698 ?   -1 S   89   0:00  \_ smtpd -t 
pass -u -o stress=
 5698 26734  5698  5698 ?   -1 S   89   0:00  \_ smtpd -t 
pass -u -o stress=
 5698 26741  5698  5698 ?   -1 S   89   0:00  \_ smtpd -t 
pass -u -o stress=
 5698 26754  5698  5698 ?   -1 S   89   0:00  \_ cleanup -z 
-t unix -u
 5698 26755  5698  5698 ?   -1 S   89   0:00  \_ smtpd -t 
pass -u -o stress=
 5698 26757  5698  5698 ?   -1 S   89   0:00  \_ cleanup -z 
-t unix -u
 5698 26760  5698  5698 ?   -1 S   89   0:00  \_ smtpd -t 
pass -u -o stress=
 5698  3639  5698  5698 ?   -1 S   89   0:00  \_ smtpd -n 
127.0.0.1:10025 -t inet -u -o content_filter= -o local_recipient_maps= 
-o relay_recipient_
 5698  3713  5698  5698 ?   -1 S   89   0:00  \_ cleanup -z 
-t unix -u
 5698  3758  5698  5698 ?   -1 S   89   0:00  \_ pickup -l 
-t fifo -u
 5698  3780  5698  5698 ?   -1 S   89   0:00  \_ lmtp -n 
smtp-amavis -t unix -u -o smtp_data_done_timeout=1200 -o 
smtp_send_xforward_command=yes -o
 5698  3815  5698  5698 ?   -1 S   89   0:00  \_ smtpd -n 
127.0.0.1:10025 -t inet -u -o content_filter= -o local_recipient_maps= 
-o relay_recipient_
 5698  3816  5698  5698 ?   -1 S   89   0:00  \_ lmtp -n 
smtp-amavis -t unix -u -o smtp_data_done_timeout=1200 -o 
smtp_send_xforward_command=yes -o
 5698  3861  5698  5698 ?   -1 S   89   0:00  \_ smtp -n 
relay -t unix -u -o smtp_fallback_relay=


Trying to release a particular mail fails with:

[root@mailgw1 ~]# postqueue -v -i 3fZY516W5NzMmGF
postqueue: name_mask: ipv4
postqueue: name_mask: ipv6
postqueue: inet_addr_local: configured 2 IPv4 addresses
postqueue: inet_addr_local: configured 3 IPv6 addresses
postqueue: flush_send_file: queue_id 3fZY516W5NzMmGF
postqueue: connect to subsystem public/flush
postqueue: send attr request = send_file
postqueue: send attr queue_id = 3fZY516W5NzMmGF
postqueue: public/flush socket: wanted attribute: status
postqueue: input attribute name: status
postqueue: input attribute value: 0
postqueue: public/flush socket: wanted attribute: (list terminator)
postqueue: input attribute 

Re: Gateway Server queues too many mails

[Nikolaos Milas]

On 27/2/2014 4:10 μμ, Wietse Venema wrote:


All MASTER daemon logging is suspect.

All ERROR logging is suspect.

All FATAL logging is suspect.

All PANIC logging is suspect.

Please show all master/error/fatal/panic logging.


I had no such log entries (only warnings).

I found that amavisd was using too much CPU and I thought something 
could be wrong with it. I tried restarting amavisd and then all active 
messages vanished from the active queue.


However, CPU issues with amavisd did not end and qshape started again 
showing messages piling in the active queue; I decided I should also 
restart clamd daemon to make things clearer and monitor the situation. 
After that, I am not seeing the problem.


Yet, I now have 2120 suspended messages; when running: postqueue -p 
those entries are indicated as:


(delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: 
Connection refused)


(10024 is an amavisd port)

Now that amavis seems to be running correctly, how can I resend 
immediately those suspended mails?


Please advise,
Nick

Re: Gateway Server queues too many mails

[Nikolaos Milas]

On 27/2/2014 4:40 μμ, Nikolaos Milas wrote:

Now that amavis seems to be running correctly, how can I resend 
immediately those suspended mails? 


Unfortunately, I am afraid that after I run postqueue -f and messages 
were moved to the active queue, amavisd again topped CPU at 100% and 
postfix started piling up again messages.


So, I restarted amavisd and messages moved again to the deferred queue.

Now,  I am thinking of temporarily removing the:

   content_filter = smtp-amavis:[127.0.0.1]:10024

line from main.cf and *restarting* postfix (or rebooting the server), 
then run postqueue -f again, at lest to have queued messages delivered.


Can I leave the

   127.0.0.1:10025 inet n  -   n   -   - smtpd
   ...

line in master.cf as is? I think it won't hurt being there, even if 
amavisd is not running. Please confirm.


Can I restart Postfix/server safely for the queue? I need to make sure 
these messages in the deferred queue do NOT get lost.


Nick

Re: Gateway Server queues too many mails

[Nikolaos Milas]

On 27/2/2014 5:36 μμ, lst_ho...@kwsoft.de wrote:

You should use a process limit matching the number of amavisd 
processes to not feed it with too much concurrent smtp connections. 
Have a look how smtp-amavis is setup in master.cf, if there is no 
limit set the default (100) applies. This *could* be your problem.


Thank you,

Here is what I have in my master.cf:

127.0.0.1:10025 inet n -   n   -   -   smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks


Also, in /etc/amavisd.conf:

   $max_servers = 2;

...and I only see two amavisd processes (as expected); but these two 
take 49,9% of the CPU each.


So, any advice would be welcome.

One critical question, now, is whether I can stop/restart postfix/server 
without risking losing deferred mail messages!


Thanks,
Nick

Re: Gateway Server queues too many mails

[Nikolaos Milas]

On 27/2/2014 5:10 μμ, Nikolaos Milas wrote:


Now,  I am thinking of temporarily removing the:

   content_filter = smtp-amavis:[127.0.0.1]:10024

line from main.cf and *restarting* postfix (or rebooting the server), 
then run postqueue -f again, at least to have queued messages 
delivered. 


I am worried that this may not be a solution, because the deferred mails 
seem to be waiting to be delivered to amavis (127.0.0.1:10024):


delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: 
Connection refused


...so, even after a reload without the content_filter, these mail 
messages may still be trying to be delivered to 127.0.0.1:10024.


Am I thinking right?

If yes, can the deferred messages be re-processed from start (as new 
incoming messages) so as to avoid delivery through amavisd? How?


Please advise.

Thanks,
Nick