Re: $queue_directory/private permissions
On Mon, Mar 25, 2019 at 01:32:28AM -0400, Viktor Dukhovni wrote: > 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. How exactly does "root" get permissions to read the directory? It's DAC permissions (0700 with owner postfix) do not provide it. Bastian -- Beam me up, Scotty, there's no intelligent life down here!
Re: $queue_directory/private permissions
Bastian Blank: > On Mon, Mar 25, 2019 at 01:32:28AM -0400, Viktor Dukhovni wrote: > > 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. > > How exactly does "root" get permissions to read the directory? It's DAC > permissions (0700 with owner postfix) do not provide it. Root always has permission in the UNIX file permission model. However this is off-topic for a Postfix mailing list. Wietse
Re: Relay Access Denied
> On Mar 25, 2019, at 1:37 AM, Viktor Dukhovni > wrote: > > This must be some Apple-specific Postfix setting, are you running Apple's > Postfix binaries? mail_version = 2.9.2 _ Rich in Toronto @ VP
Re: Relay Access Denied
> On Mar 25, 2019, at 1:37 AM, Viktor Dukhovni > 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. At the moment, that directive is commented-out. I was getting reports that it was not being used: $ sudo postfix reload /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: smtpd_relay_restrictions=permit_mynetworks permit_sasl_authenticated reject_unauth_destination postfix/postfix-script: refreshing the Postfix mail system Either way, with that directive active or not, same results: Relay access denied >> 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. I don’t know why. This is how the package came. >> smtpd_tls_ciphers = medium >> smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL > > The default settings are better. These are the defaults it came with. >> use_sacl_cache = yes > > This must be some Apple-specific Postfix setting, are you running Apple's > Postfix binaries? They all are. Yes this is Mountain Lion (10.8.5) Server. Is there a default setup for LAN access? I find their setup rather restrictive. I’ve had issues with this setup before. Security in the LAN is tight already, so I don’t need my mail server keeping me out. Cheers _ Rich in Toronto @ VP
Re: $queue_directory/private permissions
On 2019-03-25 1:32 a.m., Viktor Dukhovni wrote: >> 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. OK, thank you. Regards, Simon
Re: Relay Access Denied
On Mon, 25 Mar 2019, VP Lists wrote: On Mar 25, 2019, at 1:37 AM, Viktor Dukhovni wrote: This must be some Apple-specific Postfix setting, are you running Apple's Postfix binaries? mail_version = 2.9.2 smtpd_relay_restrictions appeared only with 2.10. That explains the "unused parameter" warning. Your (old) version should IIRC use only smtpd_recipient_restrictions. But given that you have some weird version on a weird OS with a weird configuration, I will have to pass. Best is to reinstall, from a trusted (non-Apple?) source, and start with default configuration, which is very sane. Only touch what you actually need to touch, and leave the rest to Viktor and Wietse, who seem to know what they do :) Cheers and good luck.
Re: Relay Access Denied
> On Mar 25, 2019, at 7:23 AM, VP Lists wrote: > >>> smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated >>> permit >> >> This is rather pointless. Delete it, it serves no purpose. >>> smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks >>> reject unauthdestination permit >> >> This is rather busted. > > I don’t know why. This is how the package came. No, it did not. It probably had: smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, permit what you have rejects all inbound email from outside senders. >>> smtpd_tls_ciphers = medium >>> smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL >> >> The default settings are better. > > These are the defaults it came with. Take the defaults from a more recent release: # Remove this from main.cf, taking the empty default smtpd_tls_exclude_ciphers = # Add these: smtpd_tls_ciphers = medium smtpd_tls_protocols = !SSLv2, !SSLv3 smtp_tls_ciphers = medium smtp_tls_protocols = !SSLv2, !SSLv3 As for why "mynetworks" is not enough, perhaps time to look at your master.cf file... -- Viktor.
Re: Relay Access Denied
> On Mar 25, 2019, at 11:28 AM, Viktor Dukhovni
> wrote:
>
> As for why "mynetworks" is not enough, perhaps time to look
> at your master.cf file...
Here it is:
# Postfix master process configuration file. For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==
# Begin auto-generated section
# This section of the master.cf file is auto-generated by the Server Admin
# Mail backend plugin whenever mails settings are modified.
smtp inet n - n - 1 postscreen
smtpd pass - - n - - smtpd
dnsblog unix - - n - 0 dnsblog
tlsproxy unix - - n - 0 tlsproxy
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
smtp unix - - n - - smtp
# === End auto-generated section ===
# Modern SMTP clients communicate securely over port 25 using the STARTTLS
command.
# Some older clients, such as Outlook 2000 and its predecessors, do not properly
# support this command and instead assume a preconfigured secure connection
# on port 465. This was sometimes called "smtps", but such usage was never
# approved by the IANA and therefore conflicts with another, legitimate
assignment.
# For more details about managing secure SMTP connections with postfix, please
see:
# http://www.postfix.org/TLS_README.html
# To read more about configuring secure connections with Outlook 2000, please
read:
# http://support.microsoft.com/default.aspx?scid=kb;en-us;Q307772
# Apple does not support the use of port 465 for this purpose.
# After determining that connecting clients do require this behavior, you may
choose
# to manually enable support for these older clients by uncommenting the
following
# four lines.
#465 inet n - n - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
#628 inet n - n - - qmqpd
pickupfifo n - n 60 1 pickup
-o content_filter=
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
tlsmgrunix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounceunix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verifyunix - - n - 1 verify
sacl-cache unix - - n - 1 sacl-cache
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
# 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
retry 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
scacheunix - - n - 1 scache
#
#
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent. See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
#
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
#maildrop unix - n n - - pipe
# flags=DRhu user=vmail argv=/usr/local
Re: pishing from ME
Before you freak out about whether or not your passwords were leaked please understand that this is might be a complete hoax that takes advantage of the fact that e-mail is just a string of text passed from server to server. Using telnet you can forge the From: field in an e-mail message provided the originating mail server isn't actually verifying the field (you would be surprised how many mail servers don't verify the From: field; instructions can be found here http://www.postfix.org/ADDRESS_VERIFICATION_README.html). While I do agree that password security is of the utmost importance, I'm going to go out on a fairly sturdy limb and say that the person that sent you this message does not have your password. If you look more closely at the messages (look at the full text of the message including the headers) you may find that the message has a doctored From: header. I'm looking at 7 of these same messages right now and as far as I can tell none of the messages originated from my mail server. My sample messages originate from: * 72.44.21.179 * 177.124.77.243 * 191.243.54.241 * 177.44.18.124 * 41.87.208.154 * 114.129.22.74 * 177.38.1.191 What makes these messages even more suspect is the fact that they originate from outside of my network, wind their way through the internet, hit my external mail exchange, and then make their way to my mail server for delivery. If the person does have my password (as they suggest) why didn't they log onto my externally accessible mail server and then send the messages? Just my 2 cents. On Sun, Mar 24, 2019 at 1:02 AM Viktor Dukhovni wrote: > > On Sat, Mar 23, 2019 at 04:59:46PM -0700, Alice Wonder wrote: > > > > This is not necessarily true. A hashed password can be brute-forced. > > > > Only with a weak password and/or a weak hash algorithm, and it is harder > > with just the latter. > > Yes, but "not weak" in the context of password hashes means something > different than in the usual context of collision-resistant message > fingerprints. The hash needs to be non-deterministic (randomly > salted), and ideally resistant to various space-time and parallelization > tradeoffs, which means irreducibly both CPU and memory intensive. > > Which means algorithms along the lines of Argon2, not SHA2. > > -- > Viktor. -- PGP Fingerprint: 0x1A97C6259125882867EC8410FA1E7CD382BFC760
Re: Relay Access Denied
> > On Mar 25, 2019, at 11:28 AM, Viktor Dukhovni > wrote: > > As for why "mynetworks" is not enough, perhaps time to look > at your master.cf file... Fixed. I needed a “From” header for gmail to accept it. That was inside the Ruby gem configuration. Cheers _ Rich in Toronto @ VP
What's new in log file parsers? Anything better than pflogsumm?
I'm looking for a postfix log file parser that can provide the number of messages delivered, broken down by sending domain, and per hour counts on a daily basis. I have looked at pflogsumm, but it seems a bit dated, and isn't as flexible as I had hoped. Can someone suggest any alternatives? -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: What's new in log file parsers? Anything better than pflogsumm?
> On Mar 25, 2019, at 1:13 PM, Jim Rice wrote: > > I'm looking for a postfix log file parser that can provide the number of > messages delivered, > broken down by sending domain, and per hour counts on a daily basis. Make sure you have a clear definition of "messages delivered"? Is it messages accepted, or envelopes sent? A multi-recipient message can split into multiple downstream "envelopes", each carrying a subset of the (possibly rewritten) recipients. Also, a single message might not be delivered in a short time interval, recipients might be deferred, and delivered hours or days later. For custom reporting, you might end up rolling your own. For inspiration, you can take a look at the "collate" Perl script bundled with recent Postfix source releases (auxiliary/collate/collate.pl). One thing that script does not address is maintaining state for messages not yet fully processed across multiple log files as they roll over. It should not be too difficult to modify it to run non-stop and track log file rollover, producing a stream of output. Or to checkpoint state to a file and and resume with that state with the next batch of logs. -- Viktor.
