sessment
of the issue.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
- Original Message -
From: "Stephen Farrell" <[EMAIL PROTECTED]>
To: "Jim Fenton" <[EMAIL PROTECTED]>
Cc: "IETF-DKIM"
Sent: Tuesday, January 31, 2006
On Jan 31, 2006, at 4:07 PM, J.D. Falk wrote:
On 2006-01-31 15:20, Douglas Otis wrote:
2. the "spammers have co-opted DomainKeys wtf omg" story was
last year:
http://www.eweek.com/article2/0,1759,1732576,00.asp?
kc=EWNKT0209KTX1K0100440
Re #2, the sky has not yet fallen.
By the same toke
On 2006-01-31 15:20, Douglas Otis wrote:
2. the "spammers have co-opted DomainKeys wtf omg" story was last
year:
http://www.eweek.com/article2/0,1759,1732576,00.asp?
kc=EWNKT0209KTX1K0100440
Re #2, the sky has not yet fallen.
By the same token, this story points out that basing reputations
On Jan 31, 2006, at 2:51 PM, J.D. Falk wrote:
On 2006-01-31 08:30, [EMAIL PROTECTED] wrote:
If I do not publish any key records and a bad actor whips up an
email purported to be from me with a fake signature attached, a
non dkim compliant mta may have a rule that states "signed
messages
On 2006-01-31 08:30, [EMAIL PROTECTED] wrote:
If I do not publish any key records and a bad actor whips up an email
purported to be from me with a fake signature attached, a non dkim
compliant mta may have a rule that states "signed messages are probably
okay" that might bypass some spam checkin
On 2006-01-31 10:09, Dave Crocker wrote:
The non dkim compliant mta who hasn't deployed dkim yet or knowing much
about it places a rule stating that signed messages should be allowed to
travel inbound without further checking because dkim is new and safe.
non-dkim compliant, but nonetheless ma
On Jan 31, 2006, at 9:59 AM, <[EMAIL PROTECTED]> wrote:
Sorry,
Should have been clearer.
Bad guy sends a message purportedly from cox.com with a header
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=cox.com
The non dkim compliant mta who hasn't deployed dkim yet or knowing
muc
The non dkim compliant mta who hasn't deployed dkim yet or knowing much
about it places a rule stating that signed messages should be allowed to
travel inbound without further checking because dkim is new and safe.
non-dkim compliant, but nonetheless makes a policy decision based on the
pres
> A dkim compliant mta will do a dip on my dns records and find no ssp
or
> dk record and drop the message as non compliant.
>if the signature succeeds, why do they need to check ssp?
I was making an assumption that if it's the first time cox.com has hit
that mta they would get the values for bot
-dkim] New Issue: 4.2 needs new Attack Item:
InconsistentSignature vs Policy Attacks
Bill,
[EMAIL PROTECTED] wrote:
> The hacker does not need access to my zone, he just attaches a
lookalike
> header yes " And to have *any* rule that allows bypass of defense
> based upon the recei
[ietf-dkim] New Issue: 4.2 needs new Attack Item:
InconsistentSignature vs Policy Attacks
[EMAIL PROTECTED] wrote:
> If I do not publish any key records and a bad actor whips up an email
> purported to be from me with a fake signature attached, a non dkim
> compliant mta may have a rule
Bill,
[EMAIL PROTECTED] wrote:
The hacker does not need access to my zone, he just attaches a lookalike
header yes " And to have *any* rule that allows bypass of defense
based upon the receipt of a header from outside your control is
extremely dangerous." But folks will do it anyway
By "look
[EMAIL PROTECTED] wrote:
If I do not publish any key records and a bad actor whips up an email
purported to be from me with a fake signature attached, a non dkim
compliant mta may have a rule that states "signed messages are probably
okay" that might bypass some spam checking software. Before DKI
>If I do not publish any key records and a bad actor whips up an email
>purported to be from me with a fake signature attached, a non dkim
>compliant mta may have a rule that states "signed messages are probably
>okay" that might bypass some spam checking software. Before DKIM is
>fully adopted/dep
> Direct attacks would be bad actor attempts to exploit compliant
DKIM/SSP
> systems. Indirect attacks would be bad actors attempts to exploit
> non-compliant DKIM/SSP and rely in "social engineering" exploits.
With
> indirect attacks, bad actors will not emphasize on protocol
correctness.
>
> Thes
- Original Message -
From: "Dave Crocker" <[EMAIL PROTECTED]>
> Can someone clarify how this is within scope for the
> current deliverable?
Hm,
Dave, as requested by Jim and Stephen, I racked my brains trying to mold
this NEW ISSUE entry in the best possible manner that would cater
- Original Message -
From: "william(at)elan.net" <[EMAIL PROTECTED]>
> SSP is ability to indicate policy for email address, i.e. when you see
> address in from you can check to find if emails from that address are
> supposed to be signed. If you only check policy record when you see a
> s
17 matches
Mail list logo
