Re: Relay Access Denied

[Viktor Dukhovni]

On Sun, Mar 24, 2019 at 06:38:40PM -0400, VP Lists wrote:

> # /var/log/mail.log:
> Mar 24 18:37:35 alpha.mydomain.com postfix/postscreen[11964]: CONNECT from 
> [192.168.1.4]:52147 to [192.168.1.6]:25
> Mar 24 18:37:35 alpha.mydomain.com postfix/postscreen[11964]: PASS OLD 
> [192.168.1.4]:52147
> Mar 24 18:37:35 alpha.mydomain.com postfix/smtpd[11966]: connect from 
> unknown[192.168.1.4]
> Mar 24 18:37:35 alpha.mydomain.com postfix/smtpd[11966]: NOQUEUE: reject: 
> RCPT from unknown[192.168.1.4]: 554 5.7.1 : Relay access 
> denied; from= to= proto=ESMTP 
> helo=

This is likely blocked by "smtpd_relay_restrictions", or your
mynetworks setting had not yet taken effect for all the running
smtpd(8) processes.

> smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated permit

This is rather pointless.

> smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks
> reject unauthdestination permit

This is rather busted.

> smtpd_tls_ciphers = medium
> smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL

The default settings are better.

> use_sacl_cache = yes

This must be some Apple-specific Postfix setting, are you running Apple's
Postfix binaries?

-- 
Viktor.

Re: $queue_directory/private permissions

[Viktor Dukhovni]

> On Mar 24, 2019, at 8:17 PM, Simon Deziel  wrote:
> 
> I was not clear because my issue is indeed with those accesses before
> privs get dropped. I noticed that tlsproxy accesses tlsmgr's socket
> while still running as root so it depends on its CAP_DAC_READ_SEARCH
> capability. My workaround to not need that cap was to change the perms
> to be like:
> 
> $ ls -ld /var/spool/postfix/private/
> drwx--x--- 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/
> 
> And with that group search bit on, the tlsproxy process no longer
> depends on the CAP_DAC_READ_SEARCH cap to get to tlsmgr's socket.
> 
> In other words, this group search bit allows to _not_ depend on the
> CAP_DAC_READ_SEARCH which sounded like an improvement to me. That's what
> I wanted to validate with the mailing list.

Sorry, that breaks the Postfix internal access control model in unsupported
ways.  Root needs to be able to read the directory with its standard
permissions.

-- 
Viktor.

Re: $queue_directory/private permissions

[Simon Deziel]

On 2019-03-24 5:46 p.m., Wietse Venema wrote:
> Simon Deziel:
>> I can think of 2 ways to workaround this. One is to tell Apparmor to
>> grant the tlsproxy process the needed capability and the other is to
>> have the $queue_directory/private directory perms set to 0710 with the
>> same owner/group.
> 
> Sorry, changes to Postfix permissions are not supported. 
> 
> You are welcome to configure AppArmor etc. so that they will not
> break legitimate operation of Postfix, but such configuration is
> considered platform-specific, and outside the scope of Postfix.

Apparmor is what highlighted the reliance on capabilities that seemed
avoidable with a group search bit on the private dir so I wanted to hear
the opinion of experts. I'm well aware that adding Apparmor or diverging
from the default perms means I'm on my own, sorry if that was off-topic
for postfix-users@.

Regards,
Simon

Re: $queue_directory/private permissions

[Simon Deziel]

On 2019-03-24 6:02 p.m., Viktor Dukhovni wrote:
>> On Mar 24, 2019, at 4:33 PM, Simon Deziel  wrote:
>>
>> I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I
>> noticed the tlsproxy process is apparently trying to connect to tlsmgr's
>> Unix socket while still running as root.
> 
> The premise is false.  On all the systems I've used, the "private" directory
> belongs to the "$mail_owner" user:
> 
>   $ ls -ld /var/spool/postfix/private/
>   drwx--  2 postfix  wheel  24 Mar  3 02:49 /var/spool/postfix/private/

Sorry, I should have included that as it look the same here:

 $ ls -ld /var/spool/postfix/private/
 drwx-- 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/

> and connections to peer services (e.g. to tlsmgr(8)) often happen after privs
> are dropped. 

Agreed, but I'm not concerned about the after.

> Some requests may happen before that, but the directory must be
> generally readable by $mail_owner.

I was not clear because my issue is indeed with those accesses before
privs get dropped. I noticed that tlsproxy accesses tlsmgr's socket
while still running as root so it depends on its CAP_DAC_READ_SEARCH
capability. My workaround to not need that cap was to change the perms
to be like:

 $ ls -ld /var/spool/postfix/private/
 drwx--x--- 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/

And with that group search bit on, the tlsproxy process no longer
depends on the CAP_DAC_READ_SEARCH cap to get to tlsmgr's socket.

