On 10/21/20 11:13 AM, Wietse Venema wrote:
If your XCLIENT arguments match Postfix logging, including the name
and IP address info
they do
and you used HELO or EHLO depending on Postfix's proto= logging
proto=ESMTP, so I used EHLO
then I think that the Postfix SMTP daemon cannot distingui
On 10/21/20 4:31 PM, Wietse Venema wrote:
PGNet Dev:
Two questions:
clear.
i'll focus just on just the dmarc bits.
both debugging opendmarc, and replacing it with another option to see if
behavior changes.
xclient's extremely helpful in any case.
i'm swapping out opendkim milter from a postfix setup.
inbound verification's been replaced with fastmail's authentication_milter --
in smtpd mode
so far, behaving well.
outbound signing on postfix sumbission has been replaced with dkimpy-milter.
seems to work nicely for rsa signing.
support's
On 10/26/20 4:19 AM, Patrick Ben Koetter wrote:
There's only *one* SigningTable, but there are two KeyTables – one for rsa and
the other one for ed25519. Maybe you are using an older version of
dkimpy-milter. IIRC it had a related error in the man page.
oops, typo.
yep, I've one ST & 2 KTs, on
On 10/26/20 8:41 AM, Patrick Ben Koetter wrote:
using latest available via pip, v1.2.2. can try master branch.
That will suffice.
fwiw, no diff -- same problem -- with 1.2.2 or master
I haven't had any problems either on Debian, Ubuntu or ARCH Linux using
dknewkey.
tho i doubt it matters
On 10/26/20 8:52 AM, PGNet Dev wrote:
headed for @launchpad.
for anyone interested,
https://bugs.launchpad.net/dkimpy-milter/+bug/1901569
thx! @ here
on a new, from-distro-pkgs install of Postfix, i've noted an intermittent perms
problem
it'll run just fine for quite awhile, then I start seeing a steady stream of
...
Oct 28 15:02:40 svr019 postfix/postdrop[64624]: warning:
mail_queue_enter: create file maildrop/553726.64624:
On 10/28/20 10:00 AM, Viktor Dukhovni wrote:
On Wed, Oct 28, 2020 at 09:01:38AM -0700, PGNet Dev wrote:
Oct 28 15:02:40 svr019 postfix/postdrop[64624]: warning:
mail_queue_enter: create file maildrop/553726.64624: Permission denied
Oct 28 15:02:45 svr019 postfix/postdrop[32688
On 10/28/20 10:32 AM, Viktor Dukhovni wrote:
Indeed a process with "no_new_privs" will not be able to run sendmail(1)
to submit new email.
noted.
that said, this _just_ reappeared here,
postfix/postdrop[15673]: warning: mail_queue_enter: create file
maildrop/678088.15673: Permission denied
On 10/28/20 11:30 AM, Viktor Dukhovni wrote:
You might start with:
# grep -r NoNewPrivileges /etc/systemd
and all other directories with systemd unit files.
yup. already done.
nothing --other than the now "=false" (need to double check if that's the same
as _removing_ it ) in pflogsum
On 10/28/20 11:36 AM, PGNet Dev wrote:
On 10/28/20 11:30 AM, Viktor Dukhovni wrote:
You might start with:
# grep -r NoNewPrivileges /etc/systemd
i couldn't find any direct, relevant postdrop/maildrop, or NoNewPrivileges,
references i chased sendmail usage instances instead.
On 10/28/20 2:38 PM, Wietse Venema wrote:
One possible way out is to skip the Postfix sendmail command, and
to use a "mini sendmail" program that submits mail via SMTP.
i've typically got msmtp rattling around.
Obviously that will fail when Postfix is down.
noted.
not ideal, but not critic
On 10/28/20 2:38 PM, Wietse Venema wrote:
One possible way out is to skip the Postfix sendmail command, and
to use a "mini sendmail" program that submits mail via SMTP.
adding an msmtp sender as the VirusAction script in clamav milter, though a bit
of 'extra', certainly is the simplest.
easy
On 10/29/20 6:51 AM, @lbutlr wrote:
Recently the behavior of spamass-milter or the underlying spamassasin has
changed such that the originating IP for secured submission email is being
tagged for PBL/Dynamic scores. This does;t happen often, but since all mail is
only accepted via TLSv1.2 this
On 10/29/20 7:33 AM, @lbutlr wrote:
Thank you, I will take a look at that. Spamass-milter is supposed to do this
with the -a flag which is missing from the config for some reason above, so I
will first add that flag and see if it works. Curious that it is coming up
infrequently, however, since
On 10/29/20 9:30 AM, @lbutlr wrote:
but otherwise point 1 is a real sticking point as things outside the normal ports channel
tend to fall off the "hey, I need to check that for updates" train far too
easily.
sure.
i've not dealt with *bsd packaging for a _very_ long time, so have no sense f
my postfix config includes
unknown_client_reject_code = 550
per docs, I understand
The SMTP server always replies with 450 when the mapping failed due to
a temporary error condition.
generally, does what I want.
a legit sender, sending from their provider, accidentally typo'd
On 10/29/20 5:48 PM, Viktor Dukhovni wrote:
On Thu, Oct 29, 2020 at 05:44:55PM -0700, PGNet Dev wrote:
my postfix config includes
unknown_client_reject_code = 550
--
a legit sender, sending from their provider, accidentally typo'd their own
sender ad
On 10/30/20 5:04 AM, Matus UHLAR - fantomas wrote:
unknown_client_reject_code uses client IP address<->hostname mapping
what you want here is unknown_address_reject_code
i'd read refs for "unknown_client_reject_code"
client without valid address <=> name mapping
'name mapping' seemed
I've a postfix instance accepting mail submission from internal clients.
The configuration includes a DKIM signer
[int.mx.example.com]:465 inet n - n - - smtpd
...
-o smtpd_milters=unix:/run/dkimpy-milter/dkimpy-milter.sock
-o milter_macro_daemon_name=DKIM_ORIGINA
It is not possible to switch Milter options in the middle of an SMTP session.
ah, understood.
Maybe you can configure an exception for the sender's domain in
the dkim milter configuration.
not immediately obvious how with current milter dkimpy-milter, but there are
other options.
A frontend postfix install I've in place is being subject to a literal tear-down+relocate of its various backends (relays to other postfix & imap instances).
The building's being torn down, and the occupant's relocating. Not the best
managed process, but oh well.
It's a one-time event; not s
On 11/22/20 11:58 AM, Wietse Venema wrote:
This would be good fit for virtual_alias_maps (and maybe adding
domains to virtual_alias_domains, see note below).
Good then. That'll work nicely.
All my postfix+imap backends have the virtual_alias_foo mappings; the frontend
checks via address_veri
On 11/22/20 11:58 AM, Wietse Venema wrote:
This would be good fit for virtual_alias_maps (and maybe adding
domains to virtual_alias_domains, see note below). virtual_alias_maps
replaces the envelope recipient without replacing header addresses,
and it works for single-recipient mail equ
On 11/23/20 6:48 AM, Wietse Venema wrote:
Note that smtpd does not implement the virtual alias mapping. It
merely determines if the recipient address should be accepted or
rejected.
The virtual alias mapping happens on the other end of the
smtpd_proxy_filter (presumably, another smtpd process th
fyi,
http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client
"A null client is a machine that can only send mail. It receives no mail from the
network, and it does not deliver any mail locally. A null client typically uses POP, IMAP
or NFS for mailbox access."
running
postconf mail_version
mail_version = 3.6.0
I've recently started seeing in logs
postfix/bounce[10732]: warning: [built-in]: zero result in delay template
conversion of parameter "maximal_queue_lifetime_days"
postfix/bounce[10732]: warning: please
On 5/20/21 9:20 AM, Wietse Venema wrote:
PGNet Dev:
running
postconf mail_version
mail_version = 3.6.0
I've recently started seeing in logs
postfix/bounce[10732]: warning: [built-in]: zero result in delay template
conversion of para
On 5/22/21 8:25 AM, Simon Wilson wrote:
What am I missing,as a commercial email verification service what are they
trying to validate?
Likely someone/somewhere submitted that^ email to a list, on your ... ahem ... "behalf".
Now, some client is using that list -- whether they originated it or
On 5/22/21 9:16 AM, Simon Wilson wrote:
You've misunderstood.
yep, sorry.
this
No. My email used is the same one I use on this list.
threw me off.
in this instance it's a valid check they are running on an email address I have
provided for a transaction.
... not that there aren't ot
> Postfix stable release 3.4.1 is available.
upgrading, as per usual here, from a working 3.4.0 build to 3.4.1, now fails
cd postfix-3.4.1
make tidy
make -f Makefile.in MAKELEVEL= Makefiles
(echo "# Do not edit -- this file documents how Postfix was built for
your machine."; /bin/sh
> and may (?) need a Linux5 ...
fwiw, a simple cleanup,
perl -pi -e 's|(Linux\.\[)34(\])|${1}345${2}|g' makedefs
perl -pi -e 's|(defined\(LINUX4\))|${1} \|\| defined(LINUX5)|g'
src/util/sys_defs.h
at least gets to a successful build
dunno if there's other issues w/ linux5. yet.
On 3/9/19 6:37 AM, Wietse Venema wrote:
> I jhave a concrete question: does anyone have an URL for an installable
> image (ISO, memory stick, etc.) that installs an OS with kernel5
> and enough user-land tools to build Postfix? My expectation is to
> fire up an empty VM, install the OS on the empty
To add a possible data point to the convo,
at least one distro, OpenSUSE, is already toying with apparently poorly
thought-thru patches (aka, not vetted/source here, from upstream) --
e,g, here,
https://build.opensuse.org/package/view_file/openSUSE:Factory/postfix/postfix-linux45.patch?expand=
On 3/10/19 3:19 PM, Wietse Venema wrote:
>* LINUX5 is supported, based on sanity checks with a Rawhide
> prerelease.
fyi, still
cd postfix-3.4.2
make tidy
make -f Makefile.in MAKELEVEL= Makefiles
(echo "# Do not edit -- this file d
The list of DMARC et al deployment tools
https://dmarc.org/resources/deployment-tools/#Message_Validation
identifies
"DMARC, DKIM and SPF Test System at NIST"
https://www.had-pilot.com/
as one of available tests.
afaict, it's the only (?) test site that provides simpl
On 3/18/19 2:27 PM, Scott Kitterman wrote:
On Monday, March 18, 2019 02:15:30 PM PGNet Dev wrote:
&/or, is there another available tool that does the same -- testing inbound?
If you don't have one already, set up a gmail account that autoforwards to
you.
Send your test mail to t
I've got a legitimate sender, FedEx, sending expected, automated emails, that's
got a missing RDNS PTR record on their sending host. For my config, Postfix
currently rejects is with a 450:
Apr 1 16:22:11 mx postfix/postscreen-internal/smtpd[4947]: NOQUEUE:
reject: RCPT from pvma00055.
I run postfix 3.4.5.
I typically reject on unknown reverse hostname; it's a policy I'm comfortable
with.
For a number of correspondents that use outlook.com for outbound, I
occasionally see failures crop up for the same sender, then just
'automagically' resolve.
E.g., for a single sender, her
currently, my config does include
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks
check_helo_access pcre:${config_directory}/helo_access.pcre
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
permit
is adding to head of helo_access.pcre
/.*\.out
That should be safe, because the OK here cannot affect how a recipient
will be evaluated.
Do you have any reasonable advice as to a better approach to share?
I'm aware of the list of stats tools
http://www.postfix.org/addon.html
Looking for experience/recommendations from users here.
grep's served me well enough for just a few servers.
As I switch to all/only Postfix at multiple locations, something easily
automated/deployed is of interest.
DIY
fwiw, shared here long ago -- don't remember the origin
Restrictions execution order:
postscreen, smtpd_mumble_restrictions, milter SMTP command inspection,
smtpd_proxy_filter, header/body_checks, milter header/body inspection,
content_filter
No solution so far, I think there are 2-3 open bug reports on
github, but since the project is very dead, nobody has bothered to
fix the problem.
So what's the option for a more upto date version of DKIM milter for debian?
fwiw, for inbound DKIM, DMARC, ARC, etc, this
https://github.com/fas
* Scott Kitterman via Postfix-users :
That would be great. I started dkimpy-milter for two reasons: I wanted to
experiment with the new DKIM crypto types that lead to RFC 8463 and there
didn't seem to be much activity with opendkim maintenance (this is, of course,
ironic given how well I did wit
The problem with dkimpy/dkimpy-milter, is that they don't exist in enterprise
distros (Alma, Rocky, Oracle) via EPEL.
FWIW, it's a trivial install with python/pip, and plays nicely in a venv.
works a charm here.
rpm spec's also straightforward.
here's one for Fedora,
https://src.fe
Thanks. As of a few minutes ago there's a dkimpy 1.1.1, although there aren't
any changes that will affect you one way or the other if you're using it for
dkimpy-milter.
thx,
Name: dkimpy
Version: 1.1.1
Name: dkimpy-milter
Version: 1.2.3
the 'hardest' part is
That's a surprise - thanks. I've just checked and seen that opendkim and
opendmarc set up init-style services. I'll do a systemd service for this
milter, but I'd be interested to hear if there's any policy or other advice
about whether we should be using master.cf or a service.
ultimately up
what is the practical difference between using inet or UNIX domain
socket in /etc/opendkim.conf ?
@ http://www.opendkim.org/staging/opendkim-README
see section "SOCKET SELECTION"
What do I need to put into /etc/postfix/main.cf instead of inet:localhost ?
smtpd_milters = inet:localhost:889
fyi
if SpamAssassin's in use in your Postfix message flow, then its TextCat plugin,
https://spamassassin.apache.org/full/4.0.x/doc/Mail_SpamAssassin_Plugin_TextCat.html
does a decent job of detecting many langs. good enough for scoring but NOT for
outright policy reject, here.
__
fedora 38/rhel pkg builds carry a few patches
i'm trying to figure out what still needs to be carried
one was reported @ distro
Bug 1977732 - [Regression] postfix "cleanup" crashes when processing messages
containing a "whitespace-only" fullname
https://bugzilla.redhat.com/sho
This was fixed almost 2 years ago in postfix-3.3.19, postfix-3.4.22,
postfix-3.5.12, postfix-3.6.3.
thx.
dropped from Fedora v3.0.8 pkgs:
https://src.fedoraproject.org/rpms/postfix/blob/rawhide/f/postfix.spec#_807
___
Postfix-users mailing list -
For sending, it uses (like pretty much any network application) whatever the
TCP stack in your OS chooses.
this may be useful
https://www.postfix.org/postconf.5.html#smtp_bind_address
"An optional numerical network address that the Postfix SMTP client should bind to
when making an IPv4 conn
a server that i don't have shell access to atm has, today, started seeing
undelivered mail from only one domain -- *outbound.protection.outlook.com.
apparently, everything else inbound is flowing. and, i'm told, inbound from
outlook.com was working yesterday.
all i've got so far is this log sn
What are some domains your server accepts mail for? Do you perhaps
publish DANE TLSA records and have botched certificate rotation?
See if dropping the DST cross cert from your certificate chain will
help. That root CA has long ago expired.
nothing in that cert chain reports a past date.
wha
, May 02, 2023 at 11:09:59AM -0400, PGNet Dev wrote:
what root CA expiry are you referring to?
The DST root, that issued the ISRG X1 cross cert.
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
yikes. missed that by a mile!
From my renewal.conf file
Also look into other possibilities, the DST Root issue is a bit of a
longshot. If you can get an account on Outlook.com, send mail and see
if it bounces with usable diagnostics in the bounce.
i changed the preferred chain here, and for all my domains (thx o/ !). it
certainly didn't hurt.
but
I changed the preferred chain here, and for all my domains (thx o/ !).
it certainly didn't hurt.
Presumably you then also *force* renewed the certificate chain.
yes
After the dns cleanup, switching BACK the preferred chain didn't
reinit the issue.
Did you *force* renewal at that point?
a
I don't even know whether RedHat exposes any mechanisms for applications> to opt-out
of crypto policy and use only application-driven OpenSSL> configuration. This is
should perhaps be looked into in the Postfix 3.9> timeframe.
from my notes dealing with new Fedora crypto-policies on a number o
i updated a postfix server,
postconf mail_version
mail_version = 3.8.1
on
lsb_release -rd
Description:Fedora release 38 (Thirty Eight)
Release:38
with
openssl version
OpenSSL 3.0.9 30 May 2023
The Fedora crypto policies apply to both servers and clients. Your
client doing the tests is almost certainly using the default SECLEVEL=2,
which disables TLSv1 and TLSv1.1. If you configure the client to also
allow these protocols, the test will work as expected. The problem is
not on the Post
101 - 161 of 161 matches
Mail list logo
