F fail. So maybe they wouldn't even get
a report for such emails (not sure, I have to read the
RFC). I strongly expect that it would constitute a
DMARC+DKIM failure, even if it's a DKIM success.
cheers,
raf
ils that are
arriving at the mail server. Of course, the senders
of those emails are also end users that matter.
It's OpenDKIM's user's users that matter more than
OpenDKIM's users. No offense meant to mail server
administrators. :-) You're all amazing people and the
world would fall apart without you!
Apologies for the length and opinions and repetition
above, but as the old saying goes:
"The world is complex, and the mail configuration reflects that"
And that was true long before SPF and DKIM and DMARC
came along. :-)
cheers,
raf
On Tue, Jul 13, 2021 at 10:35:15PM -0400, Bill Cole
wrote:
> On 2021-07-13 at 21:18:46 UTC-0400 (Wed, 14 Jul 2021 11:18:46 +1000)
> raf
> is rumored to have said:
>
> > I'm beginning to think that DKIM headers might be
> > getting added just to improve spam detec
On Wed, Jul 14, 2021 at 02:38:00PM +1000, raf wrote:
> On Tue, Jul 13, 2021 at 06:06:16PM -0400, post...@ptld.com wrote:
>
> Viktor wrote:
>
> > > That's because DMARC (which I don't use or recommed)
> >
> > Why don't you recommend DMARC? Wha
On Wed, Jul 14, 2021 at 09:51:25AM +0200, Bastian Blank
wrote:
> On Wed, Jul 14, 2021 at 05:43:57PM +1000, raf wrote:
> > Here's a (silly) thing that wrong with DMARC: :-)
> > I've sent two messages to this mailing list so far, and
> > I've received 52
On Wed, Jul 14, 2021 at 10:03:00AM +0200, Matus UHLAR - fantomas
wrote:
> > On Wed, Jul 14, 2021 at 05:43:57PM +1000, raf wrote:
> > > Here's a (silly) thing that wrong with DMARC: :-)
> > > I've sent two messages to this mailing list so far, and
> > &
On Wed, Jul 14, 2021 at 09:07:54AM -0400, Bill Cole
wrote:
> On 2021-07-14 at 03:43:57 UTC-0400 (Wed, 14 Jul 2021 17:43:57 +1000)
> raf
> is rumored to have said:
>
> > Here's a (silly) thing that wrong with DMARC: :-)
> > I've sent two messages to this
UTC-0400 (Thu, 15 Jul 2021 10:51:03 +1000)
> raf
> is rumored to have said:
>
> > On Wed, Jul 14, 2021 at 09:07:54AM -0400, Bill Cole
> > wrote:
> >
> > > On 2021-07-14 at 03:43:57 UTC-0400 (Wed, 14 Jul 2021 17:43:57 +1000)
> > > raf
> > >
s correct, that email resulted in a DMARC
failure because there was a DMARC+SPF failure and no
DKIM at all so that's a DMARC+DKIM failure.
This is even though a plain SPF check would have
passed, and a plain DKIM check would never have
taken place (and so wouldn't pass or fail).
cheers,
raf
On Thu, Jul 15, 2021 at 08:07:52PM -0400, Bill Cole
wrote:
> On 2021-07-15 at 19:44:41 UTC-0400 (Fri, 16 Jul 2021 09:44:41 +1000)
> raf
> is rumored to have said:
>
> > SPF by itself would have checked the envelope address
> > (owner-postfix-us...@p
On Wed, Jul 14, 2021 at 02:51:25PM +1000, raf wrote:
> On Tue, Jul 13, 2021 at 10:35:15PM -0400, Bill Cole
> wrote:
>
> > On 2021-07-13 at 21:18:46 UTC-0400 (Wed, 14 Jul 2021 11:18:46 +1000)
> > raf
> > is rumored to have said:
> >
> > > I'
On Fri, Jul 16, 2021 at 05:12:38PM +1000, raf wrote:
> On Wed, Jul 14, 2021 at 02:51:25PM +1000, raf wrote:
>
> > On Tue, Jul 13, 2021 at 10:35:15PM -0400, Bill Cole
> > wrote:
> >
> > > On 2021-07-13 at 21:18:46 UTC-0400 (Wed, 14 Jul 2021 11:18:46 +1000)
&g
On Fri, Jul 16, 2021 at 11:32:32AM +0200, Benny Pedersen wrote:
> On 2021-07-16 09:12, raf wrote:
>
> > According to this:
> >
> > https://postmarkapp.com/blog/proof-dkim-and-senderid-improve-delivery
>
> please stay away from senderid, its deprecated
Yes, I th
Hi,
The FORWARD_SECRECY_README suggests regenerating the
Postfix SMTP server EDH parameters periodically.
Would doing so necessitate a postfix reload?
cheers,
raf
On Thu, Jul 22, 2021 at 08:45:36AM -0400, Viktor Dukhovni
wrote:
> > On 22 Jul 2021, at 7:57 am, raf wrote:
> >
> > The FORWARD_SECRECY_README suggests regenerating the
> > Postfix SMTP server EDH parameters periodically.
> > Would doing so necessitate a pos
On Fri, Jul 23, 2021 at 12:35:50AM -0400, Viktor Dukhovni
wrote:
> On Fri, Jul 23, 2021 at 11:21:14AM +1000, raf wrote:
>
> > > > The FORWARD_SECRECY_README suggests regenerating the
> > > > Postfix SMTP server EDH parameters periodically.
> > > > W
t
which shows how postfix was compiled. It isn't needed.
I deleted mine without consequence.
cheers,
raf
7;t see what's causing your real problem
(non-delivery to root), but a theory is that you have:
local_recipient_maps = unix:passwd.byname $alias_maps
which is slightly different to the default:
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
The difference means that access to /etc/passwd might
not work for postfix services that are chrooted. Just a
thought. It might be irrelevant.
You could try leaving local_recipient_maps at its
default, and see what happens.
One thing that seems strange to me is that
permit_mynetworks and permit_sasl_authenticated don't
appear in your smtpd_recipient_restrictions. These were
in the overridden value. Maybe you need to add them
back into your smtpd_recipient_restrictions. But again,
this might not be relevant to your problem.
There seem to be a lot of things in the postconf -n
output that match the default values (e.g.
newaliases_path, setgid_group, ...). They can be
removed from main.cf.
But there's one setting that seems very odd:
sendmail_path = /usr/bin/postfix
Is there a good reason for that? It would normally be
sendmail_path = /usr/sbin/sendmail
You could try removing that and seeing if it helps.
As for the real problem "mail for server.mydomain.com
loops back to myself", maybe "server.mydomain.com"
should be in $mydestinations? If MX for
sender.mydomain.com is mail.my_domainFQDN.com but
mail.my_domainFQDN.com doesn't know to deliver mail for
sender.mydomain.com locally, then it might loop(?).
But don't trust me. I'm not an expert. This might be
a bad idea.
Good luck.
cheers,
raf
w
to be published, and disabling it then.
I'm sure that Rhenus will still use STARTTLS on port
25. They'll just require STARTTLS to be used and
they'll only support TLSv1.2+. The only alternative
would be to close port 25, use port 465 (TLS-only)
instead, and hope that all mail servers that want to
send them email try to use port 465. But that's not
going to happen.
cheers,
raf
l.postfix or
/etc/alternatives/sendmail, not /usr/sbin/postfix.
That's the postfix binary, not the sendmail-compatible
interface to postfix. They are not the same program.
But again, this is probably a side issue to your local mail
not being delivered due to "mail for server.mydomain.com
loops back to myself". That's probably more likely to be
related to your $mydestinations value not including all of
the right servers.
cheers,
raf
ument -- 'h'
sendmail: option requires an argument -- 'h'
sendmail: fatal: usage: sendmail [options]
And if postfix did invoke sendmail, it wouldn't get the
command line wrong.
Did you perhaps test it by invoking sendmail manually
on the command line? If so, the error message might
just be due to invoking it incorrectly. It probably has
nothing to do with the sendmail_path parameter setting
in main.cf.
cheers,
raf
On Wed, Jul 28, 2021 at 09:21:22PM -0400, Viktor Dukhovni
wrote:
> On Thu, Jul 29, 2021 at 10:26:09AM +1000, raf wrote:
>
> > The only alternative would be to close port 25, use port 465
> > (TLS-only) instead,
>
> This profoundly confuses the SMTP (relay) pro
sender hosts no ?
>
> (note : I haven't configured spf, dkim, dmarc, etc, yet on this new server,
> one thing at a time and ensure that's working fine before pilling other
> things on top ;))
That header might have been put there by the remote
receiving server. It's saying that the sending domain
does not specify which IP addresses are authorised to
send email for that domain. You could get rid of it by
specifying which IP adresses are authorised to do so,
and to include the IP address of your postfix server
host in the list. You don't have to do that, but you can.
But doing that isn't postfix-related.
You just need to add an SPF (TXT) record to the sending
domain's DNS setup. Google how to set up SPF. There's
lots of advice and tools to help construct it.
> Jeff
cheers,
raf
sbl.sorbs.net
permit
These RBL services are based on IP addresses, not
sender email addresses or domains. But there are ones
that work on sender domain names (RHSBL).
See http://www.postfix.org/SMTPD_ACCESS_README.html for
details. There are also lots of non-DNS based checks
you can apply to prevent spam. They seem to do just as
good a job for me (particularly postgrey).
cheers,
raf
On Wed, Jul 28, 2021 at 11:20:03PM -0400, Viktor Dukhovni
wrote:
> On Thu, Jul 29, 2021 at 12:18:25PM +1000, raf wrote:
>
> > And similarly, port 25 will never be TLS-only. STARTTLS
> > isn't going away.
>
> I am less certain that public Internet SMTP will no
On Thu, Jul 29, 2021 at 10:37:46AM +0200, Matus UHLAR - fantomas
wrote:
> On 29.07.21 10:26, raf wrote:
>
> > On my little personal mail server, 75% of incoming
> > connections to port 25 are plaintext. Only 25% use
> > STARTTLS (by definition). Disabling STARTTLS woul
rver."
That second sentence sounds to me like a definite
statement that an SMTP connection that doesn't initiate
STARTTLS will not be able to send email. At least, I
can't see how else to interpret those words.
cheers,
raf
; regards
> Hadmut
Would setting smtpd_client_auth_rate_limit in main.cf
to a low number help? It's not the analysis of logs that
you're asking for, but it sounds relevant.
http://postfix.org/postconf.5.html#smtpd_client_auth_rate_limit
cheers,
raf
65/TLS). The iphone can be coerced
into connecting to port 465 but it doesn't happen
without manual intervention.
cheers,
raf
commands (default: CONNECT GET POST regexp:{{/^[^A-Z]/
Bogus}})
Perhaps other HTTP reqeust methods could be added
(i.e. HEAD PUT DELETE OPTIONS TRACE PATCH) but it's
probably enough as it is.
cheers,
raf
>
> Wietse
That'll be a relief to non-SMTP clients that connect to port 25. :-)
cheers,
raf
ct that the existing default
has been arrived at after much observation and careful thought.
But the option to do this is there if that's what you want.
cheers,
raf :)
On Tue, Aug 10, 2021 at 07:54:35PM -0400, Viktor Dukhovni
wrote:
> On Wed, Aug 11, 2021 at 09:48:24AM +1000, raf wrote:
>
> > If you want postfix to reject a connection immediately
> > after the first SMTP protocol error it encounters,
> > without the need to construct
headers along the way, then it'll probably pass a DMARC
check for mail.ru. Otherwise, it won't.
Having said all that, what gmail does with it upon
arrival is entirely up to gmail. :-)
cheers,
raf
ad idea. A better solution would be for the
mailing list software to leave the To: header alone and
only use the list member's addresses in the envelope.
But presumably, that's not going to happen.
cheers,
raf
On Sat, Aug 14, 2021 at 01:22:43AM +0200, Benny Pedersen wrote:
> On 2021-08-14 01:10, raf wrote:
>
> > h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
>
> note 2 instances of From
>
> i bet both is not dkim signed, or both From is not in the reciev
ng
> stata
>
> reduce your signed headers list to begin with from, to, date, subject
>
> this will solve some of the problems you have
Not in this case. It's the To: header that is being
changed by the dovecot mailing list software.
So if the To: header is included in the signature,
then the signature will become invalid.
cheers,
raf
.
Or maybe they didn't support them earlier either,
and they haven't actually done anything.
cheers,
raf
igned header will not be the empty string. It will
be a header. So the signature wouldn't be valid.
cheers,
raf
ion
https://www.rfc-editor.org/rfc/rfc8314.html#section-3.3
And it's in the IANA registry of ports:
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=9
So "smtps" is dead. Long live "submissions".
But it isn't for server-to-server use.
cheers,
raf
On Sat, Aug 14, 2021 at 10:47:08AM -0400, Viktor Dukhovni
wrote:
> > On 14 Aug 2021, at 1:15 am, raf wrote:
> >
> > According to the hardenize.com security bingo site,
> > they get a green box for their mail server TLS, even
> > though they support TLSv1.0 (y
On Sun, Aug 15, 2021 at 07:06:06AM +0800, Lauren R wrote:
> On 2021/8/15 7:04 上午, raf wrote:
> > So "smtps" is dead. Long live "submissions".
> >
> > But it isn't for server-to-server use.
>
> so for server to server use, we should deploy star
On Sun, Aug 15, 2021 at 09:37:17AM +1000, raf wrote:
> I recommend using a CA-approved certificate like
> LetsEncrypt just because Postfix will use the same
> certificate for submissions on port 587, and mail
> clients (like Thunderbird) might complain if a
> self-signed certifi
On Sun, Aug 15, 2021 at 09:27:28PM +0200, Matus UHLAR - fantomas
wrote:
> > On Sat, Aug 14, 2021 at 02:43:29PM +0200, Matus UHLAR - fantomas
> > wrote:
> >
> > > - dedicated port for smtp/ssl was deprecated (in fact never standrdized)
>
> On 15.08.21 09:04,
ed Received Chain (ARC):
https://tools.ietf.org/html/rfc8617 (Experimental)
I think at this stage, it's safe to say that it's
getting out of hand. :-)
I suppose there's no problem in computer science that
can't be solved by adding another layer of cryptographic
indirection. :-)
cheers,
raf
On Mon, Aug 16, 2021 at 03:38:01PM +0200, Matus UHLAR - fantomas
wrote:
> On 16.08.21 21:11, Ken N wrote:
> > Thank you for providing the details.
> > That make things clear.
>
> > On 2021/8/16 6:26 下午, raf wrote:
> > > DKIM signatures should include the en
and
postfix uses the same certificate for all ports
(25/465/587). So I want using certbot for DANE to be
easy.
cheers,
raf
P.S. Apologies if this is too off-topic, but I thought
it might be useful to the debian+stable+bind+dnssec+dane
loving subset of the postfix audience.
On Tue, Aug 17, 2021 at 12:35:40PM -0400, Viktor Dukhovni
wrote:
> On Tue, Aug 17, 2021 at 06:12:04PM +1000, raf wrote:
>
> > If you use Debian stable, and ISC Bind, it has just
> > become really really easy to implement DNSSEC for your
> > domain(s).
>
&
fix/transport
transport:
/.*@(gmail|hotmail|charter)\.com/ relay:[mail.billoblog.com]
You won't need to run postmap for the transport file when
you change it (because it's a regexp database).
cheers,
raf
On Wed, Aug 18, 2021 at 08:53:40AM +0200, Marcel de Riedmatten
wrote:
> Le mercredi 18 août 2021 à 14:32 +1000, raf a écrit :
> >
> > It would be great if certbot supported multiple simultaneous
> > certificates
> > for a domain, so that the next certificate could be
On Wed, Aug 18, 2021 at 09:52:38PM +0200, Ralph Seichter
wrote:
> * raf:
>
> > If you don't mind having a key that lasts "forever", you only
> > need one(!) extra line in Bind's zone config, and one(!) manual
> > interaction with your domain r
On Wed, Aug 18, 2021 at 11:04:10AM +0200, Marcel de Riedmatten
wrote:
> Le mercredi 18 août 2021 à 17:45 +1000, raf a écrit :
> >
> > I'll need to find out how to replace one certificate
> > with the other as well.
>
> Keep in mind that both certificates wil
But it's good that they make it easy for their Cloud DNS
customers to sign their zones.
We're still a long way from the day when the Chrome browser
starts labelling unsigned domains as "Unsecure". :-)
cheers,
raf
On Thu, Aug 19, 2021 at 01:11:37AM -0400, Viktor Dukhovni
wrote:
> On Thu, Aug 19, 2021 at 02:44:44PM +1000, raf wrote:
>
> > I just saw Viktor's reply about mx[1-4].smtp.goog,
> > and it looks like those domains are no longer signed:
> >
> > > host -
. :-)
I've only used other people's milters (OpenDKIM and
OpenDMARC), and only to filter the mail content itself.
cheers,
raf
On Thu, Aug 19, 2021 at 09:27:10AM -0400, Wietse Venema
wrote:
> raf:
> > I take it that milters must work too, but they sound
> > like much more effort. You need to write a whole other
> > program (securely).
>
> No. You write little functions in a common language
7;ve come across.
I can find people asking how to set it up, but not
so much in the way of satisfactory answers.
Without something like OpenARC, OpenDMARC is going to
produce lots of false positives because it doesn't know
to defer to ARC checking in the presence of ARC headers.
cheers,
raf
nt_access
reject_unknown_client_hostname
...
/etc/postfix/client_access:
mail.radio-z.net OK
And run "postmap hash:/etc/postfix/client_access"
whenever you make changes to the client_access file.
The above assumes that you are using
reject_unknown_client_hostname in the
smtpd_client_restrictions setting.
If it's in some other smtpd_*_restrictions
setting, modify that setting instead.
cheers,
raf
On Wed, Aug 18, 2021 at 02:32:51PM +1000, raf wrote:
> I guess the most pragmatic thing to do would be to only use DANE/TLSA
> for port 25 with self-signed certificates with self-automated rollovers,
> and use certbot-created certificates (without corresponding TLSA records)
> fo
so, please send the output of:
postconf -nf
postconf -Mf
cheers,
raf
te that changes to main.cf take effect immediately
in a lot of cases (so run postconf -n right away), and changes
to master.cf only take effect after a reload (so run postconf -M
before reloading postfix).
cheers,
raf
ly
configurable text editor for composing the reply, you
can probably configure the editor to automatically
remove and/or replace the addresses before you start
typing the reply.
cheers,
raf
7;t already use mutt,
> > but I wouldn't recommend it.
> >
> > Looking for a solution in your mail client is much better.
> >
> > Also, if your mail client launches a highly
> > configurable text editor for composing the reply, you
> > can probably co
as
"fo=1:s:d" which means that they want to receive
reports for any DKIM failure. That would be every email
that comes out of there. Maybe they are conducting a
study on DMARC checkers.
cheers,
raf
On Sat, Sep 04, 2021 at 10:37:35AM +0200, Jean-François Bachelet
wrote:
> Re hello ^^)
>
> Le 04/09/2021 à 10:34, Jean-François Bachelet a écrit :
> > Hello raf ^^)
> >
> > sorry for late answer, I'm too busy :(
> >
> >
> > Le 29/07/2021 à
people
change this setting. But it probably never actually
results in passwords being sent unencrypted anyway, so
it probably doesn't really matter.
> [...]
> smtpd_sasl_auth_enable = yes
The above should probably be removed from main.cf and
added to the submission service in master.cf instead.
It won't solve your problem, but it's better. You don't
need or want authentication on port 25. The other
smtpd_sasl_* settings can stay in main.cf or be moved
to master.cf. Actually, smtpd_sasl_auth_enable is
already in master.cf, so you can just delete it from
main.cf to prevent unwanted authentication attempts on
port 25.
> --
> best regards,
> Thomas
I hope some of that helps.
cheers,
raf
On Thu, Sep 09, 2021 at 09:44:35AM +0200, TTM wrote:
> raf wrote:
> >> main.cf
> >> -
> >> [...]
> >> receive_override_options = no_address_mappings
> >
> >I could be
r remembered round trip
times, it might use that one. But that sounds more
complicated than it's worth. That sort of optimization
tends to be managed at the other end by Content
Delivery Networks (CDNs).
cheers,
raf
On Tue, Sep 14, 2021 at 01:20:03PM +1000, raf wrote:
> On Mon, Sep 13, 2021 at 11:07:27AM +0200, Max-Julian Pogner
> wrote:
>
> > Hi there,
> >
> > when a user clicks "send", the email client has to make some tcp-connection
> > to some ip address.
On Tue, Sep 14, 2021 at 08:24:00AM +0100, Nick Howitt
wrote:
> On 14/09/2021 04:29, raf wrote:
> >
> > On Tue, Sep 14, 2021 at 01:20:03PM +1000, raf wrote:
> >
>
> >
> > But chances are that mail clients just do what any
> > other TCP client woul
~start=30
Hmm, maybe not. You can see the topic titles, but it doesn't let
you see anyone else's content. Wierdly unhelpful.
cheers,
raf
al_map
/etc/postfix/canonical_map:
/^MAILER-DAEMON(@.+)?$/i mailer-daemon${1}
Note that the "i" is to make the regexp/pcre pattern case-sensitive
(because it's case-insensitive by default and the "i" toggles that).
Using hash: for canonical_maps is always case-insensitive,
so it might be better to use regexp/pcre because it enables
you to make the lookup case-sensitive. Maybe it wouldn't matter.
cheers,
raf
se is that changing them back
again doesn't always unbreak the other things,
especially if they were already broken but
nobody had noticed yet. :-(
cheers,
raf
?
> I changed it to this :
>
> virtual_mailbox_maps = socketmap:unix:/var/imap/socket/smmap:smmapd
>
> Which matches what's in cyrus.conf :
>
> smmap cmd="smmapd" listen="/var/imap/socket/smmap" prefork=0
>
> And Lo! It started working.
>
> I think that solved that problem. I think the Cyrus doco needs updating.
>
> Thank you
> Carl
Well done working it out.
cheers,
raf
the logs in the SQL database, you might want to rethink
that and investigate the ELK Stack instead
(Elasticsearch, Logstash, Kibana). It'll be overkill,
but well worth learning, as it will be useful for all
manner of log analysis needs.
> Thanks,
> Alex
cheers,
raf
On Wed, Sep 22, 2021 at 12:24:25PM +1000, raf wrote:
> On Tue, Sep 21, 2021 at 08:49:24PM -0400, Alex wrote:
>
> > Hi,
> >
> > I'm interested in having postfix log directly to a mariadb or mongodb
> > database so I can then query it for different info lik
you can configure it to
do what you need, whereas there are bound to be ELK
stack users that analyze Postfix logs, so any plugins
or configuration needed will have already been created.
That might be reason enough to use the ELK stack, even
if the scale doesn't warrant it.
Bear in mind, I don't really know what I'm talking about.
I never heard of LogAnalyzer before today, and I've never
used the ELK stack myself. I've only heard good things
about it.
> Thanks,
> Alex
cheers,
raf
7;ll probably want to set enable_long_queue_ids = yes.
It ensures that queue IDs are unique/non-repeating so that log analysis
doesn't get mislead.
http://www.postfix.org/postconf.5.html#enable_long_queue_ids
cheers,
raf
out the -d option for defaults, the output is perfect.
cheers,
raf
On Wed, Sep 22, 2021 at 12:56:30PM -0400, Viktor Dukhovni
wrote:
> On Wed, Sep 22, 2021 at 10:35:45PM +1000, raf wrote:
>
> > I just encountered a wierd thing (debian-11 stable, postfix-3.5.6-1+b1).
>
> Thanks for the bug report.
Thanks for the fix!
On Wed, Sep 22, 2021 at 07:11:19PM -0400, Wietse Venema
wrote:
> Viktor Dukhovni:
> > On Wed, Sep 22, 2021 at 10:35:45PM +1000, raf wrote:
> >
> > > I just encountered a wierd thing (debian-11 stable, postfix-3.5.6-1+b1).
> >
> > Thanks for the bug
On Wed, Sep 22, 2021 at 10:52:02PM -0400, Viktor Dukhovni
wrote:
> On Thu, Sep 23, 2021 at 09:28:59AM +1000, raf wrote:
>
> > > Thanks. This is the result of lazy coding in a nasty language.
> > > I should stop hidden static buffers, or switch to a language
> > &g
return to investment ratio.
It would be nice if Gtest could support testing C. :-)
cheers,
raf
to be changed in the code, perhaps it could be changed
to that instead.
cheers,
raf
On Fri, Sep 24, 2021 at 09:49:49AM -0400, Wietse Venema
wrote:
> raf:
> > Hi,
> >
> > I think there's a parameter name that is rightish/better
> > in the documentation but wrong/worse in the code.
>
> Added to the queue.
>
> Wietse
T
On Fri, Sep 24, 2021 at 08:06:06AM -0400, Wietse Venema
wrote:
> raf:
> > On Thu, Sep 23, 2021 at 06:46:33AM -0400, Wietse Venema
> > wrote:
> >
> > > C and C++ are similar enough that C can easily be wrapped in C++.
> > > I'd love to adopt Gtest
On Fri, Sep 24, 2021 at 11:54:29AM -0400, Viktor Dukhovni
wrote:
> On Sat, Sep 25, 2021 at 01:08:29AM +1000, raf wrote:
>
> > Also, the following look like they are defined in
> > mail_params.h but they aren't in postconf.proto
> > (20210815 snapshot). Thi
nking day.
>
> Thank you.
It looks like it was copied and pasted from a vim
statusline (i.e., line number, column number, and
proportion through the file/buffer expressed as a
percentage).
cheers,
raf
m over the hold queue directory.
That might work. But it might a bad idea. Not sure.
You could also stop chrooting the process that produced
the error message by changing its chroot value in
/etc/postfix/master.cf from "yes" to "no" (5th column).
But I personally think that's definitely a bad idea.
cheers,
raf
cert.pem
But you are missing the smtpd_tls_security_level
parameter in main.cf, so that certificate is unused.
When you want the postfix smtp client to use STARTTLS
when it's offered by remote smtp servers for outgoing
mail, you usually want this in main.cf:
smtp_tls_security_level = may
Since you are requiring submission clients to have
particular client certificates, perhaps it's possible
that your relay_transport host is requiring a
particular client certificate from your local postfix
smtp client. If so, your mistake is that, instead of
getting your local postfix smtp client to use that
client certificate when making connections to your
relay host, you have instead tried to use it as a server
certificate when submission clients connect to your local
postfix smtp server.
> Regards.
cheers,
raf
On Wed, Sep 29, 2021 at 11:18:31AM -0400, Viktor Dukhovni
wrote:
> On Thu, Sep 30, 2021 at 12:45:31AM +1000, raf wrote:
>
> > > postconf: warning: /etc/postfix/master.cf: undefined parameter:
> > > submission_sender_restrictions
> > > s
On Thu, Sep 30, 2021 at 12:07:08AM -0400, Viktor Dukhovni
wrote:
> On Thu, Sep 30, 2021 at 01:21:19PM +1000, raf wrote:
>
> > You said that the following extensions are needed:
> >
> > basicConstraints = CA:true
> > keyUsage = digitalSignature, keyCertSign,
On Thu, Sep 30, 2021 at 02:28:11AM -0400, Viktor Dukhovni
wrote:
> On Thu, Sep 30, 2021 at 03:50:41PM +1000, raf wrote:
>
> > > No, because you don't get to choose which CA signed your certificates.
>
> I meant to say "your *peer's* certificates".
>
s, and Postfix will escape the characters
represented by %s between those single quotes. So
Postfix does protect you from SQL injection.
It uses MySQL's mysql_real_escape_string function to perform
the escaping (https://mariadb.com/kb/en/mysql_real_escape_string/).
cheers,
raf
e ready, post the output of "postconf -nf" and "postconf -Mf".
cheers,
raf
guish between a well-behaved client and a
spambot, based on their command pipelining behavior.
If you require "reject_unauth_pipelining" to block
spambots, then turn off Postfix's CHUNKING
announcement"
Based on that, I disable CHUNKING, but I leave
PIPELINING enabled. There's nothing in the
documentation to suggest that disabling PIPELINING
is a good idea.
cheers,
raf
7;s method for achieving default
backwards compatibility by changing default behaviour
only explicitly via compatibility_level is superb.
As for discoverability, this issue probably doesn't
occur often, and when it does, there is a warning
message by default. Perhaps the warning could be
changed to mention/suggest the new
smtp_bind_address_failure_action parameter.
cheers,
raf
On Tue, Oct 26, 2021 at 05:08:00PM -0700, Dan Mahoney
wrote:
>
>
> > On Oct 26, 2021, at 4:54 PM, raf wrote:
> >
> > On Tue, Oct 26, 2021 at 09:42:33AM -0400, Wietse Venema
> > wrote:
> >
> >> Vincent Pelletier:
> >>> On Mon, 25
On Tue, Oct 26, 2021 at 08:50:38PM -0400, Viktor Dukhovni
wrote:
> On Tue, Oct 26, 2021 at 08:41:20PM -0400, Viktor Dukhovni wrote:
>
> > With `bash` inline /dev/fd/ files:
> >
> > $ diff -U0 <(postconf -x -o compatibility_level=2) <(postconf -x -o
> > compatibility_level=3.6)
>
> A hand
epository. If you show them what logs you
have, and what you are expecting to be grokked, they might be able to
see what the problem is.
cheers,
raf
1 - 100 of 286 matches
Mail list logo