In other words, this group search bit allows to _not_ depend on the
CAP_DAC_READ_SEARCH which sounded like an improvement to me. That's what
I wanted to validate with the mailing list.

Thanks,
Simon

Re: reject_unknown_reverse_client_hostname query

[Wietse Venema]

Viktor Dukhovni:
> On Sun, Mar 24, 2019 at 09:00:24PM +, Nick Howitt wrote:
> 
> [ Please avoid pasting "non-breaking space" characters into
>   your email.  It is tedious to have to convert these to ASCII. ]
> 
> > The header is below (x headers and DKIM removed):
> >  
> > Return-Path: 
> > Received: from hz.cn (unknown [220.191.208.116])
> >  by howitts.co.uk (Postfix) with ESMTP id 6614E401361E
> >  for ; Sun, 24 Mar 2019 10:09:30 + (GMT)
> 
> The "unknown" means that either:
> 
> 1. The IP did not resolve to a PTR (name) record
> 2. The name did not resolve back to the same IP
> 
> In case 2. the IP could have had a reverse name.
> 
> > Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
> > mail.hz.cn does not resolve to address 220.191.208.116
> > Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
> > unknown[220.191.208.116]
> 
> This is case 2.
> 
> > Have I misunderstood something or is something else at play?
> 
> Inattention to detail, and/or unfamiliarity of the meaning of
> "unknown" in the Received header.

To clarify, 

1) The reverse name (PTR) lookup succeeded. The client would be NOT
be rejected by reject_unknown_reverse_client_hostname.

2) The IP address lookup for the name produced the wrong IP address.
The client would be rejected by reject_unknown_client_hostname.

Wietse

Re: I don't realize why this email was not delivered

[Bill Cole]

On 24 Mar 2019, at 18:15, dstonek wrote:


Where can that be configured?
I posted Header and Body checks.
It is strange because the sender is a regular user the recipient 
receives

emails from.


My guess is that your 'header_checks' regex /.icu/ is matching something 
in the full x-microsoft-antispam-message-info header. Postfix does not 
log all of very long headers and that's a very loose regex because you 
have the wildcard '.' and probably meant /\.icu/ That seems like a very 
risky pattern to me but do as you want with your own mail. More 
generally, header_checks is a very weak tool for spam filtering by 
design. If you want anything like spam control, you need something 
external.


Note that "x-microsoft-antispam-message-info" is not documented, but it 
almost always contains >300 or <100 characters and most often is 428 
characters.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: reject_unknown_reverse_client_hostname query

[Viktor Dukhovni]

On Sun, Mar 24, 2019 at 10:28:27PM +, Nick Howitt wrote:

> >>  Received: from hz.cn (unknown [220.191.208.116])
> >>   by howitts.co.uk (Postfix) with ESMTP id 6614E401361E
> >>   for ; Sun, 24 Mar 2019 10:09:30 + 
> >> (GMT)
> >
> > The "unknown" means that either:
> >
> >  1. The IP did not resolve to a PTR (name) record
> >  2. The name did not resolve back to the same IP
> >
> > In case 2. the IP could have had a reverse name.
> >
> >>  Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
> >>  mail.hz.cn does not resolve to address 220.191.208.116
> >>  Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
> >>  unknown[220.191.208.116]
> >
> > This is case 2.

We know it is case 2., because Postfix logged failure to map
"mail.hz.cn" back to the address.  So it got the "220.191.208.116"
from somewhere, the only possible source being the PTR record, the
IP address had one at the time the message was received.

> Sorry but I am unfamiliar with the term "non-breaking space". Is pasting 
> from PuTTy or Notepad++ causing an issue?

The text you posted had lots of Unicode non-breaking spaces (U+00A0),
rather than ASCII spaces (U+0020).

> As far as I can see 220.191.208.116 has no PTR so should fall under your 
> case 1? Or have I misunderstood?

It may not now, but it did then.

> [root@server ~]# dig -x 220.191.208.116 @8.8.8.8
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> -x 220.191.208.116 @8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29403
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

