On 03/03/2023 19:19, David Conrad via mailop wrote:
This kind of comment isn’t particularly useful as it appears to be a
statement of an opinion with no explanation/justification.
DNSSEC is a different PKI. Like everything, it has pros and cons.
Whether it is better or worse depends on what yo
On 3/2/23 12:27 PM, Tobias Fiebig via mailop wrote:
The tool looks for a perfect world, which there isn't. ...
Still, if i'd not deduct points for those things, everyone would get
a 10. ;-)
I have no idea if your infrastructure / UI could support this or not,
but what if you had an option to
On 2/28/23 2:51 PM, John Levine via mailop wrote:
It's not common and I would be astonished if anyone checked as part
of delivery.
I wouldn't mind if the test called it out mostly in the sense that:
- I would want case consistency
- I'd be worried about tickling a bug in someone else's softwa
Heho,
> Heh, it turns out that actually works, so not a big deal :-)
Not tooo sure; There were a lot of timeouting tests which looked like
'did not reload page'; Wouldn't be surprised if _some_ browsers are
fine with it, while others aren't. Anyway, for good measure, it's fixed
now. ;-)
And thank
On 2023-03-04 at 01:37 +0100, Tobias Fiebig via mailop wrote:
Heho,
>
> On Fri, 2023-03-03 at 17:02 +0100, Ángel via mailop wrote:
> > Note you could use a > for
> > a refresh-every-10-seconds functionality. (meta refresh could be
> > blocked as well, though)
> Briefly considered that; However, c
Heho,
On Fri, 2023-03-03 at 17:02 +0100, Ángel via mailop wrote:
> Note you could use a a refresh-every-10-seconds functionality. (meta refresh could be
> blocked as well, though)
Briefly considered that; However, contrary to JS (which is often
ignored by screenreaders) the HTML manual put a warn
This kind of comment isn’t particularly useful as it appears to be a statement
of an opinion with no explanation/justification.
DNSSEC is a different PKI. Like everything, it has pros and cons. Whether it is
better or worse depends on what you’re looking at.
If you believe MTA-STS is superior,
On 2023-02-27 at 12:59 +0100, Tobias Fiebig via mailop wrote:
> Please note that setting up the tests (as we have to configure vhosts
> for some MTA-STS cases etc.) takes some time on our site. The test-
> site should periodically reload and provide the status. As we use JS
> for that part, please
On 2023-03-03 at 02:58:18 UTC-0500 (Fri, 3 Mar 2023 08:58:18 +0100)
Alessandro Vesely via mailop
is rumored to have said:
On Thu 02/Mar/2023 20:52:40 +0100 Bill Cole via mailop wrote:
On 2023-03-02 at 12:53:34 UTC-0500 (Thu, 2 Mar 2023 17:53:34 +
(UTC))
L. Mark Stone via mailop
is rumore
Heho,
no, i at least make the assumption that the people who get themselves
to implement MTA-STS (in either direction) will also have PKIX valid
certs.
And that group of orgs is relatively small.
In contrast, you can, e.g., just enable dane for you N-thousand
customers by adding records to _you
You make the strong assumption that DNSSEC is a better PKI than WebPKI.
It is not, it's significantly worse. MTA-STS *would* be inferior if
DNSSEC was good, it is not good.
On 02/03/2023 22:23, Tom Ivar Helbekkmo via mailop wrote:
Tobias Fiebig writes:
I share your sentiment. I am not a
Chris Adams via mailop writes:
> Since POSIX has nothing to do with network communication protocols for
> email, that's a funny hill to die on. The RFC defines the response
> format, which doesn't have to be a text file on a POSIX system at all
> (could be generated on the fly, could be on a non
On Thu 02/Mar/2023 20:52:40 +0100 Bill Cole via mailop wrote:
On 2023-03-02 at 12:53:34 UTC-0500 (Thu, 2 Mar 2023 17:53:34 + (UTC))
L. Mark Stone via mailop
is rumored to have said:
We got a ding on our DNSSEC score, because the PTR record isn't signed. Is
this really as big an issue as th
Once upon a time, Tom Ivar Helbekkmo said:
> Tobias Fiebig via mailop writes:
> > If I read RFC8461 correctly, this is not required for MTA-STS policies:
>
> Until they formally override POSIX, they have to abide by it.
Since POSIX has nothing to do with network communication protocols for
emai
Tobias Fiebig via mailop writes:
> If I read RFC8461 correctly, this is not required for MTA-STS policies:
Until they formally override POSIX, they have to abide by it.
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea
Tobias Fiebig via mailop writes:
> If I read RFC8461 correctly, this is not required for MTA-STS policies:
...begging the question whether MTA-STS is ever even interesting.
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important i
Tobias Fiebig writes:
> I share your sentiment. I am not a fan of MTA-STS, and honestly not
> really sure which problem it solves.
I'm reasonably sure. The problem is: "people are starting to want DANE,
which means we need to implement DNSSEC, which will cost us money, so we
need to design an i
On 2023-03-02 at 15:11:25 UTC-0500 (Thu, 02 Mar 2023 21:11:25 +0100)
Tobias Fiebig via mailop
is rumored to have said:
> I share your sentiment. I am not a fan of MTA-STS, and honestly not
> really sure which problem it solves.
It solves Google's problem of not wanting to deploy DNSSEC.
--
Bil
Heho,
> If I recall correctly, POSIX says that a line of text is not a line
> of text unless it ends in a proper line ending marker. I'm unsure of
> the details, here, but I am sure that when, a few years ago, I dug
> deeply into this, I concluded that the last line of a UNIX text file
> absolute
Tobias Fiebig via mailop writes:
> Besides: The CRLF thing is actually a bit funny; The RFC iirc just says
> 'delimited by', so i am not too sure whether it really must be at the
> end of the file; And then there is an errata clarifying that you can
> also delimit with LF instead of CRLF as menti
Heho,
> ...and now it gives me 9 out of 10, acknowledging that my MTA
> verifies DNSSEC and honors TLSA records.
My own domain (and the sending for email-security-scans.org) scores
9/10 as well; Mostly because OpenSMTPd lacks DANE and MTA-STS
validation... and TLS-RPT sending... that is a whole no
Tom Ivar Helbekkmo via mailop writes:
> I'll give it another go tonight, then! :)
...and now it gives me 9 out of 10, acknowledging that my MTA verifies
DNSSEC and honors TLSA records.
Of course, I'll never get a 10 out of 10. I'll implement TLS reports,
by and by, but MTA-STS will be support
On 2023-03-02 at 12:53:34 UTC-0500 (Thu, 2 Mar 2023 17:53:34 +
(UTC))
L. Mark Stone via mailop
is rumored to have said:
We got a ding on our DNSSEC score, because the PTR record isn't
signed. Is this really as big an issue as the explanatory test makes
out?
No. It isn't ANYTHING.
--
Bi
Hello Mark,
> We got a ding on our DNSSEC score, because the PTR record isn't
> signed. Is this really as big an issue as the explanatory test makes
> out?
The tool looks for a perfect world, which there isn't. Un-signed rDNS
is not really a bad thing (of course, a hypothetical attacker could
op"
Sent: Thursday, March 2, 2023 12:38:52 PM
Subject: Re: [mailop] Mail Sending Self-Test Platform
On 1 Mar 2023, at 16:21, John R Levine via mailop wrote:
BQ_BEGIN
Still, i am a bit wondering; Looking at the data flushed in so far (and
already multiple bugs filed agains
> On 1 Mar 2023, at 16:21, John R Levine via mailop wrote:
>
>> Still, i am a bit wondering; Looking at the data flushed in so far (and
>> already multiple bugs filed against implementations)... there are a lot
>> of funny milters and often unmaintained software integrated in funny
>> docker st
Tobias Fiebig writes:
> the 'issue' was indeed that you moved the addresses to Cc: instead of
> To:; Us not checking there is actually somewhat of an oversight.
Aha! That's my MUA doing that, of course. I handle email with Gnus.
> Fixed and pushed.
I'll give it another go tonight, then! :)
Heho,
the 'issue' was indeed that you moved the addresses to Cc: instead of
To:; Us not checking there is actually somewhat of an oversight.
Fixed and pushed.
With best regards,
Tobias
On Thu, 2023-03-02 at 09:13 +0100, Tom Ivar Helbekkmo wrote:
> Tobias Fiebig via mailop writes:
>
> > If you
Tobias Fiebig via mailop writes:
> If you try this again tomorrow you have to start a new test, as tests
> that do not receive a reply within an hour get removed (minimizing data
> storage etc.)
I just did - same results, and test ID is gq7oj8xk44aw452j4e4fzf7vhpu4v3.
-tih
--
Most people who g
Heho,
> Will do - have been waiting for the web site to send me another mail
> for a while, now, but it seems I'll have to leave it until morning.
> I'm guessing it's rather busy, with lots of people wanting to try it?
Gnah... seems like i got ratelimited at LE's staging environment for
(somewhat
Tobias Fiebig via mailop writes:
> If you'd like to look into this a bit more, could you maybe run another
> test, but check the box for 'store my emails'?
Will do - have been waiting for the web site to send me another mail for
a while, now, but it seems I'll have to leave it until morning. I'
Heho,
> My system has five mail items still queued, that won't be delivered.
> Two because of broken DNSSEC, three because of invalid TLSA records.
> (It's report ppk95bat9arnakovq5nmljen4n342u, by the way.)
>
> The consequences of this in the report could be somewhat confusing.
> It says "Not
It appears that John R Levine via mailop said:
>It's not surprising that there are a lot of broken DMARC and SPF records.
>The question is whether anyone cares. My impression is that in many cases
>there was a checklist item "DMARC" so someone did the absolute mimimum. A
>p=none policy, a slo
Tobias Fiebig via mailop writes:
> https://email-security-scans.org/
Nice! A couple of comments, though:
My system has five mail items still queued, that won't be delivered.
Two because of broken DNSSEC, three because of invalid TLSA records.
(It's report ppk95bat9arnakovq5nmljen4n342u, by the
Still, i am a bit wondering; Looking at the data flushed in so far (and
already multiple bugs filed against implementations)... there are a lot
of funny milters and often unmaintained software integrated in funny
docker stacks (probably preaching to the choir there, but i have a lot
of grievances
Heho,
On Tue, 2023-02-28 at 22:21 -0500, John Levine wrote:
> We briefly considered that and decided against it because the vast
> majority of actual DMARC records will continue to work unchanged, and
> long experience says that if you try to change the version number,
> you end up living with the
It appears that Tobias Fiebig via mailop said:
>John: Btw, what I am wondering; Given the last par of 6.3 in 7489,
>shouldn't dmarcbis switch to DMARC2, given that there are changes to
>existing tags ..
We briefly considered that and decided against it because the vast
majority of actual DMARC re
Heho,
> It's in RFC 9091 and in the DMARC update currently in draft form at
> the IETF. The intention was always that you could put private
> clauses in DMARC records which get ignored by clients that don't
> understand them, but the ABNF was overly clever. That's fixed in the
> new draft too.
Heho,
On Tue, 2023-02-28 at 17:53 -0500, John R Levine wrote:
> > dmarcv1 is a typo in the description (i correctly check for DMARC1,
> > otherwise this would have shown up earlier);
> ??
>
er... DKIMv1... -.-' The check checks for v=DMARC1, not DKIMv1 as the
description implies; Currently fixing
dmarcv1 is a typo in the description (i correctly check for DMARC1,
otherwise this would have shown up earlier);
??
The actual complaint is psd=n; Lemme see if i can make the report more
clear re: where it complained.
Do you maybe have some context on psd=n? I can't find it in 7489.
It's in R
Heho,
dmarcv1 is a typo in the description (i correctly check for DMARC1,
otherwise this would have shown up earlier);
The actual complaint is psd=n; Lemme see if i can make the report more
clear re: where it complained.
Do you maybe have some context on psd=n? I can't find it in 7489.
With bes
It appears that Tobias Fiebig via mailop said:
>Heho,
>
>after our paper on mail sending configurations some time ago [1], we
>now glued that together into a self-service site:
>
>https://email-security-scans.org/
>
>I'd be happy to hear your feedback, especially if things do not work as
>expecte
It appears that Tobias Geerinckx-Rice via mailop said:
>Is DNSSEC-signing PTR records common? Will it affect delivery in
>practice?
It's not common and I would be astonished if anyone checked as part of delivery.
I have an IPv6 tunnel from Hurricane Electric, who do not do DNSSEC on
their rDNS
Heho,
> For DMARC, there is a parsing bug. My DMARC record consists of three
> concatenated strings, which should be joined as usual. The view
> shown in the report strips the leading and trailing double quotes,
> but not the intermediate ones:
>
> v=DMARC1; p=none; " "rua=mailto:dmarca...@tana
Heho,
> Thanks for this. I tried it a few days ago (I think because you
> posted it to opensmtpd-misc? :-)
Yeah, also shared it there, hoping for more motivation to implement
DANE/MTA-STS in OpenSMTPd. Next escalation step is releasing code i
wrote for other projects and threatening to send pat
Heho,
> Looks like an useful utility for testing these things out live.
Thanks!
> One thing though, the EHLO and rDNS comparison is case-sensitive,
> there should really be no need?
No, there indeed isn't; Thanks, good catch! Already patched and will
deploy in a bit (some more bugs to address fr
Hi Tobias,
Thanks for this. I tried it a few days ago (I think because you
posted it to opensmtpd-misc? :-) and without doing anything my
‘score’ went from 7 to 8 since I last checked! At this rate I
expect a 10 by Friday.
Is DNSSEC-signing PTR records common? Will it affect delivery in
Hi,
Looks like an useful utility for testing these things out live.
One thing though, the EHLO and rDNS comparison is case-sensitive, there
should really be no need?
On 27/02/2023 13:59, Tobias Fiebig via mailop wrote:
Heho,
after our paper on mail sending configurations some time ago [1],
On Mon 27/Feb/2023 12:59:04 +0100 Tobias Fiebig via mailop wrote:
I'd be happy to hear your feedback, especially if things do not work as
expected (then, your test ID and ideally stored emails would be really
helpful, so i can double check what went wrong).
My DMARC and DKIM results were ma
Heho,
> The inevitable questions about how bad the issues are. I.e. what
> could happen?:
> - My ip4 and ip6 reverse DNS records are not DNSSEC-signed. I could
> ask my hosting provider if they can sign them. Could there be a
> reason not to?
> - I'm not DKIM-signing the MIME-Version header (marke
On 2/27/23 12:59, Tobias Fiebig via mailop wrote:
after our paper on mail sending configurations some time ago [1], we
now glued that together into a self-service site:
https://email-security-scans.org/
I'd be happy to hear your feedback, especially if things do not work as
expected
Nice!
Res
Heho,
after our paper on mail sending configurations some time ago [1], we
now glued that together into a self-service site:
https://email-security-scans.org/
I'd be happy to hear your feedback, especially if things do not work as
expected (then, your test ID and ideally stored emails would be
52 matches
Mail list logo
