On Fri, Feb 9, 2018 at 3:22 PM, John Levine wrote:
> In article <1707398.kN3rUcK64s@kitterma-e6430> you write:
> >Does this need to update RFC 7208 since there are SPF related MUST
> >requirements?
>
> I would think so, also 6376, 7489, 7601 since it updates DKIM, DMARC, and
>
On Thu, Feb 8, 2018 at 5:22 AM, John R. Levine wrote:
> someone asked me about case sensitiveness of the header field name. I
>> looked
>> for an ABNF in RFC6376, but only found examples and informative notes.
>>
>
> I was going to say that can't possibly be true, but it's true,
On Tue, Dec 5, 2017 at 2:52 PM, Pawel Lesnikowski
wrote:
>
> DKIM works as expected, but as you said it may re-enforce an incorrect
> assumption that email is from respected source.
>
>
Only if it's abused by saying "DKIM signature verified, it's safe!" rather
than "
I disagree that it's specifically a DMARC issue, because from that I infer
that you think DMARC is at fault here, i.e., that you expected it to deal
with this.
On Tue, Dec 5, 2017 at 1:44 PM, Steve Atkins
wrote:
> That's DMARC working exactly as designed but not as
On Tue, Feb 7, 2017 at 10:25 AM, Barry Leiba
wrote:
> >>Murray, Tony, or someone else: Can you independently check that these
> >>examples need the extra space in order to be verified correctly?
> >
> > Murray did that for us a decade ago -- it's one of the test cases
:
>
> On 11/13/2016 09:38 PM, Murray S. Kucherawy wrote:
>
> On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany <sx6un-fc...@qmda.emu.st>
> wrote:
>
> Hi Murray.
>
>
> Mark!
>
> > RFC6376 and even RFC4871, but now it's apparently happening
>
> I'd be intere
On Tue, Nov 22, 2016 at 7:45 AM, Michael Storz wrote:
>
>> The negative side of the proposal is the requirement to split all
>>> multi-recipient-emails to single-recipient-emails, which is a show
>>> stopper for me.
>>>
>>
>> That's curious; why?
>>
>
> Because SMTP is
On Fri, Nov 18, 2016 at 3:47 AM, Michael Storz wrote:
> Normal DKIM-Signatures give us a way to check if the body and/or header of
> an email has been changed on the way from the signer to the verifier. The
> new extension extends this to the recipients of the email. A
On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz wrote:
>
> Thanks, I see. That means the recipient is bound to the message and an
> attacker cannot delete or change the new tags. Great solution, I like it,
> though I do not like the consequences when this extension will go
On Fri, Nov 18, 2016 at 1:11 AM, Rolf E. Sonneveld <
r.e.sonnev...@sonnection.nl> wrote:
> Hi, Murray,
>
> On 16-11-16 02:45, Murray S. Kucherawy wrote:
>
>> There's been a lot of great feedback here. I just cranked out an update
>> based on the discussion so f
On Thu, Nov 17, 2016 at 7:28 PM, Alessandro Vesely wrote:
>
> Yes.
>>
>
> Well, if its title were *Incompatibility with Current Infrastructure*, I
> would agree there is a statement on the risk of disrupting how DKIM works.
>
That section talks about some things that are
On Thu, Nov 17, 2016 at 3:09 AM, Terry Zink
wrote:
> > This means ARC will be needed not only for mailing lists which modify
> the header or
> > body of an email, but for EVERY mailing list and EVERY forwarded email
> or EVERYTIME
> > the recipient has been modified
On Thu, Nov 17, 2016 at 3:47 AM, Alessandro Vesely wrote:
>
> That way it will stay dormant until someone gets hurt and has to activate
>>> it, at which time it may cause more damage than improvement. A loose
>>> cannon.
>>>
>>
>> The document makes that risk clear, or so I
On Wed, Nov 16, 2016 at 11:50 PM, Michael Storz
wrote:
>
> Ok, I see you have removed the hashing of the recipient together with the
> email itself. But how do you prevent a replay attack, if the new tag is not
> bound to the email and signed with the DKIM-key (that's how I
(dropping DMARC again)
On Wed, Nov 16, 2016 at 9:51 PM, Michael Storz wrote:
> Version 01 is purely incremental, meaning you can just ignore the new
>> tags if you're more worried about breakage of forwarding than the
>> attack it's trying to address.
>>
>
> Optional for
On Wed, Nov 16, 2016 at 7:57 PM, Alessandro Vesely wrote:
> That way it will stay dormant until someone gets hurt and has to activate
> it, at which time it may cause more damage than improvement. A loose
> cannon. I'd keep it in its own header field [Ned's (1)(a)], so as to
On Wed, Nov 16, 2016 at 1:05 PM, John R Levine wrote:
>
> So far this exercise has mostly served to persuade me that putting
> envelope info in the DKIM signature is a bad idea, and our advice to people
> who have problems with recipients remailing spam they've signed remains
>
On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink
wrote:
> Large email receivers forward tons of email. This proposal causes email
> from DMARC-passing messages to be incapable of forwarding. As a large email
> receiver who gets tons of complaints about breakage of DKIM
On Wed, Nov 16, 2016 at 10:56 AM, John R Levine wrote:
> https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01
>>
>> I forgot to update the title of Section 3, but other than that I think I
>> captured what's been discussed. Please let me know what I've missed.
>>
>
>
On Wed, Nov 16, 2016 at 5:11 AM, Michael Thomas wrote:
> So, when the filters catch up, it will then mark it as spam again
> regardless of the DKIM signature.
>
> So what exactly is the problem here?
>
I suppose when the filters catch up, the spammer can no longer get
On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten wrote:
> My understanding is an attack where the email is sent to an outside
> address owned by the sender, who then gets a copy of the email, signed
> by the provider who didn't think the email was bad.
>
> Signing an
On Tue, Nov 15, 2016 at 6:01 PM, Vladimir Dubrovin <dubro...@corp.mail.ru>
wrote:
> 15.11.2016 2:07, Murray S. Kucherawy пишет:
>
> On Mon, Nov 14, 2016 at 10:36 PM, <ned+dm...@mrochek.com> wrote:
>
>> Let's break this down. If we're going to include recipients in t
On Mon, Nov 14, 2016 at 10:36 PM, wrote:
> Let's break this down. If we're going to include recipients in the DKIM
> signature, it seems we have at least three key design decisions to make:
> [...]
>
That's a pretty excellent summary. A couple of points:
I think you
Hi Rolf,
On Tue, Nov 15, 2016 at 7:41 AM, Rolf E. Sonneveld <
r.e.sonnev...@sonnection.nl> wrote:
> At the time SenderID was proposed, back in 2004 or something, the act of
> propagating header information into the transport stream was seen by many
> as a layering violation. The proposal of
On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed wrote:
> > Actually same message to same destination may be
> > sent to different MTAs (e.g. different MXs with same weight).
> > 2.3 Canonization must be better defined. It's usual for MTA to e.g.
> > lowercase the domain of
On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin
wrote:
> 1. This standard is not backward compatible with existing DKIM
> implementations. It makes it useless. In addition, in it's current form it
> can not be implemented in most MTAs (see below)
> 2. This standard
On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman
wrote:
> Wouldn't a DMARC option to allow senders to specify only messages that
> pass verification and alignment for BOTH SPF and DMARC accomplish the same
> result with less complexity and without the layering violation
On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany
wrote:
> Hi Murray.
>
Mark!
> RFC6376 and even RFC4871, but now it's apparently happening
>
> I'd be interested to hear about the actual scenarios. Are the targeted
> users somehow given an indication that the email verifies
I've posted a draft that attempts to address an attack that's begun to
appear with DKIM. Interestingly, we called it out as a possible attack in
RFC6376 and even RFC4871, but now it's apparently happening and being
annoying enough that people (I believe from the MAAWG community) are asking
if
On Tue, Sep 27, 2016 at 8:15 PM, Jiankang Yao wrote:
> Since EAI deployment is on the way, gmail, outlok2016, postfix, yandex,
> xgenplus and many more have adopted EAI.
> In order to make EAI environment more friendly, I suggest that this WG
> considers to move this
That looks correct to me. Barry or Dave?
On Mon, Sep 26, 2016 at 2:55 PM, Stephen Farrell
wrote:
>
> If someone familiar with the dkim abnf could comment I'd be
> happy to approve/reject this as appropriate.
>
> S
>
> On 26/09/16 20:15, RFC Errata System wrote:
> >
On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten
martijn.groo...@virusbtn.com wrote:
Why remove 512 support from the verification side? Does this mean the
verifier will take valid 512 signature and make it invalid, no signature
message? Is there a correlation out there that 512 bits
On Tue, May 12, 2015 at 8:28 PM, Scott Kitterman ietf-d...@kitterman.com
wrote:
Is it appropriate to change the protocol document for this? Isn't it
really more of a BCP?
I think when key size got put in the protocol, then it's a protocol update
to
change it.
Is it part of the
On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas m...@mtcc.com wrote:
The list of things DMARC does that ADSP doesn't in its appendix, is a trip
down memory lane
of constraints that were placed on it by the
against-it-before-they-were-for it set. True
SPF wasn't ever on its radar -- SPF has
I also agree with this proposal. I don't have much to add over the text in
the formal request; it lays out the case based on my experience
implementing DKIM and ADSP in open source. I can also say that I have
never encountered an operation that actively uses it, including current and
previous
On Thu, Aug 15, 2013 at 8:46 AM, Stephen Farrell
stephen.farr...@cs.tcd.iewrote:
That looks weird. Do we know its not spam?
S
First I've heard of it.
-MSK
___
NOTE WELL: This list operates according to
On Sun, Aug 4, 2013 at 1:35 PM, Pawel Lesnikowski
lesnikow...@limilabs.comwrote:
There are few details I'd like to clarify.
Body hash for this message is correctly computed by the sender.
Entire signature of this message in fact valid - this is why Port25,
Gmail, and Mail.dll validate DKIM
If the message is totally empty or consists only of CRLF sequences, or not
even that, then the l= value should be zero since they would all be
ignored and not fed to the hash; the total number of bytes fed to the hash
would be zero. I suggest reaching out to Gmail to find out what's going on.
On Sat, Aug 3, 2013 at 2:09 AM, Michael Deutschmann
mich...@talamasca.ocis.net wrote:
Your question about drafts has two possible implications. The first is
I'm not going to pay any attention to Michael until he takes up RFC
lawyering. In which case I can't help you.
My problem is that
On Sun, Jun 30, 2013 at 9:21 AM, John R. Levine jo...@iecc.com wrote:
What I'm asking for is nothing like SES. I want the signature to be
based on the envelope MAIL FROM:, but it is still the body that gets
signed. No VERPing is called for. ...
Where can we read the draft?
+1. I pledge
On Mon, Jul 1, 2013 at 12:24 PM, Michael Deutschmann
mich...@talamasca.ocis.net wrote:
On Mon, 1 Jul 2013, Alessandro Vesely wrote:
Well, not really. MAIL FROM: is only visible after delivery, so to
avoid dangling signatures one should store its value in some other
header field or... in
On Sat, Jun 22, 2013 at 9:49 PM, Michael Deutschmann
mich...@talamasca.ocis.net wrote:
(I have deployed DKIM alone senderside, but that's just to keep in
practice in case someone invents an accessory protocol that's actually
sane. Allowing me to declare that all mail bearing my RFC821 MAIL
On Tue, Jun 18, 2013 at 7:59 AM, Dave Crocker dcroc...@bbiw.net wrote:
On 6/18/2013 7:18 AM, Tony Hansen wrote:
I always thought it would be a nice follow-on to DKIM to provide a way
for a site to specify how that site was using i=; that is, to provide
some clarity and comprehension for
At the IETF meeting in Atlanta, Tim Draegen presented a proposal for DMARC,
which is an email authentication and reporting layer atop SPF and DKIM.
The externally-developed proposal is now in widespread deployment by a
number of large-scale providers. The group that developed it is seeking to
Colleagues,
(with apologies for the cross-posting if you get more than one copy of this)
As you may have seen already, I'm working on a revision to RFC5451.
A Proposed Standard bis effort always benefits from describing extant
implementations. I know about the ones I've written, and about some
On Wed, Jul 25, 2012 at 10:42 PM, Roland Turner
roland.tur...@trustsphere.com wrote:
This appears to be the inverse of the use case that was originally put
forward (we're concerned that we're signing rubbish, please disregard
signatures made with this selector); the very case that you're
On Mon, Jul 23, 2012 at 6:26 AM, Richard Dawe
rich.d...@messagesystems.comwrote:
Do you think that DMARC provides a better way of testing your DKIM
signatures than DKIM's t=y? E.g.: p=none DMARC policy.
I don't understand what you're after here. How would a mail receiver apply
p=none as
On Mon, Jul 23, 2012 at 6:42 AM, Michael Thomas m...@mtcc.com wrote:
There seems like there are many things wrong with this sort of
helpfulness. If a given selector is dodgy, the reputation system
should figure that out for itself. Believing even a vaguely
positive-assertion from the source
On Mon, Jul 23, 2012 at 6:13 AM, Barry Leiba barryle...@computer.orgwrote:
Should't have been signed by us clearly can't mean that someone
stole the private key or otherwise hacked things, so you're saying,
Our processes might not be set up right, and we might be signing crap
sent by bad
On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker d...@dcrocker.net wrote:
Here are two small tweaks that might correct things:
y This domain is testing DKIM. Verifiers MUST NOT treat messages
from Signers in testing mode differently from unsigned email.
This covers
And you thought this list was dead.
I was asked to consult recently on some DKIM questions raised by a customer
of a former employer. The questions involved the meaning of t= in DKIM
keys and the text in RFC6376. The focus of this tag has always been, to
the best of my recollection, the notion
On Tue, Jun 19, 2012 at 5:49 AM, Chris Lamont Mankowski
makerofthing...@gmail.com wrote:
I realize my last message talked about TLS-OBC for SMTP but didn't preface
it with any information on how I see how it can replace, or compliment SPF
in a given situation. First, does anyone know of a
FYI
-Original Message-
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On
Behalf Of rfc-edi...@rfc-editor.org
Sent: Wednesday, February 29, 2012 10:59 AM
To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org
Cc: rfc-edi...@rfc-editor.org
Subject: RFC 6541 on
FYI, in case anyone wants to comment.
-Original Message-
From: marf-boun...@ietf.org [mailto:marf-boun...@ietf.org] On Behalf Of The IESG
Sent: Wednesday, February 29, 2012 6:58 AM
To: IETF-Announce
Cc: m...@ietf.org
Subject: [marf] Last Call: draft-ietf-marf-dkim-reporting-11.txt
Hi all,
This got approved by the IESG. Note that it is slightly different than the
last time it was discussed here, courtesy of some suggested changes during IESG
evaluation.
OpenDKIM has already implemented the revised version and is thus available for
interop testing if anyone wants to try
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Monday, July 11, 2011 3:52 AM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
Agents that evaluate or apply DKIM
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Michael Deutschmann
Sent: Sunday, July 10, 2011 12:53 AM
To: DKIM List
Subject: Re: [ietf-dkim] Doublefrom language should be in ADSP, not core
The attack only matters if
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Scott Kitterman
Sent: Sunday, July 10, 2011 6:46 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Doublefrom language should be in ADSP, not core
I think we should
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Sunday, July 10, 2011 6:00 AM
To: DKIM
Cc: Pete Resnick
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
Implementors of
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Murray S. Kucherawy
Sent: Sunday, July 10, 2011 8:39 PM
To: Charles Lindsey; DKIM
Cc: Pete Resnick
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Friday, July 08, 2011 3:59 AM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
My favourite counterexample, which
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Friday, July 08, 2011 3:52 AM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
1. The fact that DKIM choose headers
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Thursday, July 07, 2011 3:09 AM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
The signer most certainly CAN
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Thursday, July 07, 2011 4:56 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
I'd s/to be
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Scott Kitterman
Sent: Thursday, July 07, 2011 6:32 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
I'm working with
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Scott Kitterman
Sent: Thursday, July 07, 2011 9:44 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
I agree it's not
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Thursday, July 07, 2011 12:31 PM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
I think Murray is wrong. There is
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Douglas Otis
Sent: Thursday, July 07, 2011 6:47 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
Unfortunately, the
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Barry Leiba
Sent: Wednesday, July 06, 2011 9:32 AM
To: Charles Lindsey
Cc: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
As Pete has
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Barry Leiba
Sent: Saturday, July 02, 2011 8:27 PM
To: DKIM Mailing List
Subject: [ietf-dkim] Final update to 4871bis for working group review
We have a week. Murray will
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Thursday, June 30, 2011 7:05 AM
To: DKIM
Subject: Re: [ietf-dkim] Pete's review of 4871bis
The problem is that an apparently valid signature (albeit
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Wednesday, June 29, 2011 9:20 AM
To: DKIM
Subject: Re: [ietf-dkim] Pete's review of 4871bis
I agree that 8.14 is poorly written (and it was even
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Dave CROCKER
Sent: Wednesday, June 29, 2011 11:56 AM
To: Pete Resnick
Cc: DKIM
Subject: Re: [ietf-dkim] Pete's review of 4871bis
If I missed it, I apologize, but have you
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Tuesday, June 28, 2011 12:13 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] spam filtering 101
+1, revising RFC 2505, whose date is in last
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Monday, June 27, 2011 2:43 AM
To: DKIM
Subject: Re: [ietf-dkim] spam filtering 101, was DKIM expert group meeting
for Dutch 'comply or explain' list
-Original Message-
From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On
Behalf Of internet-dra...@ietf.org
Sent: Friday, June 24, 2011 12:08 PM
To: i-d-annou...@ietf.org
Cc: ietf-dkim@mipassoc.org
Subject: I-D Action: draft-ietf-dkim-rfc4871bis-13.txt
A
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Ian Eiloart
Sent: Friday, June 17, 2011 2:41 AM
To: dcroc...@bbiw.net
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] I-D Action: draft-ietf-dkim-rfc4871bis-11.txt
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Friday, June 17, 2011 8:13 AM
To: ietf-dkim@mipassoc.org
Subject: [ietf-dkim] Certified DKIM verification
Hi all,
does anybody know about
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Steve Atkins
Sent: Monday, May 30, 2011 9:14 AM
To: DKIM List
Subject: Re: [ietf-dkim] New canonicalizations
The most obvious thing that MLMs do that invalidate signatures
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Saturday, May 28, 2011 9:29 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] New canonicalizations
On 27/May/11 19:16, Murray S. Kucherawy
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Friday, May 27, 2011 9:08 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] MLMs and signatures again
Certainly a possible feature, but it
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Friday, May 27, 2011 10:09 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] New canonicalizations
By introducing a loose canonicalization we
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Hector Santos
Sent: Thursday, May 26, 2011 10:44 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] MLMs and signatures again
This sounds like you are missing a point
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Ian Eiloart
Sent: Thursday, May 26, 2011 3:08 AM
To: John R. Levine
Cc: DKIM List
Subject: Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
I think the long term solution
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of John R. Levine
Sent: Thursday, May 26, 2011 6:40 AM
To: Ian Eiloart
Cc: DKIM List
Subject: Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
Mailing lists have worked
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Steve Atkins
Sent: Thursday, May 26, 2011 12:21 PM
To: DKIM List
Subject: Re: [ietf-dkim] MLMs and signatures again
In my experience with traditional discussion MLMs
-Original Message-
From: John R. Levine [mailto:jo...@iecc.com]
Sent: Thursday, May 26, 2011 1:29 PM
To: Murray S. Kucherawy
Cc: DKIM List
Subject: Re: [ietf-dkim] MLMs and signatures again
If anyone's claiming that contributors' DKIM signatures on list mail are
important, a good
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Franck Martin
Sent: Thursday, May 26, 2011 1:13 PM
To: Steve Atkins; DKIM List
Subject: Re: [ietf-dkim] MLMs and signatures again
side note: do
mail receivers treat
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Steve Atkins
Sent: Thursday, May 26, 2011 3:20 PM
To: DKIM List
Subject: Re: [ietf-dkim] MLMs and signatures again
That's relying on an awful lot of vaporware in the MUA,
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Steve Atkins
Sent: Thursday, May 26, 2011 3:47 PM
To: DKIM List
Subject: Re: [ietf-dkim] MLMs and signatures again
It's not vapourware in general. Such feedback systems
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of MH Michael Hammer (5304)
Sent: Thursday, May 26, 2011 4:15 PM
To: Scott Kitterman; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] MLMs and signatures again
The other
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Scott Kitterman
Sent: Thursday, May 26, 2011 5:36 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] MLMs and signatures again
My experience is it varies a lot by
-Original Message-
From: Dave CROCKER [mailto:d...@dcrocker.net]
Sent: Tuesday, May 24, 2011 5:33 PM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] New canonicalizations
Let's make it be the right work.
To make a canonicalization algorithm
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Monday, May 23, 2011 2:21 AM
To: DKIM
Subject: Re: [ietf-dkim] New canonicalizations
Could you get the effect of this by including the
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Scott Kitterman
Sent: Monday, May 23, 2011 10:12 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] 8bit downgrades
Do you have numbers to show that broken signatures
-Original Message-
From: Michael Thomas [mailto:m...@mtcc.com]
Sent: Wednesday, May 25, 2011 7:03 AM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] No signatures, bad signatures, cousin domains
Heuristic based systems like SA are subject to the phases
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Hector Santos
Sent: Sunday, May 22, 2011 10:43 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] 8bit downgrades
Please refrain from passing the buck to the WG. The
-Original Message-
From: Ian Eiloart [mailto:i...@sussex.ac.uk]
Sent: Thursday, May 19, 2011 4:00 AM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] New canonicalizations
Right, but you can't address that by examining only the traffic from
the high
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Ian Eiloart
Sent: Thursday, May 19, 2011 3:21 AM
To: John Levine
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] New canonicalizations
Probably true, but if the
Can anyone remember why there's a SHOULD for the downgrade to 7-bit in RFC4871
Section 5.3, rather than a MUST? The likelihood of breakage is so high when
sending 8-bit data that DKIM almost becomes pointless without the upgrade.
Not advocating for this to be changed in -bis (yet), but
1 - 100 of 656 matches
Mail list logo