[ Yet more non-breaking spaces in the pasted dig output. :-( ]

This is not an NXDOMAIN, rather a lookup failure, so the PTR may
be there, just not working presently:

http://dnsviz.net/d/116.208.191.220.in-addr.arpa/dnssec/

[220.191 is at this time a lame delegation]

-- 
Viktor.

Re: Relay Access Denied

[VP Lists]

> On Mar 24, 2019, at 6:31 PM, Viktor Dukhovni  
> wrote:
> 
> On Sun, Mar 24, 2019 at 05:36:56PM -0400, VP Lists wrote:
> 
>> smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated 
>> permit
> 
> What do you expect this to do?

At this point I have no clue.  I think it was in there from previous messing.  

>> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
>> reject_unauth_destination
>> 
>> Same error.  
> 
> Care to post logs?  Care to post "postconf -nf" (older versions
> "postconf -n") output?

# /var/log/mail.log:
Mar 24 18:37:35 alpha.mydomain.com postfix/postscreen[11964]: CONNECT from 
[192.168.1.4]:52147 to [192.168.1.6]:25
Mar 24 18:37:35 alpha.mydomain.com postfix/postscreen[11964]: PASS OLD 
[192.168.1.4]:52147
Mar 24 18:37:35 alpha.mydomain.com postfix/smtpd[11966]: connect from 
unknown[192.168.1.4]
Mar 24 18:37:35 alpha.mydomain.com postfix/smtpd[11966]: NOQUEUE: reject: RCPT 
from unknown[192.168.1.4]: 554 5.7.1 : Relay access denied; 
from= to= proto=ESMTP 
helo=
Mar 24 18:37:35 alpha.mydomain.com postfix/smtpd[11966]: disconnect from 
unknown[192.168.1.4]

So below we see that mynetworks includes the LAN for relaying.  But above, it 
says my workstation (192.168.1.4) is unknown.  No clue why.  

$ postconf -nf

biff = no
command_directory = /usr/sbin
config_directory = /Library/Server/Mail/Config/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /Library/Server/Mail/Data/mta
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
dovecot_destination_recipient_limit = 1
html_directory = /usr/share/doc/postfix/html
imap_submit_cred_file = /Library/Server/Mail/Config/postfix/submit.cred
inet_interfaces = loopback-only
inet_protocols = all
mail_owner = _postfix
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 10485760
mydomain_fallback = localhost
mynetworks = 192.168.1.0/24, 192.168.1.23, 192.168.1.4, 127.0.0.0/8, [::1]/128 
# RF
newaliases_path = /usr/bin/newaliases
queue_directory = /Library/Server/Mail/Data/spool
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
sample_directory = /usr/share/doc/postfix/examples
sendmail_path = /usr/sbin/sendmail
setgid_group = _postdrop
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated permit
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks
reject unauthdestination permit
smtpd_tls_ciphers = medium
smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
use_sacl_cache = yes


_
Rich in Toronto @ VP

Re: Relay Access Denied

[Viktor Dukhovni]

On Sun, Mar 24, 2019 at 05:36:56PM -0400, VP Lists wrote:

> smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated permit

What do you expect this to do?

> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
> reject_unauth_destination
> 
> Same error.  

Care to post logs?  Care to post "postconf -nf" (older versions
"postconf -n") output?

-- 
Viktor.

Re: reject_unknown_reverse_client_hostname query

[Nick Howitt]

On 24/03/2019 22:13, Viktor Dukhovni wrote:

On Sun, Mar 24, 2019 at 09:00:24PM +, Nick Howitt wrote:

[ Please avoid pasting "non-breaking space" characters into
   your email.  It is tedious to have to convert these to ASCII. ]


The header is below (x headers and DKIM removed):
  
 Return-Path: 

 Received: from hz.cn (unknown [220.191.208.116])
  by howitts.co.uk (Postfix) with ESMTP id 6614E401361E
  for ; Sun, 24 Mar 2019 10:09:30 + (GMT)

The "unknown" means that either:

 1. The IP did not resolve to a PTR (name) record
 2. The name did not resolve back to the same IP

In case 2. the IP could have had a reverse name.


 Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
 mail.hz.cn does not resolve to address 220.191.208.116
 Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
 unknown[220.191.208.116]

This is case 2.


Have I misunderstood something or is something else at play?

Inattention to detail, and/or unfamiliarity of the meaning of
"unknown" in the Received header.

Sorry but I am unfamiliar with the term "non-breaking space". Is pasting 
from PuTTy or Notepad++ causing an issue?


As far as I can see 220.191.208.116 has no PTR so should fall under your 
case 1? Or have I misunderstood?


[root@server ~]# dig -x 220.191.208.116 @8.8.8.8

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> -x 220.191.208.116 @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29403
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;116.208.191.220.in-addr.arpa.  IN  PTR

;; Query time: 14 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Mar 24 22:24:00 GMT 2019
;; MSG SIZE  rcvd: 57

Re: I don't realize why this email was not delivered

[Wietse Venema]

dstonek:
> Where can that be configured?
> I posted Header and Body checks.
> It is strange because the sender is a regular user the recipient receives
> emails from.

You can find header_checks settings with one of the following commands:

$ postconf header_checks
$ postconf -P | grep header_checks

Wietse

Re: I don't realize why this email was not delivered

[dstonek]

Where can that be configured?
I posted Header and Body checks.
It is strange because the sender is a regular user the recipient receives
emails from.
Thanks.
Daniel



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: reject_unknown_reverse_client_hostname query

[Viktor Dukhovni]

On Sun, Mar 24, 2019 at 09:00:24PM +, Nick Howitt wrote:

[ Please avoid pasting "non-breaking space" characters into
  your email.  It is tedious to have to convert these to ASCII. ]

> The header is below (x headers and DKIM removed):
>  
> Return-Path: 
> Received: from hz.cn (unknown [220.191.208.116])
>  by howitts.co.uk (Postfix) with ESMTP id 6614E401361E
>  for ; Sun, 24 Mar 2019 10:09:30 + (GMT)

The "unknown" means that either:

1. The IP did not resolve to a PTR (name) record
2. The name did not resolve back to the same IP

In case 2. the IP could have had a reverse name.

> Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
> mail.hz.cn does not resolve to address 220.191.208.116
> Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
> unknown[220.191.208.116]

This is case 2.

> Have I misunderstood something or is something else at play?

Inattention to detail, and/or unfamiliarity of the meaning of
"unknown" in the Received header.

-- 
Viktor.

Re: I don't realize why this email was not delivered

[Wietse Venema]

dstonek:
> To make it simple please take a look at 
> https://serverfault.com/questions/959629/why-this-email-wasnt-delivered-by-postfix-dovecot-procmail
> Thank you

According to the above link:

Mar 22 06:36:21 host postfix/cleanup[12463]: D6D441CA09A0: discard: header 
x-microsoft-antispam-message-info:? 5rSUbtg9a+8v7qvflcvdu8ODNNDgy6QCo+...etc...

According to Postfix header_checks documentation:

   DISCARD optional text...
  Claim successful delivery and silently discard the message.   Do
  not  inspect  the  remainder  of  the  input  message.   Log the
  optional text if specified, otherwise log a generic message.

Someone configured Postfix to discard this message.

Wietse

Re: $queue_directory/private permissions

[Viktor Dukhovni]

> On Mar 24, 2019, at 4:33 PM, Simon Deziel  wrote:
> 
> I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I
> noticed the tlsproxy process is apparently trying to connect to tlsmgr's
> Unix socket while still running as root.

The premise is false.  On all the systems I've used, the "private" directory
belongs to the "$mail_owner" user:

  $ ls -ld /var/spool/postfix/private/
  drwx--  2 postfix  wheel  24 Mar  3 02:49 /var/spool/postfix/private/

and connections to peer services (e.g. to tlsmgr(8)) often happen after privs
are dropped.  Some requests may happen before that, but the directory must be
generally readable by $mail_owner.

-- 
Viktor.

Re: reject_unknown_reverse_client_hostname query

[Nick Howitt]

On 24/03/2019 21:53, Wietse Venema wrote:

Nick Howitt:

I have the follosing restrictions in main.cf:

 smtpd_client_restrictions = permit_mynetworks,
 reject_unknown_reverse_client_hostname

What is the output from "postconf mynetworks"?

If the client matches that, then "permit_mynetworks"
will override reject_unknown_reverse_client_hostname.

Wietse

[root@server ~]# postconf mynetworks
mynetworks = 127.0.0.0/8, [::1]/128, 172.17.2.0/23, $clearglassnetwork

and:

[root@server ~]# postconf clearglassnetwork
clearglassnetwork = 172.19.0.0/16


I would have expected this to have been dropped by the
reject_unknown_reverse_client_hostname filter as 220.191.208.116 does
not have a PTR record. The logs for this transaction (amavis and
opendkim removed to cut the output) are:

 Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
 mail.hz.cn does not resolve to address 220.191.208.116
 Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
 unknown[220.191.208.116]
 Mar 24 10:09:31 server postgrey[800]: action=pass, reason=triplet
 found, delay=724, client_name=unknown,
 client_address=220.191.208.116, sender=g...@hz.gov.cn,
 recipient=usern...@howitts.co.uk
 Mar 24 10:09:31 server postfix/smtpd[8102]: 6614E401361E:
 client=unknown[220.191.208.116]

Re: reject_unknown_reverse_client_hostname query

[Wietse Venema]

Nick Howitt:
> I have the follosing restrictions in main.cf:
> 
> smtpd_client_restrictions = permit_mynetworks,
> reject_unknown_reverse_client_hostname

What is the output from "postconf mynetworks"?

If the client matches that, then "permit_mynetworks"
will override reject_unknown_reverse_client_hostname.

Wietse

> I would have expected this to have been dropped by the 
> reject_unknown_reverse_client_hostname filter as 220.191.208.116 does 
> not have a PTR record. The logs for this transaction (amavis and 
> opendkim removed to cut the output) are:
> 
> Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
> mail.hz.cn does not resolve to address 220.191.208.116
> Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
> unknown[220.191.208.116]
> Mar 24 10:09:31 server postgrey[800]: action=pass, reason=triplet
> found, delay=724, client_name=unknown,
> client_address=220.191.208.116, sender=g...@hz.gov.cn,
> recipient=usern...@howitts.co.uk
> Mar 24 10:09:31 server postfix/smtpd[8102]: 6614E401361E:
> client=unknown[220.191.208.116]

Re: $queue_directory/private permissions

[Wietse Venema]

Simon Deziel:
> I can think of 2 ways to workaround this. One is to tell Apparmor to
> grant the tlsproxy process the needed capability and the other is to
> have the $queue_directory/private directory perms set to 0710 with the
> same owner/group.

Sorry, changes to Postfix permissions are not supported. 

You are welcome to configure AppArmor etc. so that they will not
break legitimate operation of Postfix, but such configuration is
considered platform-specific, and outside the scope of Postfix.

Wietse

Re: Relay Access Denied

[VP Lists]

> On Mar 24, 2019, at 5:20 PM, B. Reino  wrote:
> 
> Sorry for top posting. Mobile client here..

No problem.  I don’t mind top-posting anywhere.

> Your mynetworks has 192.168.0.0/24 but you say you use 192.168.x.x, i.e. 
> 192.168.0.0/16.
> 
> In the headers of your mail I see 192.168.1.4, which would thus not be in 
> mynetworks.

Yes, it’s now corrected.

mynetworks = 192.168.1.0/24 127.0.0.0/8

smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated permit
recipient_delimiter = +
smtpd_tls_ciphers = medium
inet_protocols = all
inet_interfaces = loopback-only
config_directory = /Library/Server/Mail/Config/postfix

smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks 
reject unauthdestination permit

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
reject_unauth_destination


Same error.  


> So you may want to check that..

_
Rich in Toronto @ VP

Re: Relay Access Denied

[B. Reino]

Sorry for top posting. Mobile client here..

Your mynetworks has 192.168.0.0/24 but you say you use 192.168.x.x, i.e. 
192.168.0.0/16.

In the headers of your mail I see 192.168.1.4, which would thus not be in 
mynetworks.

So you may want to check that..
Cheers.


On March 24, 2019 8:35:59 PM UTC, VP Lists  
wrote:
>Hi folks.
>
>I’m on a LAN, with a mail server on OS X Server Mountain Lion. It’s
>running Postfix as a mail server.  
>
>My LAN has a 192.168.x.x range.  I’m getting that error when an app I’m
>developing, is trying to send an email out through this email server to
>the internet.  A gmail address specifically. 
>
>
>
>My main.cf:
>
>biff = no
>command_directory = /usr/sbin
>config_directory = /Library/Server/Mail/Config/postfix
>daemon_directory = /usr/libexec/postfix
>data_directory = /Library/Server/Mail/Data/mta
>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
>dovecot_destination_recipient_limit = 1
>html_directory = /usr/share/doc/postfix/html
>imap_submit_cred_file = /Library/Server/Mail/Config/postfix/submit.cred
>inet_interfaces = loopback-only
>inet_protocols = all
>mail_owner = _postfix
>mailbox_size_limit = 0
>mailq_path = /usr/bin/mailq
>manpage_directory = /usr/share/man
>message_size_limit = 10485760
>mydomain_fallback = localhost
>mynetworks = 192.168.0.0/24 127.0.0.0/8# RF
>newaliases_path = /usr/bin/newaliases
>queue_directory = /Library/Server/Mail/Data/spool
>readme_directory = /usr/share/doc/postfix
>recipient_delimiter = +
>sample_directory = /usr/share/doc/postfix/examples
>sendmail_path = /usr/sbin/sendmail
>setgid_group = _postdrop
>smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated
>permit
>smtpd_recipient_restrictions = permit_sasl_authenticated
>permit_mynetworks reject unauthdestination permit
>smtpd_tls_ciphers = medium
>smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
>tls_random_source = dev:/dev/urandom
>unknown_local_recipient_reject_code = 550
>use_sacl_cache = yes
>postconf: warning: /etc/postfix/main.cf: unused parameter:
>smtpd_relay_restrictions=permit_mynetworks permit_sasl_authenticated
>reject_unauth_destination
>
>I’m hosting a handful of local and FQDN on the LAN, and I develop using
>a machine.local naming scheme.  Just wondering how I can whitelist my
>internal domains to get outgoing emails past my mail server.  Not
>really sure what to post here as well.
>
>Any insight appreciated.
>
>Cheers
>
>
>_
>Rich in Toronto @ VP

reject_unknown_reverse_client_hostname query

[Nick Howitt]

I have the follosing restrictions in main.cf:

   smtpd_client_restrictions = permit_mynetworks,
   reject_unknown_reverse_client_hostname
   smtpd_recipient_restrictions = permit_mynetworks,
   permit_sasl_authenticated, reject_non_fqdn_hostname,
   reject_non_fqdn_sender, reject_non_fqdn_recipient,
   reject_invalid_hostname, check_policy_service
   unix:/var/spool/postfix/postgrey/socket, reject_unauth_pipelining,
   reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org
   smtpd_relay_restrictions = permit_mynetworks,
   permit_sasl_authenticated, reject_unauth_destination
   smtpd_sender_restrictions = permit_mynetworks, check_sender_access
   hash:/etc/postfix/access, permit_sasl_authenticated,
   reject_non_fqdn_sender, reject_invalid_hostname


and I recently received an e-mail I thought should have been rejected. 
The header is below (x headers and DKIM removed):


   Return-Path: 
   Received: from localhost (localhost [127.0.0.1])
     by server.howitts.co.uk (Cyrus
   v2.4.17-Fedora-RPM-2.4.17-8.v7.1) with LMTPA;
     Sun, 24 Mar 2019 10:09:39 +
   Received: from localhost (localhost [127.0.0.1])
    by howitts.co.uk (Postfix) with ESMTP id 16BB7401361E
    for ; Sun, 24 Mar 2019 10:09:39 + (GMT)
   Authentication-Results: server.howitts.co.uk (amavisd-new);
    dkim=pass (2048-bit key) header.d=howitts.co.uk
   Received: from howitts.co.uk ([127.0.0.1])
    by localhost (server.howitts.co.uk [127.0.0.1]) (amavisd-new,
   port 10024)
    with ESMTP id 2mbKEOm3NT5q for ;
    Sun, 24 Mar 2019 10:09:35 + (GMT)
   Received: from localhost (localhost [127.0.0.1])
    by howitts.co.uk (Postfix) with ESMTP id E1436403B6E4
    for ; Sun, 24 Mar 2019 10:09:34 + (GMT)
   Received: from hz.cn (unknown [220.191.208.116])
    by howitts.co.uk (Postfix) with ESMTP id 6614E401361E
    for ; Sun, 24 Mar 2019 10:09:30 + (GMT)
   Received: from [92-245-104-63.mega.kg] (unknown [92.245.104.63])
    by app2 (Coremail) with SMTP id wROGCgAXH_P5Updcy7ZsAw--.3795S5;
    Sun, 24 Mar 2019 17:51:01 +0800 (CST)
   From: 
   Organization: Jkhkuhcoqn
   Subject: [SPAM] username
   User-Agent: SquirrelMail/1.4.8-21.el5.centos
   List-Unsubscribe:
 
,
   

   Message-ID: 
   X-Sender-Info: 
   Date: Sun, 24 Mar 2019 10:51:03 +0100
   To: usern...@howitts.co.uk
   Content-Type: multipart/related;
 boundary="--_com.android.email_77040368709730"
   MIME-Version: 1.0
   Sender: g...@hz.gov.cn


I would have expected this to have been dropped by the 
reject_unknown_reverse_client_hostname filter as 220.191.208.116 does 
not have a PTR record. The logs for this transaction (amavis and 
opendkim removed to cut the output) are:


   Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
   mail.hz.cn does not resolve to address 220.191.208.116
   Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
   unknown[220.191.208.116]
   Mar 24 10:09:31 server postgrey[800]: action=pass, reason=triplet
   found, delay=724, client_name=unknown,
   client_address=220.191.208.116, sender=g...@hz.gov.cn,
   recipient=usern...@howitts.co.uk
   Mar 24 10:09:31 server postfix/smtpd[8102]: 6614E401361E:
   client=unknown[220.191.208.116]
   Mar 24 10:09:32 server postfix/cleanup[8108]: 6614E401361E:
   message-id=
   Mar 24 10:09:34 server postfix/qmgr[4531]: 6614E401361E:
   from=, size=242365, nrcpt=1 (queue active)
   Mar 24 10:09:34 server postfix/smtpd[8127]: connect from
   localhost[127.0.0.1]
   Mar 24 10:09:34 server postfix/smtpd[8127]: E1436403B6E4:
   client=localhost[127.0.0.1]
   Mar 24 10:09:34 server postfix/cleanup[8108]: E1436403B6E4:
   message-id=
   Mar 24 10:09:35 server postfix/qmgr[4531]: E1436403B6E4:
   from=, size=242537, nrcpt=1 (queue active)
   Mar 24 10:09:35 server postfix/smtpd[8127]: disconnect from
   localhost[127.0.0.1]
   Mar 24 10:09:35 server postfix/pipe[8124]: 6614E401361E:
   to=, relay=mailprefilter, delay=4.2,
   delays=3.9/0.01/0/0.28, dsn=2.0.0, status=sent (delivered via
   mailprefilter service)
   Mar 24 10:09:35 server postfix/qmgr[4531]: 6614E401361E: removed
   Mar 24 10:09:35 server postfix/smtpd[8102]: disconnect from
   unknown[220.191.208.116]
   Mar 24 10:09:39 server postfix/smtpd[8146]: connect from
   localhost[127.0.0.1]
   Mar 24 10:09:39 server postfix/smtpd[8146]: 16BB7401361E:
   client=localhost[127.0.0.1]
   Mar 24 10:09:39 server postfix/cleanup[8108]: 16BB7401361E:
   message-id=
   Mar 24 10:09:39 server postfix/qmgr[4531]: 16BB7401361E:
   from=, size=244229, nrcpt=1 (queue active)
   Mar 24 10:09:39 server postfix/smtpd[8146]: disconnect from
   localhost[127.0.0.1]
   Mar 24 10:09:39 server postfix/smtp[8129]: E1436403B6E4:
   to=, relay=127.0.0.1[127.0.0.1]:10024,
   delay=4.

Relay Access Denied

[VP Lists]

Hi folks.

I’m on a LAN, with a mail server on OS X Server Mountain Lion. It’s running 
Postfix as a mail server.  

My LAN has a 192.168.x.x range.  I’m getting that error when an app I’m 
developing, is trying to send an email out through this email server to the 
internet.  A gmail address specifically. 



My main.cf:

biff = no
command_directory = /usr/sbin
config_directory = /Library/Server/Mail/Config/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /Library/Server/Mail/Data/mta
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
dovecot_destination_recipient_limit = 1
html_directory = /usr/share/doc/postfix/html
imap_submit_cred_file = /Library/Server/Mail/Config/postfix/submit.cred
inet_interfaces = loopback-only
inet_protocols = all
mail_owner = _postfix
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 10485760
mydomain_fallback = localhost
mynetworks = 192.168.0.0/24 127.0.0.0/8 # RF
newaliases_path = /usr/bin/newaliases
queue_directory = /Library/Server/Mail/Data/spool
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
sample_directory = /usr/share/doc/postfix/examples
sendmail_path = /usr/sbin/sendmail
setgid_group = _postdrop
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated permit
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks 
reject unauthdestination permit
smtpd_tls_ciphers = medium
smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
use_sacl_cache = yes
postconf: warning: /etc/postfix/main.cf: unused parameter: 
smtpd_relay_restrictions=permit_mynetworks permit_sasl_authenticated 
reject_unauth_destination

I’m hosting a handful of local and FQDN on the LAN, and I develop using a 
machine.local naming scheme.  Just wondering how I can whitelist my internal 
domains to get outgoing emails past my mail server.  Not really sure what to 
post here as well.

Any insight appreciated.

Cheers


_
Rich in Toronto @ VP

$queue_directory/private permissions

[Simon Deziel]

Hello,

I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I
noticed the tlsproxy process is apparently trying to connect to tlsmgr's
Unix socket while still running as root.

Since tlsmgr's socket is stored under $queue_directory/private that has
perms set to 0700 and owned by postfix:root, the tlsproxy process needs
to override the DAC checks using the CAP_DAC_READ_SEARCH capability.

I can think of 2 ways to workaround this. One is to tell Apparmor to
grant the tlsproxy process the needed capability and the other is to
have the $queue_directory/private directory perms set to 0710 with the
same owner/group.

Tuning the private directory perms removes the need for the capability
so that's my current workaround [*] but I'm looking for feedback on the
possible ramifications of this diversion from the default perms.

Regards,
Simon


*: I created postfix-files.d/private-group-search.files with
   "$queue_directory/private:d:$mail_owner:-:710:uc"

P.S: while testing further, I also noticed that smtpd processes need the
same cap to access proxymap's Unix socket also under
queue_directory/private.

I don't realize why this email was not delivered

[dstonek]

To make it simple please take a look at 
https://serverfault.com/questions/959629/why-this-email-wasnt-delivered-by-postfix-dovecot-procmail

  
Thank you



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: pishing from ME

[@lbutlr]

On 24 Mar 2019, at 09:32, Michael  wrote:
> header CUST_DMARC_FAIL Authentication-Results =~ /mydomain\.com; dmarc=fail/
> score CUST_DMARC_FAIL 4.0

Have you checked this against your spam?

You're going to have a lot of problems with a score of 4.0, I expect.


-- 
"Some cause happiness wherever they go; others, whenever they go.." -
Oscar Wilde

Re: pishing from ME

[Michael]

I've been getting these types of email lately too. They're spoofing the 
from header from to make it look like it comes from my domain, but the 
full email headers show the real source:


Received: from mail.promiks.com (unknown [95.130.173.217])

Received: from ([80.38.233.163])
by mail.promiks.com (Promiks Mail Server V3.4.1) with ASMTP (SSL) id 
201903240032330905




Most were getting marked as spam by spamassasin, but a few were getting 
through. I have opendkim and opendmarc running, so I added these rules 
to my spamassasin local.cf:


#dmarc fail
header CUST_DMARC_FAIL Authentication-Results =~ /mydomain\.com; 
dmarc=fail/

score CUST_DMARC_FAIL 4.0

#dmarc pass
header CUST_DMARC_PASS Authentication-Results =~ /mydomain\.com; 
dmarc=pass/

score CUST_DMARC_PASS -1.0


This requires you to have a dmarc record for your domain, but the policy 
can be "none" if you want since this rule is only looking for the 
"dmarc=fail" result from opendmarc. I got these rules from 
https://www.skelleton.net/2015/03/21/how-to-eliminate-spam-and-protect-your-name-with-dmarc/







On 2019-03-22 6:19 pm, Christian Schmitz wrote:


Hi everyone:
I have a small mail server with fewer emails account, The server is:
Opensuse/Postfix/apache

Today i receive a pishing email Words more or less say that i was 
hacked, that
he know my passwords blah blah blah and i must pay on bit_coins. The 
email

content is 100% pishing and no real hacking because sevral reasons:
list@XXX was only created for mailing lists and no other usage
I have not webcam
The hacker not used SASL to get real use of my account.
For forums/website registrations i use mailinator.com

The  curious is that email seem at first time writed from me to myself. 
If my

email is list@xxx the emails say to be list@xxx

So i start a little investigation on LOG file, and all seem that the 
"hacker"
do not know the passwords. Because the emailer has no SASL 
autenticated, so

the "hacker"simply spoof the FROM field:

1)First question: how i can filter the spoofed emails. In other words, 
if the
sender is not authorized to send list@xxx because this emai is managed 
by ME


