On Wed, Apr 17, 2019 at 09:53:14PM -0700, ecsd wrote:
> The documentation should list the parameter as long as it exists
> (supported by the code, which it is) and say it is deprecated
> and not to be used.
It is an obsolete and mostly equivalent form of reject_unauth_destination,
which only dif
On 17.04.19 21:53, ecsd wrote:
*(1)*
On 4/17/19 12:02 AM, Viktor Dukhovni wrote:
On Tue, Apr 16, 2019 at 06:22:12PM -0700, ecsd wrote:
(1) the control "check_relay_domains" is not documented.
It is obsolete, and should no longer be used.
(1) postfix itself says to use it, and (2) it was the o
Hi all,
I'm running Ubuntu 16.04 LTS Server providing Postfix 3.1 and have a
setup in which Postfix generates the following "From"-header for
mails:
> From: supp...@example.org (root host.example.net)
The same config on Ubuntu 18.04 LTS Server with Postfix 3.3 generates
the following header inst
On Thu, Apr 18, 2019 at 11:47:31AM +0200, Thorsten Schöning wrote:
> So, is there some way to get "header_from_format = standard" of
> Postfix 3.3 in Postfix 3.1?
Of cause there is: set the correct header while submitting mail.
Relying on Postfix to fixup stuff is always the least preferred option
Zitat von Wietse Venema :
lst_ho...@kwsoft.de:
This sounds like the feature we will need. I doubt the client would be
able to do real AUTH, but we have to trust/relay based on the CN of a
validated certificate. Is there any progress merging this in the 3.5
line or do i have to poke around wit
Zitat von Emmanuel Fusté :
Hello,
Great piece of work ! It solve a big part of my problem, but sadly I
need to go deeper.
Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :
In the meantime I have completed a patch and sent it to Wietse and
Victor, which adds an option smtpd_sasl_tls_ccert
Le 18/04/2019 à 12:05, lst_ho...@kwsoft.de a écrit :
Zitat von Emmanuel Fusté :
Hello,
Great piece of work ! It solve a big part of my problem, but sadly I
need to go deeper.
Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :
In the meantime I have completed a patch and sent it to Wietse and
Hi,
am I right with the assumption that tls_verify_cert in the mysql table
uses the native provided ssl-verify-server-cert algorithm provided by
MariaDB?
Because it doesn't work as expected with IP and it is known that the
MariaDB mechanism is broken as of now regarding verifying against IPs in
th
Zitat von Emmanuel Fusté :
You need the relay_clientcerts map with relay_clientcerts_auto mode.
Put the fingerprint or pkey_fingerprint and the mapped SASL identity
in the file and it will work
For example:
43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6 xxx.kwsoft.de
Will try that, bu
Guten Tag Thorsten Schöning,
am Donnerstag, 18. April 2019 um 11:47 schrieben Sie:
> So, is there some way to get "header_from_format = standard" of
> Postfix 3.3 in Postfix 3.1?
One can manually change the order of fields of the From-header using
some regular expression and "smtp_header_checks":
ecsd:
> If I am writing production software (i.e. the end users have a
> very vested interest in it working properly), then if I see the
> user attempt to give me "empty" for a symbol required to be nonblank
> and for which I otherwise have a default value in hand, I would
> syslog that I had refus
lst_ho...@kwsoft.de:
> What is the way to go to take part of the feature development? I looks
> like we need a slight modification of the auth external as described.
Mailin glist discussions.
Eventually there will be a postfix--nonprod release that combines
all the code (jay) and none of th
> On Apr 18, 2019, at 5:47 AM, Thorsten Schöning wrote:
>
> So, is there some way to get "header_from_format = standard" of
> Postfix 3.3 in Postfix 3.1?
You can install Postfix 3.3 or later. But if all you want is to see
which machine "root" send an email from, see the template null-client
con
Zitat von Wietse Venema :
lst_ho...@kwsoft.de:
What is the way to go to take part of the feature development? I looks
like we need a slight modification of the auth external as described.
Mailin glist discussions.
Eventually there will be a postfix--nonprod release that combines
all th
The logs show that postfix examines the recipients before the milter is
given the chance to see them.
I have a milter that detects certain RCPT patterns harassing a domain
name and will discard (not bounce) the mail,
but that code cannot be reached because postfix will bounce for a bad
recipient
On 18 Apr 2019, at 13:15, ecsd wrote:
>
> The logs show that postfix examines the recipients before the milter is given
> the chance to see them.
> I have a milter that detects certain RCPT patterns harassing a domain name
> and will discard (not bounce) the mail,
> but that code cannot be reac
> On Apr 18, 2019, at 12:01 PM, Wietse Venema wrote:
>
> Eventually there will be a postfix--nonprod release that combines
> all the code (jay) and none of the guarantees (bleh).
>
> I am not convinced that stuffing arbitrary PKI identities into a
> SASL identity is necessarily a good idea.
ecsd:
> The logs show that postfix examines the recipients before the milter is
> given the chance to see them.
Indeed. Milter sees only things that Postfix is willing accept,
after Postfix has had a chance to modify it. I am pretty sure that
is how they are supposed to be used (if Milters were p
Re: Viktor Dukhovni
I took your suggestions about reconfig and things have improved, but
there are still anomalies.
I set "mydestination = localhost, localhost.transbay.net" and think
"localhost.transbay.net" ought to be able to go away,
though for now it's being used as a key to deliver (bec
On Thu, Apr 18, 2019 at 03:49:16PM -0700, ecsd wrote:
> I set "mydestination = localhost, localhost.transbay.net" and think
> "localhost.transbay.net" ought to be able to go away,
> though for now it's being used as a key to deliver.
Much depends on your setting of "append_dot_mydomain", which u
This happens
Apr 18 19:34:15 transbay postfix/qmgr[88661]: CC13326F54D2:
from=,
size=33062, nrcpt=1 (queue active)
Apr 18 19:34:21 transbay postfix/local[89631]: CC13326F54D2:
to=<*ca...@localhost.transbay.net*>, orig_to=<*ca...@transpacific.net*>,
relay=local, delay=606, delays=601/0.01/0/5.
You've just installed postfix, badly, and emails to your users are not
being delivered, but rather deferred.
You are stuck in the meantime until you can figure out how to get the
email to deliver, and meanwhile you
have emails pending to be delivered to users. You'd rather not make them
wait.
As usual my futzing with the mail system provoked an issue whereby the
system discarded the last however many emails from the postfix list.
Where can I go search for them, or can I request a
resend-sent-since-datetime? Most of today was trashed.
On 19 Apr 2019, at 0:36, ecsd wrote:
As usual my futzing with the mail system provoked an issue whereby the
system discarded the last however many emails from the postfix list.
Where can I go search for them, or can I request a
resend-sent-since-datetime? Most of today was trashed.
There's a
On 18.04.19 12:15, ecsd wrote:
The logs show that postfix examines the recipients before the milter
is given the chance to see them.
I have a milter that detects certain RCPT patterns harassing a domain
name and will discard (not bounce) the mail,
does the milter see those invalid recipients a
Sorry for the repost, but [mail hidden] wiped out what I was trying to
show from the logs.
I have replaced all email addresses with "user at domain".
==
This happens
Apr 18 19:34:15 transbay postfix/qmgr[88661]: CC13326F54D2:
from=bounce.email.vimeo.com>, size=33062, nrcpt=1 (queue active)
Ap
26 matches
Mail list logo
