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 7/23/2012 8:20 AM, Murray S. Kucherawy wrote:
On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker d...@dcrocker.net
mailto:d...@dcrocker.net wrote:
Here are two small tweaks that might correct things:
y This domain is testing DKIM. Verifiers MUST NOT treat
messages
That customer brought up an interesting point. t=y could also be useful
for messages whose signatures do verify. Specifically, it could be used by
a signer to say It's possible this message shouldn't have been signed by
us. Please don't give it any preferential treatment based on our name's
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
But more to the point, it seems that this isn't a specific we're
testing our system issue, but a separate issue related to reputation:
Do not use signatures made with this key as input to your evaluation
of our reputation. It would seem best to propose a new tag, in a
DKIM extension, for
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 7/21/2012 9:50 PM, Murray S. Kucherawy wrote:
That customer brought up an interesting point. t=y could also be
useful for messages whose signatures do verify. Specifically, it could
be used by a signer to say It's possible this message shouldn't have
been signed by us. Please don't
On 07/23/2012 06:47 AM, Murray S. Kucherawy wrote:
On Mon, Jul 23, 2012 at 6:42 AM, Michael Thomas m...@mtcc.com
mailto: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
On 07/23/2012 06:13 AM, Barry Leiba wrote:
That customer brought up an interesting point. t=y could also be useful
for messages whose signatures do verify. Specifically, it could be used by
a signer to say It's possible this message shouldn't have been signed by
us. Please don't give it
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
Murray S. Kucherawy wrote:
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
Barry Leiba wrote:
That said, I'm inclined to agree with Mike T that input from the
reputation target is suspicious, so it's not clear how much value it
will have nor whether it might be gamed (by the reputation target) or
hacked (by someone wanting to hurt the target's reputation).
It
I've opened a ticket to arrange that t=y suppresses any positive impact
domain reputation has in the next version of OpenDKIM, as an experiment.
I'm inclined to leave well enough alone. That wouldn't have been an
unreasonable interpretation six years ago when DKIM was new, but this is
the
Murray S. Kucherawy wrote:
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
John R. Levine wrote:
I've opened a ticket to arrange that t=y suppresses any positive impact
domain reputation has in the next version of OpenDKIM, as an experiment.
I'm inclined to leave well enough alone. That wouldn't have been an
unreasonable interpretation six years ago when DKIM was
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
17 matches
Mail list logo