2)Seccond question :how i can adjust the sender policy to block soft 
fail SPF?


Thanks you all.
Best Regards.
Christian Schmitz

Info extra 1: LOG: /var/log/mail
connect from mmu.ac.ug[62.75.235.12]
Anonymous TLS connection established from mmu.ac.ug[62.75.235.12]: 
TLSv1.2

with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
: SPF softfail (Mechanism '~all' matched): Envelope-from: d...@mmu.ac.ug
: handler sender_policy_framework: is decisive.
: Policy action=PREPEND Received-SPF: softfail (mmu.ac.ug: Sender is 
not
authorized by default to use 'd...@mmu.ac.ug' in 'mfrom' identity, 
however

domain is not currently prepared for false failures (mechanism '~all'
matched)) receiver=schweb; identity=mailfrom; 
envelope-from="d...@mmu.ac.ug";

helo=xray144.theg7.com; client-ip=62.75.235.12
client=mmu.ac.ug[62.75.235.12]
message-id=<5s5jp2.2trzrx165hrq...@mail.mmu.ac.ug>
from=, size=228789, nrcpt=1 (queue active)
disconnect from mmu.ac.ug[62.75.235.12]
to=, relay=virtual, delay=8, delays=6.9/0.02/0/1, dsn=2.0.0,
status=sent (delivered to maildir)
removed

