> On Apr 18, 2021, at 10:30 PM, Viktor Dukhovni
> wrote:
>
> On Sun, Apr 18, 2021 at 08:49:34PM -0400, Demi Marie Obenour wrote:
>
Each system is issued a certificate for its own domain. Perhaps a
better example would be email Subject Alternative Names.
>>>
>>> That's not an
On Sun, Apr 18, 2021 at 08:49:34PM -0400, Demi Marie Obenour wrote:
> >> Each system is issued a certificate for its own domain. Perhaps a
> >> better example would be email Subject Alternative Names.
> >
> > That's not an example (use-case), it is a certificate field. What
> > is the
On 4/18/21 8:04 PM, Viktor Dukhovni wrote:
> On Sun, Apr 18, 2021 at 07:59:07PM -0400, Demi Marie Obenour wrote:
>
Would it be possible to support trusting based on subject alt name?
I would like a machine with a certificate for a.example.com to send
mail from a.example.com
I'm looking at config documentation for solr on dovecot:
https://doc.dovecot.org/configuration_manual/fts/solr/
In the suggested solrconfig.xml file
(https://raw.githubusercontent.com/dovecot/core/master/doc/solr-config-7.7.0.xml),
it has the following line:
7.7.0
I'm running solr version
On Sun, Apr 18, 2021 at 07:59:07PM -0400, Demi Marie Obenour wrote:
> >> Would it be possible to support trusting based on subject alt name?
> >> I would like a machine with a certificate for a.example.com to send
> >> mail from a.example.com domains.
This rather mixes end-to-end properties (the
On 4/18/21 2:39 PM, Wietse Venema wrote:
> Demi Marie Obenour:
It seems that There are knobs that let you list *individual certs* for
allowing trusted relaying, but not *individual ca's*.
Is there any way around this?
>>>
>>> Yes: handle that traffic with a dedicated smtpd
Wietse Venema:
> As /etc/sevices [has become incompatibly different between platforms
> and versions], the solution is to make Postfix less dependent on
> that file. Well-known services such as submission, smtps, lmtp,
> and smtp, aren't going to move to a different TCP port. Therefore,
> I'm
Sent from my iPad
> On Apr 17, 2021, at 14:16, Wietse Venema wrote:
> Dan Mahoney (Gushi):
>> All,
>>
>> The dayjob has a number of machines out in the wild that need to be able
>> to send mail (mostly from cron jobs) home to the mothership. Not all have
>> controllable reverse DNS.
Demi Marie Obenour:
> >> It seems that There are knobs that let you list *individual certs* for
> >> allowing trusted relaying, but not *individual ca's*.
> >>
> >> Is there any way around this?
> >
> > Yes: handle that traffic with a dedicated smtpd instance that only
> > trusts your internal
On 4/17/21 5:15 PM, Wietse Venema wrote:
> Dan Mahoney (Gushi):
>> All,
>>
>> The dayjob has a number of machines out in the wild that need to be able
>> to send mail (mostly from cron jobs) home to the mothership. Not all have
>> controllable reverse DNS. It's an issue with donated colo and
On 18.04.21 07:55, li...@lazygranch.com wrote:
I need to learn postscreen eventually for other spammers.
mostly bots, but thanks to dnsbl scoring, spammers too.
The thing with fail2ban or the similar sshguard is I have a huge block
list for the webserver. It has been my experience that these
On Sun, 18 Apr 2021 21:29:26 +1200
Nick Tait wrote:
> On 18/04/21 7:32 pm, li...@lazygranch.com wrote:
> > And so it goes. I suppose if this really bugs me I can block the
> > server in firewalld. I've yet to see it actually deliver mail. Or
> > complain to the data center.
> >
Francesc Pe?alvez:
> thanks was that, I had smtp_tls_loglevel but not smtpd_tls_loglevel.
> Another thing, as is that from the host that sent the mail the
> connection appears as:
>
> Trusted TLS connection established
The client trusts the server certificate.
> ?but in the log of the host
thanks was that, I had smtp_tls_loglevel but not smtpd_tls_loglevel.
Another thing, as is that from the host that sent the mail the
connection appears as:
Trusted TLS connection established
but in the log of the host that receives it, it appears as:
Anonymous TLS connection established from
Here's how I test :
$ openssl s_client -connect my.mail.server:submission -starttls smtp
the logs show
Apr 18 14:18:04 messagerie postfix/smtpd[26383]: connect from
unknown[192.168.100.241]
Apr 18 14:18:04 messagerie postfix/smtpd[26383]: disconnect from
unknown[192.168.100.241]
Apr 18
Le 4/18/21 à 12:21 PM, Francesc Peñalvez a écrit :
I can only see TO connections but not FROM connections and I would
like to see both
Can you show us how your logs look like when you make
a TLS connection to your server ?
Yassine
I can only see TO connections but not FROM connections and I would like
to see both
El 18/04/2021 a las 12:59, Jaroslaw Rafa escribió:
Dnia 18.04.2021 o godz. 12:44:41 Francesc Peñalvez pisze:
I have postfix configured to log outgoing tls connections:
Untrusted TLS connection established to
Dnia 18.04.2021 o godz. 12:44:41 Francesc Peñalvez pisze:
> I have postfix configured to log outgoing tls connections:
>
> Untrusted TLS connection established to smtp-mx.x
>
> but is it possible to log in the same way the incoming connections?
It logs for me with default settings in
I have postfix configured to log outgoing tls connections:
Untrusted TLS connection established to smtp-mx.x
but is it possible to log in the same way the incoming connections?
smime.p7s
Description: Firma criptográfica S/MIME
On 18/04/21 7:32 pm, li...@lazygranch.com wrote:
And so it goes. I suppose if this really bugs me I can block the server
in firewalld. I've yet to see it actually deliver mail. Or complain to
the data center.
https://serveroffer.lt
Firewalling is definitely the best solution to the problem
On Sat, 17 Apr 2021 18:25:47 -0400 (EDT)
Wietse Venema wrote:
> li...@lazygranch.com:
> > > You should enable SASL auth in master.cf NOT main.cf, and ONLY for
> > > a service that needs SASL auth.
> > >
> > > Otherwise you're turning it on for the server-to-server port (25)
> > > where it is
21 matches
Mail list logo
