I'm thrilled to hear that you're interested in contributing to open
source projects!
I don't use this library (sad face) But you can help tons of people by
being a contributing member.
Log in and start contributing?
The Debian teams that support OpenDKIM have a structured hierarchy and
addi
On Fri, Aug 9, 2024 at 5:03 AM Richard Hector via mailop
wrote:
> Sorry for the resurrection of an old thread.
>
> I recently set up DKIM, partly using https://wiki.debian.org/opendkim as
> my reference. That seems to suggest using l=, so that's what I did ...
>
> If it's not good advice, perhaps
On 18/05/24 02:12, Taavi Eomäe via mailop wrote:
Hi!
As part of coordinated disclosure, I am sharing it here as well. In
short, using the approach described below, attackers can replace the
entire contents of a letter, in a way the letters still pass DKIM’s
cryptographic checks. This also mea
On 17/05/2024 15:12, Taavi Eomäe via mailop wrote:
Hi!
As part of coordinated disclosure, I am sharing it here as well. In
short, using the approach described below, attackers can replace the
entire contents of a letter, in a way the letters still pass DKIM’s
cryptographic checks. This also m
On Sat 18/May/2024 19:37:44 +0200 Dave Crocker via mailop wrote:
On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:
We hope that with some cooperation from mail operators improved defense
measures can be implemented to strengthen DKIM for everyone.
As I recall, the original intent was to pe
On 5/18/2024 2:12 PM, Gellner, Oliver via mailop wrote:
Changing the existing DKIM specification is probably a big challenge.
Yes, but it can be done as a separate specification that is classed as
an 'update' to the DKIM spec.
fwiw, I've heard rumors of some industry folk wanting to produce
On 2024-05-18 at 17:12:11 UTC-0400 (Sat, 18 May 2024 21:12:11 +)
Gellner, Oliver via mailop
is rumored to have said:
On 18.05.2024 at 21:02 Dave Crocker via mailop wrote:
[...]
Seems like the right approach is to seek community-wide pressure to
deprecate it. First through operational pre
> On 18.05.2024 at 21:02 Dave Crocker via mailop wrote:
>
> On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:
>> Although some of these dangers have been known for a while (some parts are
>> even described in the RFC itself), things like the threat landscape, our
>> approach and the extent to
> Other than that, I'm with you, it is a fraction of a percent of signed
> mail, not common at all.
I'm with Dr Levine; I just looked at all the stuff our spamtrap system
has received in May so far (n~=8M). The exact number I came up with is
0.6%. Also, the percentage of signed mail out of all mai
On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:
Although some of these dangers have been known for a while (some parts
are even described in the RFC itself), things like the threat
landscape, our approach and the extent to which this can be abused
have changed. In our opinion previously sug
On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:
Although some of these dangers have been known for a while (some parts
are even described in the RFC itself), things like the threat
landscape, our approach and the extent to which this can be abused
have changed. In our opinion previously sug
It appears that Bill Cole via mailop
said:
>Who uses it?
In my logs most of the l= tags are l=1 on that libertarian newsletter,
and one or two other newsletters.
I see that Verisign puts an l= in the mail their employees send with the
real message length.
Other than that, I'm with you, it is a
It appears that Slavko via mailop said:
>I feel as the problem lies elsewhere. Perhaps just mentioned gigants
>fails properly parse the l= tag (or even do not parse it at all) and their
>UI shows whole message (or all its parts) as signed, ...
That's not how DKIM works, and not how l= works. Eith
It appears that Taavi Eomäe via mailop said:
>> Every a few months we see a paper / blogpost that passes SPF / DKIM /
>> DMARC. So maybe requiring both SPF and DKIM for BIMI would be a good idea.
>
>Both together might make sending a bit too error-prone. Hardening DKIM
>seems more doable. I hope
Dňa 18. mája 2024 16:07:51 UTC používateľ Bill Cole via mailop
napísal:
>Who uses it?
I feel as the problem lies elsewhere. Perhaps just mentioned gigants
fails properly parse the l= tag (or even do not parse it at all) and their
UI shows whole message (or all its parts) as signed, despite that
On 2024-05-17 at 14:38:00 UTC-0400 (Fri, 17 May 2024 18:38:00 +)
Gellner, Oliver via mailop
is rumored to have said:
While it’s not new information that the length attribute of DKIM
poses a security risk, it’s still worthwhile to draw attention to it
every once in a while and the usual sus
On 18/05/2024 01:53, Alex Liu wrote:
I dont know this is that new with regard to DMARC. missing citation:
https://www.usenix.org/system/files/sec20-chen-jianjun.pdf
Thanks for the reference, I'll give it a read when I get the chance.
Email is quite old by now, so the amount of resources to go
I dont know this is that new with regard to DMARC. missing citation:
https://www.usenix.org/system/files/sec20-chen-jianjun.pdf
It is, however, the first time someone tries to combine with BIMI.
Every a few months we see a paper / blogpost that passes SPF / DKIM /
DMARC. So maybe requiring both S
On 17/05/2024 18:37, Slavko via mailop wrote:
I didn't get what is **new** in it, nor how length of RSA keys is related...
Turning the original content into a comment seemed novel to us, should
in theory yield better forgeries than just adding new boundaries.
Gmail's "show original" also seem
On Fri, May 17, 2024 at 02:11:04PM -0700, Brandon Long via mailop wrote:
> I guess the part that's new to me is the apparent widespread (enough) use
> of the l=
> parameter. I don't recall ever noticing its use before, though can't say
> it was ever top
> of mind when looking at various headers of
On Fri, 17 May 2024, Brandon Long wrote:
I guess the part that's new to me is the apparent widespread (enough)
use of the l= parameter. I don't recall ever noticing its use before,
though can't say it was ever top of mind when looking at various headers
of messages.
I have to admit I'm surpr
On Fri, May 17, 2024 at 1:07 PM John Levine via mailop
wrote:
> It appears that Taavi Eomäe via mailop said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >Hi!
> >
> >As part of coordinated disclosure, I am sharing it here as well. In
> >short, using the approach described below, attackers can replace the
> >
It appears that Taavi Eomäe via mailop said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>Hi!
>
>As part of coordinated disclosure, I am sharing it here as well. In
>short, using the approach described below, attackers can replace the
>entire contents of a letter, in a way the letters still pass DKIM’s
>cryptogr
The mailauth command can detect these signatures
https://github.com/postalsys/mailauth/blob/master/cli.md
For example
$ mailauth report path-to-email.eml
"canonBodyLength": 87122,
"canonBodyLengthTotal": 87563,
"canonBodyLengthLimited": true,
"canonBodyLengthLimit": 87122,
"mimeStructureStar
> On 17.05.2024 at 16:24 Taavi Eomäe via mailop wrote:
>
> Although some of these dangers have been known for a while (some parts are
> even described in the RFC itself), things like the threat landscape, our
> approach and the extent to which this can be abused have changed. In our
> opinion p
And the reason why wanting to require both SPF _and_ DKIM passing would be a
good thing...
Unfortunately one cannot do that.
Greets,
Jeroen
--
> On 17 May 2024, at 16:12, Taavi Eomäe via mailop wrote:
>
> Hi!
>
> As part of coordinated disclosure, I am sharing it here as well. In short,
>
Dňa 17. mája 2024 14:12:41 UTC používateľ "Taavi Eomäe via mailop"
napísal:
>A longer description with images is available here:
>https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
I didn't get what is **new** in it, nor how length of RSA keys is related...
The l= DKIM tag was
Am Fri, 17 May 2024 16:04:56 +0100 (BST)
schrieb Andrew C Aitchison via mailop :
> If the mail system uses a DKIM pass to show the *other pieces*
> of the message as trusted, then bad things can happen.
I don't know any end users system that shows those results to the user.
I only know MTA's filt
On Fri, 17 May 2024, Taavi Eomäe via mailop wrote:
As part of coordinated disclosure, I am sharing it here as well. In short,
using the approach described below, attackers can replace the entire contents
of a letter, in a way the letters still pass DKIM’s cryptographic checks.
This also means
Hi!
As part of coordinated disclosure, I am sharing it here as well. In
short, using the approach described below, attackers can replace the
entire contents of a letter, in a way the letters still pass DKIM’s
cryptographic checks. This also means these forged letters can be easily
replayed to
30 matches
Mail list logo
