Again, please don't CC me. I'm subscribed to the list.
Stephen Farrell wrote:
> On 05/10/10 23:54, Julian Mehnle wrote:
> > Recommending that one more "From" be added to h= (and hashed)
> > than From headers are initially placed in the message should be
>
Hector Santos wrote:
> Right. Does this add "signer" reputation weight for the injected
> 5322.From?
Probably not. AFAICT mipassoc.org doesn't verify DKIM sigs on list
messages, and even if it did, a verified DKIM sig (such as one created by
the original author of the message) doesn't tell any
President Obama wrote:
> [...]
Funny, but this shows nothing because mipassoc.org resigns messages
(d=mipassoc.org). (Oh, and it even included *two* "From"s in h= on your
message.)
> I propose the following addition text by adding to 48721bis to address
> this serious issue;
>
>Special Co
Hector Santos wrote:
> Julian Mehnle wrote:
>
> > I interpret RFC 4871, section 5.4 (actually, exactly the part you
> > quoted originally), such that signing a message that has a dingle
> > From field with h=From:From ensures that adding another From field
> >
Please don't CC me. I'm subscribed to the list.
Hector Santos wrote:
> Julian Mehnle wrote:
>
> > The trick is to list From twice in h=. This ensures more From headers
> > cannot be added without breaking the signature.
>
> Julian, this was explored and
Murray S. Kucherawy wrote:
> But the attacker in this scenario is already the signer (or has
> compromised the signer), so he/she will just sign the single From:.
If the attacker is the signer, they can just as well resign many times.
I don't think that's the scenario that Hector meant, though.
Hector Santos wrote:
> It has been observed by implementations that is it possible to replay
> a message with a 2nd 5322.From header at the top which wouldn't break
> the DKIM signature validity, but would often be displayed by MUAs to
> display the new 5322.From display rather than the signature
Julian Mehnle wrote:
> [...] there are indeed other ways for DNS-traffic-based DoS attacks that
> are just as suitable as, if not more than, SPF:
>
> http://www.openspf.org/auth/draft-otis-spf-dos-exploit_Analysis#rebuttal
Er, that was supposed to read
http://www.openspf.org/draft-
Douglas Otis wrote:
> On Dec 30, 2007, at 7:15 PM, Frank Ellermann wrote:
> > Nobody proposed to use SPF to "validate a DKIM domain in some
> > manner". SPF validates envelope sender addresses, it allows "accept
> > and bounce" after a PASS. SPF is for SMTP, not for DKIM. If you
> > reject a SSP