Info extra 2: when i send a email i get the log of sasl autentication:
client=unknown[192.168.XX.XX], sasl_method=LOGIN, sasl_username=YYY@XXX

Info extra 3: received email header
Return-Path: 
X-Original-To: list@XXX
Delivered-To: list@XXX
Received-SPF: softfail (mmu.ac.ug: Sender is not authorized by default 
to
use 'd...@mmu.ac.ug' in 'mfrom' identity, however domain is not 
currently
prepared for false failures (mechanism '~all' matched)) 
receiver=schweb;
identity=mailfrom; envelope-from="d...@mmu.ac.ug"; 
helo=xray144.theg7.com;

client-ip=62.75.235.12
Received: from xray144.theg7.com (mmu.ac.ug [62.75.235.12])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by schweb.com.ar (schweb.com.ar) with ESMTPS id 9EE12450F4
for ; Fri, 22 Mar 2019 07:41:58 -0300 (ART)
Received: from localhost (localhost [127.0.0.1])
by xray144.theg7.com (Postfix) with ESMTP id 50A1C11A0A4A
for ; Fri, 22 Mar 2019 09:58:35 + (UTC)
X-Virus-Scanned: Debian amavisd-new at xray144.theg7.com
Received: from xray144.theg7.com ([127.0.0.1])
by localhost (xray144.theg7.com [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id pFCoeEV4cz8Y for ;
Fri, 22 Mar 2019 09:58:34 + (UTC)
Received: from [IP-45-237-216-17.acesstelecom.com] (unknown 
[168.196.195.30])

(Authenticated sender: d...@mmu.ac.ug)
by xray144.theg7.com (Postfix) with ESMTPSA id 9097B11A042A
for ; Fri, 22 Mar 2019 09:58:20 + (UTC)
Message-ID: <5s5jp2.2trzrx165hrq...@mail.mmu.ac.ug>
X-Sender-Info: 
X-Abuse-Reports-To: 
X-Mailer: ZetaMail50
Content-Type: multipart/related;
boundary="7737CA265D6"
MIME-Version: 1.0
Errors-To: 64342856482eb6c5e0f0aa6...@mail.mmu.ac.ug
To: l...@schweb.com.ar
Subject: list
From: 
Date: Fri, 22 Mar 2019 11:41:41 +0100
Or