On 4/27/22 14:01, Wietse Venema wrote:
> Michael Stroeder:
>>> Either way a compromised CA or a compromise KDC is bad news...
>>
>> Yes!
>>
>> And one of my biggest concerns are bad operational practices. That's why
>> admins should not have to manually deal with crypto key files like
>> service
On 4/27/22 21:30, Wietse Venema wrote:
Michael Stroeder:
So even if you cannot afford a HSM you can e.g. use ssh-agent via Unix
domain socket for your SSH-CA to avoid having to grant direct read
access to the SSH-CA's private key to your SSH-CA service. Simple
solutions, which you can isolate a
Michael Stroeder:
> So even if you cannot afford a HSM you can e.g. use ssh-agent via Unix
> domain socket for your SSH-CA to avoid having to grant direct read
> access to the SSH-CA's private key to your SSH-CA service. Simple
> solutions, which you can isolate a bit more with stuff already
Wietse Venema wrote:
> Wietse Venema:
>> This is a site-specific problem. I ran "openssl s_client" and
>> "posttls-finger -w" against one of the affected servers, and reliably
>> crashed their postscreen daemon. I've been doing similar tests
>> against my own servers without any problems.
>
>
On 4/27/22 20:01, Wietse Venema wrote:
Michael Stroeder:
Either way a compromised CA or a compromise KDC is bad news...
Yes!
And one of my biggest concerns are bad operational practices. That's why
admins should not have to manually deal with crypto key files like
service keytabs or TLS
Michael Stroeder:
> > Either way a compromised CA or a compromise KDC is bad news...
>
> Yes!
>
> And one of my biggest concerns are bad operational practices. That's why
> admins should not have to manually deal with crypto key files like
> service keytabs or TLS server keys.
To implement
On 4/27/22 19:03, Viktor Dukhovni wrote:
On 27 Apr 2022, at 12:45 pm, Michael Ströder wrote:
But my concern is rather that I would not connect my KDC to the
Internet (for now leaving aside approaches like proxy KCM). >>
In general I'm leaning more towards using asymmetric keys for
authc. On my
> On 27 Apr 2022, at 12:45 pm, Michael Ströder wrote:
>
> But my concern is rather that I would not connect my KDC to the Internet (for
> now leaving aside approaches like proxy KCM).
>
> In general I'm leaning more towards using asymmetric keys for authc. On my
> personal to-do list is to
On 4/27/22 18:38, Demi Marie Obenour wrote:
On 4/27/22 07:58, Michael Ströder wrote:
Mozilla hunked out all features for PKI client cert enrollment from
Firefox and Thunderbird. So today it's easier to issue client certs to
Outlook users than to Thunderbird users. :-(
Please report a bug on
“Well, if you believe that it's ok for you to use it.”
Not sure if you mean I’m being presumptuous (not intended) or actually
that I would see value in using it - I think you meant the latter but
again, not sure…(lol)
Anyway, I would see value in at least checking it out - seems
On 4/27/22 18:50, Antonio Leding wrote:
On 27 Apr 2022, at 9:45, Michael Ströder wrote:
> “On my personal to-do list is to implement a simple X.509-CA for issuing
> short-term client certs, with a CLI tool to directly manipulate
> Thunderbird and Firefox key/cert DB.”
As in you are planning
On 4/27/22 18:39, Demi Marie Obenour wrote:
On 4/27/22 12:27, Michael Ströder wrote:
On 4/27/22 14:37, Jahnke-Zumbusch, Dirk wrote:
I’m very interested in what options / solutions (if any) exist that allow
you to use a passwordless approach to authenticating your users against
“On my personal to-do list is to implement a simple X.509-CA for
issuing short-term client certs, with a CLI tool to directly manipulate
Thunderbird and Firefox key/cert DB.”
As in you are planning to build such a suite and put up on GH for all of
us to use as well???
If so, would love to
On 4/27/22 18:36, Viktor Dukhovni wrote:
On 27 Apr 2022, at 12:27 pm, Michael Ströder wrote:
one way to authenticate may be using Kerberos.
Not recommended for roaming users accessing submission service via public
Internet.
Suitability depends on the user base, ... my personal mail
On 4/27/22 12:27, Michael Ströder wrote:
> On 4/27/22 14:37, Jahnke-Zumbusch, Dirk wrote:
> I’m very interested in what options / solutions (if any) exist that allow
> you to use a passwordless approach to authenticating your users against
> imaps/pop3/smtps/submission services (tls
On 4/27/22 08:37, Jahnke-Zumbusch, Dirk wrote:
> Hi everybody,
>
I’m very interested in what options / solutions (if any) exist that allow
you to use a passwordless approach to authenticating your users against
imaps/pop3/smtps/submission services (tls encrypted of course)
>
> one
On 4/27/22 07:58, Michael Ströder wrote:
> On 4/27/22 12:27, Jaroslaw Rafa wrote:
>> Dnia 27.04.2022 o godz. 17:47:06 AndrewHardy pisze:
>>>
>>> I’m very interested in what options / solutions (if any) exist that allow
>>> you to use a passwordless approach to authenticating your users against
>>>
On 4/27/22 17:28, lists wrote:
The TOTP built into Linux has a 30 second time limit but most
implementations approve the stale code making it effectively 60
seconds.
>
Hackers have either implemented [..] a man in the middle attack
intercepted the token.
An implementation taking the
> On 27 Apr 2022, at 12:27 pm, Michael Ströder wrote:
>
>> one way to authenticate may be using Kerberos.
>
> Not recommended for roaming users accessing submission service via public
> Internet.
Suitability depends on the user base, ... my personal mail server
indeed supports SASL GSSAPI
On 4/27/22 14:37, Jahnke-Zumbusch, Dirk wrote:
I’m very interested in what options / solutions (if any) exist that allow
you to use a passwordless approach to authenticating your users against
imaps/pop3/smtps/submission services (tls encrypted of course)
one way to authenticate may be using
On Wed, Apr 27, 2022 at 08:42:25AM +0200, Varadi Gabor wrote:
> > /\.that-domain\.com$/ OK
>
> /.*\.that-domain\.com$/ OK
>
> Tested in https://www.debuggex.com/?flavor=pcre
No. The original form is better. The leading ".*" is unnecessary and
may be less efficient.
The OP
On Wed, Apr 27, 2022 at 06:12:53PM +0800, al...@coakmail.com wrote:
> I guess this kind of file doesn't need to run postmap against it?
>
> virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
> virtual_alias_domains = /etc/postfix/virtual_alias_domains
These are "match lists", the
al...@coakmail.com:
> Hello
>
> I guess this kind of file doesn't need to run postmap against it?
All tables that are created with the postmap command, as described
in https://www.postfix.org/DATABASE_README.html#types
Wietse
The TOTP built into Linux has a 30 second time limit but most implementations
approve the stale code making it effectively 60 seconds.
Hackers have either implemented or there was a proof of concept (I forget
which) where a man in the middle attack intercepted the token. That is more
likely
Wietse Venema:
> This is a site-specific problem. I ran "openssl s_client" and
> "posttls-finger -w" against one of the affected servers, and reliably
> crashed their postscreen daemon. I've been doing similar tests
> against my own servers without any problems.
That was with FreeBSD 13.0, as
On 2022-04-27 at 01:47:06 UTC-0400 (Wed, 27 Apr 2022 17:47:06 +1200)
AndrewHardy
is rumored to have said:
Hi,
Following this thread has been quite intriguing. Interesting
conversation indeed.
On a similar topic but probably more focused on addressing root cause
(which in mind is just
wilson writes:
> today everyone claim they are encrypted email provider.
> what's the definition of an encrypted email? messages and headers and
> logs were encrypted in the rest?
I think RFC 8461 is worth considering, thanks!
Sincerely, Linux fan Byung-Hee
--
^고맙습니다 _布德天下_ 감사합니다_^))//
Hi everybody,
>>> I’m very interested in what options / solutions (if any) exist that allow
>>> you to use a passwordless approach to authenticating your users against
>>> imaps/pop3/smtps/submission services (tls encrypted of course)
one way to authenticate may be using Kerberos. Get your
On 4/27/22 12:27, Jaroslaw Rafa wrote:
Dnia 27.04.2022 o godz. 17:47:06 AndrewHardy pisze:
I’m very interested in what options / solutions (if any) exist that allow
you to use a passwordless approach to authenticating your users against
imaps/pop3/smtps/submission services (tls encrypted of
Dnia 26.04.2022 o godz. 18:59:35 lists pisze:
> I see the snowshoe hackers on my web server and I
> assume they are on my email but I don't read the postfix logs as often. I
> haven't seen a hacker hammer my server in a long time. It is all snowshoe
> these days.
I also have a personal server and
Hello Alice,
check out:
http://www.postfix.org/postconf.5.html
For every parameter you'll find the expected values, e.g. for virtual_alias_maps , which
expects a "lookup table".
If you use hash:*, you must postmap this file.
al...@coakmail.com wrote:
Hello
I guess this kind of file
Dnia 27.04.2022 o godz. 17:47:06 AndrewHardy pisze:
>
> I’m very interested in what options / solutions (if any) exist that allow
> you to use a passwordless approach to authenticating your users against
> imaps/pop3/smtps/submission services (tls encrypted of course)
To my knowledge,
Hello
I guess this kind of file doesn't need to run postmap against it?
virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
virtual_alias_domains = /etc/postfix/virtual_alias_domains
But this file need postmap after the modification?
virtual_alias_maps =
Dnia 27.04.2022 o godz. 15:46:33 wilson pisze:
> today everyone claim they are encrypted email provider.
> what's the definition of an encrypted email? messages and headers
> and logs were encrypted in the rest?
"Encrypted email" is a very vague term and one can understand it very
differently.
One more important thing is to educate the users to not click on any
unknown links because many a times spammers get hold of the account by the
way of phishing emails.
Fail2ban works in case there are brute force attempts. but if the password
is valid then the server will authenticate.
On
Hi,
>> /\.that-domain\.com$/ OK
>/.*\.that-domain\.com$/ OK
>Tested in https://www.debuggex.com/?flavor=pcre
Thanks!
Greets,
Ludi
today everyone claim they are encrypted email provider.
what's the definition of an encrypted email? messages and headers and
logs were encrypted in the rest?
Thanks
On 2022-04-27 lists wrote:
> Steve Gibson spent four years developing a passwordless Auth system.
> Open sourced it. Provided APIs. Nobody bought into it.
Steve Gibson? The same Steve Gibson who claimed that raw sockets in
Windows XP are evil because ... reasons? The same Steve Gibson who
Steve Gibson spent four years developing a passwordless Auth system. Open sourced it. Provided APIs. Nobody bought into it. https://www.grc.com/sqrl/sqrl.htmPart of what you asked sounds like the equivalent of a web firewall (WAF). I'm not a fan since the one I was using often broke the website
2022. 04. 27. 8:16 keltezéssel, Ludi Cree írta:
Hi all,
I would like to exclude non-existing subdomains from this rule:
"reject_unknown_sender_domain"
that I have on the end of my sender-restrictions here:
smtpd_sender_restrictions = check_sender_access
Hi all,
I would like to exclude non-existing subdomains from this rule:
"reject_unknown_sender_domain"
that I have on the end of my sender-restrictions here:
smtpd_sender_restrictions = check_sender_access
hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated,
41 matches
Mail list logo
