A DKIM signature acts like a notary public, "This person, who is well known
to me, can be reliably associated with this document."
Signing works for DMARC only when the DKIM signer has actually validated
the entity before adding the signature.
Therefore, when a signature is applied by an outbound
On 24/04/2019 03:02, Hector Santos wrote:
> Can anyone provide me some C/C++ or pseudo-code to do DKIM ecdhc
> encryption?... Using OpenSSL API in v1.1 format?
>
> Thanks
>
> PS: Not sure where to post this, but it equally applies to OpenSSL at
> GitHub.
>
Here is my pretty minimalistic (~3k Lo
And this using libsodium
https://github.com/halon/libdkimpp/commit/7e73f5b6a115b2cfdf8122824575b321d1c114f2
Regards
Erik
On 2019-04-24 13:34, Дилян Палаузов wrote:
Hello Hector,
you can check
https://github.com/Exim/exim/commit/286b9d5fa4344de72fe6575fa089237
(Exim+GnuTLS)
or
https://gith
Hello Hector,
you can check
https://github.com/Exim/exim/commit/286b9d5fa4344de72fe6575fa089237
(Exim+GnuTLS)
or
https://github.com/trusteddomainproject/OpenDKIM/commit/35bf6c901a2
(OpenDKIM+OpenSSL)
and the last discussion at https://mailarchive.ietf.org/arch/browse/dcrup/
(dc...@ietf.or
Can anyone provide me some C/C++ or pseudo-code to do DKIM ecdhc
encryption?... Using OpenSSL API in v1.1 format?
Thanks
PS: Not sure where to post this, but it equally applies to OpenSSL at
GitHub.
--
HLS
___
dmarc mailing list
dmarc@ietf.org
ht
>How would you suggest we drive a revision to RFC 6376 to address this issue?
As you saw, anything in the IETF that smells of crypto tends to go
into the weeds with the crypto fad du jour.
If you want to do this, I'd suggest an update with a very small focus:
1) Add a new signature algorithm, pr
Annyeong haseyo,
While this thread is relevant to dmarc, it doesn't cover dmarc work.
So can we please stop copying the dmarc mailing list and just send to
the dkim mailing list, where it belongs?
Thanks.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
On Fri, Apr 3, 2015 at 7:42 PM, John Levine wrote:
> In answer to someone else's question, libdkim is inded the Alt-N
> library which as far as I can tell hasn't been touched since 2008.
> It still seems to work OK, and it checks the v= in the signature
> to be "1" or some old 0.x test versions.
In article
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Looks like we require v to exist and be either 1 or DKIM1, otherwise you'll
>get a "bad format" or "bad version" in the AuthRes header. Wonder how old
>the DKIM1 is and whether we should remove that now...
The DNS key record has to say v=DKIM1
apps-discuss isn't interested in demarc procedural issues, I suppose.
Hector Santos writes:
> IMO, your proposal is on par with the engineering considerations
> needed to develop and mold the charter.
Maybe, that's for Barry to decide, I believe. My opinion is that this
part of the discussion
Hi Wei,
IMO, your proposal is on par with the engineering considerations needed to
develop and mold the charter. Your proposal intent is to preserve the
integrity and indirectly, the authorization for forwarding, resigning mail.
The draft charter has its own even higher complex ideas for t
On 6/28/2014 9:41 AM, Wei Chuang wrote:
Note this isn't a full proposal as we would like the concept to be
considered first. If this discussion is successful, we would like to also
discuss a related improvement to SPF and DMARC, as well as the binary
encoding change. At the conclusion we can ha
Dear J. Gomez,
Oops. Multi-tasking too much between conversations it seems.
This is what was intended in the last paragraph.
The basic goal is to devise a means to establish informal federations of
domains with a goal of not altering messages. With this goal, it can therefore
be assumed to pr
On Jun 4, 2014, at 3:07 PM, J. Gomez wrote:
> On Wednesday, June 04, 2014 10:56 PM [GMT+1=CET], Douglas Otis wrote:
>
>> On Jun 4, 2014, at 12:16 PM, J. Gomez wrote:
>>
>>> On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos
>>> wrote:
>>>
I prefer to update my software wit
On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull
wrote:
> Nor does DMARC say it's nonconforming; in fact, it automatically
> passes identity alignment, because there's nobody who is allowed to
> create domains under .invalid, so there can be no _dmarc.x.y.invalid.
>
Actually, it does not and
John Levine writes:
> From what I can see on the mailman lists, looking for the internal
> DKIM signatures won't work too well, since mailman sometimes
> removes parts from multipart/alternative to fix to some formatting
> issue.
Mailman implements certain MIME structure manipulations as a pe
Franck Martin writes:
> Anyhow... my point is that moving an human decision to the machine
> is difficult, this is why we rely on protocols
Sure. That's why the U.S. military relies on landmines, too. "Smart
bombs" aren't perfect, obviously, but they're better than landmines!
DMARC "p=reject
J. Gomez writes:
> On Wednesday, June 04, 2014 9:34 PM [GMT+1=CET], John R Levine wrote:
> > > Obfuscating the domain is quite suspicious because then, what
> > > entity is taking responsibility for that email? What abuse
> > > help-desk can the potential receiver recourse to?
> >
> > The
>I'm beginning to lean towards liking the "embedded message" solution that
>mailman has, though. In my testing, it works mostly fine in Gmail, though
>it assumes (and prefixes with) "forwarded message". YMail's handling isn't
>that pretty, however, as it ignores the headers of the embedded messag
>I'm beginning to lean towards liking the "embedded message" solution that
>mailman has, though. In my testing, it works mostly fine in Gmail, though
>it assumes (and prefixes with) "forwarded message". YMail's handling isn't
>that pretty, however, as it ignores the headers of the embedded messag
On Wednesday, June 04, 2014 10:56 PM [GMT+1=CET], Douglas Otis wrote:
> On Jun 4, 2014, at 12:16 PM, J. Gomez wrote:
>
> > On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos
> > wrote:
> >
> > > I prefer to update my software with the above script for our MTA
> > > receiver rather
On Jun 4, 2014, at 12:16 PM, J. Gomez wrote:
> On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos wrote:
>
>> I prefer to update my software with the above script for our MTA
>> receiver rather to add logic to rewrite the 5322.From to bypass a
>> security protocol
>
> Rewriting th
On 6/4/2014 3:16 PM, J. Gomez wrote:
On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos wrote:
I prefer to update my software with the above script for our MTA
receiver rather to add logic to rewrite the 5322.From to bypass a
security protocol
Rewriting the Header-From field in m
Obfuscating the domain is quite suspicious because then, what entity is
taking responsibility for that email? What abuse help-desk can the
potential receiver recourse to?
The one whose DKIM signature is on the mail, of course. Sigh.
That would be the no-longer valid (assuming it ever was) and
On Wednesday, June 04, 2014 9:34 PM [GMT+1=CET], John R Levine wrote:
> > That is true, but it is not the same to obfuscate the local part in
> > the ReturnAddress/FromHeader, than to obfuscate the domain.
> >
> > Obfuscating the domain is quite suspicious because then, what
> > entity is taking
On Wed, Jun 4, 2014 at 12:34 PM, John R Levine wrote:
> That is true, but it is not the same to obfuscate the local part in the
>> ReturnAddress/FromHeader, than to obfuscate the domain.
>>
>> Obfuscating the domain is quite suspicious because then, what entity is
>> taking responsibility for tha
That is true, but it is not the same to obfuscate the local part in the
ReturnAddress/FromHeader, than to obfuscate the domain.
Obfuscating the domain is quite suspicious because then, what entity is taking
responsibility for that email? What abuse help-desk can the potential receiver
recourse
On Wednesday, June 04, 2014 5:44 AM [GMT+1=CET], John Levine wrote:
> > Yes the email is legitimate, but how does the MTA knows it?
> >
> > Well a bayesian filter has learned that this type of content is
> > legitimate, and then one day a spammer uses the same content, but
> > change one link...
On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos wrote:
> I prefer to update my software with the above script for our MTA
> receiver rather to add logic to rewrite the 5322.From to bypass a
> security protocol
Rewriting the Header-From field in mailing list traffic is not "bypassi
- Original Message -
> From: "Stephen J. Turnbull"
> To: "Hector Santos"
> Cc: "Tony Hansen" , dmarc@ietf.org, "Kurt Andersen"
> , "Franck Martin"
>
> Sent: Wednesday, June 4, 2014 10:43:16 AM
> Subject: Re:
Kurt Andersen writes:
> On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull
> wrote:
>
> > Nor does DMARC say it's nonconforming; in fact, it automatically
> >> passes identity alignment, because there's nobody who is allowed to
> >> create domains under .invalid, so there can be no _dmarc
On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull
wrote:
> Nor does DMARC say it's nonconforming; in fact, it automatically
>> passes identity alignment, because there's nobody who is allowed to
>> create domains under .invalid, so there can be no _dmarc.x.y.invalid.
>>
>
Actually, it does not
Hector Santos writes:
> [Mail From: a domain under .INVALID] is not legitimate mail per the
> proposed security protocol.
Sorry, in this subthread, "legitimate", as used by Franck and myself,
means "delivery desired by the addressee". If you want to insist on a
different definition, go ahead,
John, I doubt these aol and yahoo users give a hoot of what u snuck into your
small local site. The odds are high these kind of addresses were first used for
junk, aliases, "throw away" addresses like most people did with these public
email service bureaus. Sure, for many, these public addresses
But it does know. It is not legitimate mail per the proposed security protocol.
The problem and conversation should be focused on resolving the 9 years old
mail integration dilemma -- the dearth of resigners not wanting to check for
bad DKIM-secured transactions via a policy layer protocol. Kee
>But that is not equivalent to putting non-resolvable gibberish on the right
>side of the @ sign. That's
>a reliable way of assuring that such messages do not get queued on my server.
>As a matter of
>practicality, I highly doubt that I'm unique in requiring that the sender
>domain (envelope and
Franck Martin writes:
> Yes the email is legitimate, but how does the MTA knows it?
Aha! Precisely where this conversation should go.
The MTA *doesn't* know. A mailing list knows more, though. And an
MUA knows a lot more than that. Or they could.
For bandwidth reasons, it's important (espe
Brandon Long writes:
> You're being a bit free with the "we" there.
Sorry if you understood it that way. I'm here as a delegate of the
Mailman project, and in this case I believe my views are
representative of a working consensus of the core developers and some
influential users. So I wrote "w
Elizabeth Zwicky writes:
> But I do, in fact, have data, and that data tells me that the attackers
> forging our users based on stolen addressbooks have never stopped; we are
> still blocking them now.
Interesting. No perceptible change at all? I am going to have to dig
up that graph of the
- Original Message -
> From: "Matt Simerson"
> To: dmarc@ietf.org
> Sent: Tuesday, June 3, 2014 10:01:37 PM
> Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't
> change)
>
>
> On Jun 3, 2014, at 8:44 PM, John
On Jun 3, 2014, at 8:44 PM, John Levine wrote:
>> Yes the email is legitimate, but how does the MTA knows it?
>>
>> Well a bayesian filter has learned that this type of content is legitimate,
>> and then one day a spammer
>> uses the same content, but change one link...
>
> That could happen
>Yes the email is legitimate, but how does the MTA knows it?
>
>Well a bayesian filter has learned that this type of content is legitimate,
>and then one day a spammer
>uses the same content, but change one link...
That could happen to any mail feature you care to name.
Big companies send bucket
- Original Message -
> From: "Stephen J. Turnbull"
> To: "Franck Martin"
> Cc: "Tony Hansen" , dmarc@ietf.org, "Kurt Andersen"
>
> Sent: Tuesday, June 3, 2014 7:16:04 AM
> Subject: Re: [dmarc-ietf] DKIM through mailing lists
But why would you accept emails from invalid domains in the first
instance?
Because the email is legitimate, of course.
Until it isn't.
The purpose of the ".invalid" TLD was not for bypassing a proposed
security protocol. This is a malicious hack that will ultimately help
break down on
On Tue, Jun 3, 2014 at 12:43 PM, Brandon Long wrote:
>
> Remember, we think *all* of the mitigations should be discouraged in
>> favor of not permitting posts from "p=reject" domains. But we also
>> know that will be unacceptable to most of our list operators.
>
>
> You're being a bit free with
On 6/3/14, 4:26 AM, "Stephen J. Turnbull" wrote:
>Elizabeth Zwicky writes:
>
> > At this point, I do not see going to p=quarantine in the hope
> > that attackers won't exploit data they already have exactly the same
> > way
>
>Has Yahoo! has already tried 'p=quarantine', or is that merely your
Franck Martin writes:
> I'm not sure it is wise to encourage the use of "invalid" domains
> in any of the email headers.
Remember, we think *all* of the mitigations should be discouraged in
favor of not permitting posts from "p=reject" domains. But we also
know that will be unacceptable to mos
Franck Martin writes:
> But why would you accept emails from invalid domains in the first
> instance?
Because the email is legitimate, of course. I've seen people use
"example.com" in their addresses on list posts to ensure they won't
get personal replies. I've seen people use "nore...@person
Elizabeth Zwicky writes:
> At this point, I do not see going to p=quarantine in the hope
> that attackers won't exploit data they already have exactly the same
> way
Has Yahoo! has already tried 'p=quarantine', or is that merely your
expert opinion? (Nothing against expertise, but "experiment
- Original Message -
> From: "Kurt Andersen"
> To: "Stephen J. Turnbull" , "Tony Hansen"
>
> Cc: dmarc@ietf.org
> Sent: Monday, June 2, 2014 12:55:39 PM
> Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won
- Original Message -
> From: "Stephen J. Turnbull"
> To: "Tony Hansen"
> Cc: dmarc@ietf.org
> Sent: Monday, June 2, 2014 12:28:21 AM
> Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't
> change)
>
> Tony Hansen
I'm a list software product developer. I believe our list package was
among the
first to implement domains controls with restrictive domains. In our
case, we used the then IETF Proposed Standard ADSP. It followed the
guidelines written in the 2006 DSAP (DKIM Signature Authorization
Protocol) I
Tony Hansen writes:
> I would love to see that list of multiple mitigations shared with the
> broader community. That would be useful information for people in the
> IETF,
I've shared it here in various levels of detail more than once, and
sooner or later it will be in the Mailman FAQ as I'm
It is true that when attackers can't use our From: lines, they
try other things.
Empirically, it's also clear that the attackers do not like
From: "Victim Name"
as much as they like
From: "Victim Name"
based on lowered volume when the second form is unavailable. Given that,
I see no reason
>That's okay -- it was just a thought. However, note that not all MLMs
>are in as good a shape as GNU Mailman is, volunteer-wise. For *them*, it
>might be useful.
I wouldn't count on it. I did .invalid patches for majordomo2, which
is largely abandonware but still used a fair number of places.
Thanks for your comments Stephen.
On 5/31/14, 1:51 PM, Stephen J. Turnbull wrote:
Tony Hansen writes:
>> That doesn't help the DMARC situation now, but DMARC could be
>> given other options once that happens.
>
> I agree completely that a change to DMARC is needed in conjunction
> wit
On May 31, 2014, at 8:49 AM, Stephen J. Turnbull
wrote:
> Douglas Otis writes:
>
>> https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly
>
> Grr. Doesn't describe the problem! Is it that a QuickBooks client
> using a mailbox a
Douglas Otis writes:
> https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly
Grr. Doesn't describe the problem! Is it that a QuickBooks client
using a mailbox at a "p=reject" domain is having QuickBooks send
invoices on their beha
Tony Hansen writes:
>> That doesn't help the DMARC situation now, but DMARC could be
>> given other options once that happens.
>
> I agree completely that a change to DMARC is needed in conjunction
> with having clear ML specs.
A change to the protocol? What? I don't see it. The protocol
Elizabeth Zwicky writes:
> So changes that maintain effective protection for users who are
> being targeted by attackers with addressbook information, with less
> disruption to email that people want, are of great interest to us.
How about trying "p=quarantine" with a real short TTL just in ca
On 05/30/2014 11:28 AM, Stephen J. Turnbull wrote:
> I am of the opinion that the technical DMARC protocols (including
> "p=reject") are fine. I have not heard of any complaint about use by
> banks (Bank of America joined the ranks of "p=reject" banks some time
> in the last 10 days AFAICT). Have
Murray S. Kucherawy writes:
> > DMARC change is even more off the table than MLM software change
> > (which does, as you suggest, evolve over time).
>
> Are there changes people want to make?
I am of the opinion that the technical DMARC protocols (including
"p=reject") are fine. I have not
On Friday, May 30, 2014 17:07:30 Elizabeth Zwicky wrote:
> On 5/29/14, 8:44 PM, "Scott Kitterman" wrote:
> >DMARC change is even more off the table than MLM software change (which
> >does,
> >as you suggest, evolve over time).
>
> DMARC changes are not off the table for Yahoo. Right now, the opti
On 5/29/14, 8:44 PM, "Scott Kitterman" wrote:
>DMARC change is even more off the table than MLM software change (which
>does,
>as you suggest, evolve over time).
DMARC changes are not off the table for Yahoo. Right now, the option that
best serves the majority of our customers is one that also
On May 30, 2014 3:37:28 AM EDT, "Murray S. Kucherawy"
wrote:
>On Thu, May 29, 2014 at 8:44 PM, Scott Kitterman
>wrote:
>
>> The reason there is no IETF working group is that the people behind
>DMARC
>> were
>> unwilling to entertain participation in a working group that had a
>charter
>> that al
On Thu, May 29, 2014 at 8:44 PM, Scott Kitterman
wrote:
> The reason there is no IETF working group is that the people behind DMARC
> were
> unwilling to entertain participation in a working group that had a charter
> that allowed for any chance of a change to the DMARC protocol.
>
I think that'
Dear Tony,
See comments inline:
On May 29, 2014, at 8:11 PM, Tony Hansen wrote:
> On 5/28/14, 6:46 PM, Barry Leiba wrote:
>> Anything that requires mailing list software to change won't work.
>
> I'm going to push back on this statement. I think we keep getting stuck on
> the mantra that "th
On Thursday, May 29, 2014 23:11:28 Tony Hansen wrote:
> On 5/28/14, 6:46 PM, Barry Leiba wrote:
> > Anything that requires mailing list software to change won't work.
>
> I'm going to push back on this statement. I think we keep getting stuck
> on the mantra that "the mailing list software won't c
On 5/28/14, 6:46 PM, Barry Leiba wrote:
Anything that requires mailing list software to change won't work.
I'm going to push back on this statement. I think we keep getting stuck
on the mantra that "the mailing list software won't change". However,
the majority of the mailing list software pa
On May 29, 2014, at 7:07 AM, Stephen J. Turnbull wrote:
> Douglas Otis writes:
>
>> There are many cases that are never originally signed by the DMARC
>> domain. Such as an accounting package that sends out invoices on
>> behalf of some company that wants their email address in the From
>> hea
Douglas Otis writes:
> There are many cases that are never originally signed by the DMARC
> domain. Such as an accounting package that sends out invoices on
> behalf of some company that wants their email address in the From
> header since this is what their customers will recognize.
I don't
On 5/28/2014 9:47 PM, Arvel Hathcock wrote:
Anything that requires mailing list software to change won't work. If
mailing list software is changed, the right answer is for the mailing
list to re-sign the message. That doesn't help the DMARC situation
now, but DMARC could be given other option
On 5/28/2014 6:47 PM, Arvel Hathcock wrote:
> That's right. But maybe there could be a multipart/dkim type that lets
> several signatures exist in a message - all of which could potentially
> verify with different d=.
Hi Arvel. Great to see you re-entering the fray...
Picking a nit: It's not
Anything that requires mailing list software to change won't work. If
mailing list software is changed, the right answer is for the mailing
list to re-sign the message. That doesn't help the DMARC situation
now, but DMARC could be given other options once that happens.
That's right. But may
On May 28, 2014, at 4:05 PM, Brandon Long wrote:
>
>
>
> On Wed, May 28, 2014 at 3:46 PM, Barry Leiba wrote:
> > We could attempt to define a dkim canonicalization that would pass through a
> > mailing list.
>
> This was beaten pretty severely during the DKIM work, and we couldn't
> come up
> We could attempt to define a dkim canonicalization that would pass through a
> mailing list.
This was beaten pretty severely during the DKIM work, and we couldn't
come up with anything that was workable.
> It should include the subject, but have rules for stripping "standard"
> subject prefixes
76 matches
Mail list logo
