On Tue, Nov 15, 2016 at 11:56:11AM -0600, Scott Kitterman wrote:
> Not at all. As I understand the scenario, the provider knows it's
> bad, doesn't send the mail on to the outside world, but still gives a
> signed copy back to the originator (which is then available for
> replay).
My understandin
On Mon, Nov 14, 2016 at 07:42:16AM -0500, Scott Kitterman wrote:
> OK. Ultimately, "don't sign spam" has got to be the solution or reputation
> is
> going to suffer, so I think they are going to have to eventually bite the
> bullet and fix it.
I think you underestimate how difficult it is to d
On Tue, Nov 15, 2016 at 08:07:38AM +0900, Murray S. Kucherawy wrote:
> This is not reversible so nothing is leaked, but as we've all conceded by now
> it's not hard to attack this to recover the hashed address especially since
> one
> might have good guesses as to what that address would be.
I ca
On Mon, Nov 14, 2016 at 02:48:01PM +0900, Murray S. Kucherawy wrote:
> On Mon, Nov 14, 2016 at 5:30 AM, Martijn Grooten
> wrote:
>
> It isn't very clear to me how this proposal deals with receipients at
> different domains, including but not limited to blind carbon co
On Sun, Nov 13, 2016 at 03:50:05PM +0900, Murray S. Kucherawy wrote:
> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/
>
> Comments welcome.
Thanks for this.
It isn't very clear to me how this proposal deals with receipients at
different domains, including but not limited to blind c
On Fri, Oct 28, 2016 at 11:06:34AM +0100, Stephen Farrell wrote:
> Instead, I'd point out that this can be handled, even now,
> by simply rolling to a new key and then shortly publishing
> the private key used to sign the messages. That way Podesta
> could deny the content once more, at least at th
On Tue, May 19, 2015 at 11:40:12AM +0200, Alessandro Vesely wrote:
> Apologies for jumping in late; just to note that 1024-bit keys seem to have
> been accepted until quite recently:
> https://www.sophos.com/en-us/support/knowledgebase/122327.aspx
This refers to certificates signed with RSA-1024 k
On Wed, May 13, 2015 at 01:21:36PM +0800, Roland Turner wrote:
> (e.g. perhaps measurement discovers that 512 bit keys are only used by
> low-risk domains; does this warrant killing the feature for the good of those
> who are being targeted, or retaining it because it's still in use, with a
> clea
> 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 signers are more
> prune to be Bad Guys? Spammers?
The problem here is that 512-bit keys ca
PS References that were left out of the version of the email I did not send to
Hector only:
[1]
http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html
[2] http://www.wired.com/2012/10/dkim-vulnerability-widespread/
Virus Bul
> I propose a short draft that updates 6376 to say MUST use at least 1024 bits
> and setting that as the minimum size verifiers must be able to validate. I'm
> volunteering to write it if people agree it's appropriate.
I think it is appropriate - and I agree with others that we shouldn't go beyon
Graham Murray wrote:
> An MUA does not have to do filtering in order to support DKIM. It could
> display the Authentication Results header, or take some action
> depending
> on whether there is a valid DKIM signature - in a similar way that some
> web browsers will turn the URL bar green when the s
> On 8/4/2010 2:01 PM, John Levine wrote:
> >> There's a scenario where a spammer/phisher sets up a mailing list,
> ...
> > I don't see how this poses any new problems.
>
>
> More to the point is that this attack does not appear to be relevant to
> the
> question I asked.
>
> Phrased differently, t
roken, don't send it through systems that are likely to
break it.
Martijn.
> -Original Message-
> From: Dave CROCKER [mailto:dcroc...@bbiw.net]
> Sent: 04 August 2010 18:35
> To: Martijn Grooten
> Subject: Re: [ietf-dkim] Clarifying DKIM (etc.) expectations for
> mail
> What is the security model that makes this expectation of preservation
> important
> and reasonable, given that it is so easily and whimsically violated by
> a common
> recipient-selectable setting?
There's a scenario where a spammer/phisher sets up a mailing list, adds a bunch
of addresses to
> Assuming you do any sorting of inbound mail at all, how do you treat
> mail from lists to which you have subscribed?
>
> A) Use the From: address (or something that identifies the contributor)
> as the primary sort criterion
>
> B) Use the List-ID: (or something that identifies the list) as the
>
> So why does a domain that performs that painful audit and
> remediation need to then tell John's drop list that it's OK to
> drop unsigned mail? It doesn't. It can just publish an ADSP
> record and be done with it. No need to count on some unreliable,
> unaccountable point of failure to mediate t
17 matches
Mail list logo
