tation calls for. i.e. find out more about the host system it is
about to send a "valuable" mail to.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ble).
Additional text along the following thought process SHOULD|MUST be needed:
Validators are not obligated to honor this signer reporting tag,
nor obligated to send reports to the signing domain.
Maybe adding one sentence or short paragraph explaining the security
reasons.
messages.
If people think SHA-256 is vulnerable, then we need to be ready for
additional methods.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Z headers match the H headers but contains
the values used for hashing.
---
Hector
- Original Message -----
From: "Hector Santos" <[EMAIL PROTECTED]>
To: "IETF-DKIM"
Sent: Thursday, February 23, 2006 1:01 AM
Subject: [ietf-dkim] signature h= and z= tags
> I nee
has direct effect on the original common Online Hosting Definitions:
AUTHOR
OPERATOR
And an indirect effect with transport systems, if any, per RFC definition:
ORIGINATOR
SENDER
There you go, all three spectrums.
--
Hector Santos, Santronics Software, Inc.
http
This is all depends on the binding of the headers.
If the FROM: field is bounded to the signature, than it is 100% indeed tied
to the author of the message.
If the FROM: field is not bound to the signature, then it is more like you
say.
--
Hector Santos, Santronics Software, Inc.
http
ER" to refer to the CLIENT/AUTHOR
of the message if that the connotation you are referring too. A MAILER is
"SOFTWARE" and more associated with the the transport/frontend system.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
[1] From CAN-SPAM:
(16) SENDER.-
(A)
he type of "mechanical" engineering that
keeps me interested.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
- Original Message -
From: "Barry Leiba" <[EMAIL PROTECTED]>
To: "DKIM IETF WG"
Sent: Friday, March 10, 2006 11:45 PM
Subje
o. It is issue
regarding more changes to software. If thats a barrier, then thats another
issue. But it isn't complex in my opinion.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
[1] http://www.sympa.org/wiki/doku.php?id=dkim_and_mailing
do so
in appropriate manner to minimize impact. A domain can not expect a
signature that is most often found to be abused (broken) most of the time,
to be viewed with trust the few times it is found to be successfully
validated.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
---
Sounds we can just toss DKIM aside and wait until this new reputation
trust-layer in introduced (or re-introduced). But this can be done
independently anyway, so I am lost as too why DKIM is needed in the first
place?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
choice
but to provide a relaxed domain to him, even if they honors SSP or not.
PS: I am willing to write a DRAFT I-D For "List Server DKIM Support
Recommendations." Is that still desirable?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_
er" for the Operator group, I
would suggest you throw in the term "Provider" in the User group.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
s support operations to increase the
confidence of the system. By promoting the idea that these bad messages
should be viewed as "No Signatures" messages, I can't help but seeing a
"cry wolf" syndrome to occur. We already see this now with mangled listed
mail. We ac
stions.
PS: To the "necessary folks", ignoring these concerns is in my view
negligent of the engineering process. Don't be surprise of the "future
critics" when the issues were pointed out now and you opted to ignore the
messenger now in attempt to promote negative consensus a
Thanks for going back on-list.
- Original Message -
From: "Hector Santos" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 17, 2006 3:55 PM
Subject: Re: [ietf-dkim] New Issue: Analyzing Failures: List of Possible
Reasons
Why go off list Bill? :-)
- SSP processing offers short circuiting of remaining
processing overhead
- HASH-HDR processing offers short circuiting of remaining
processing overhead
and so on.
So think of the verifiers. Signing is the easiest part.
Get it right. The cost will be much higher later cleaning up the "me
Oy vey! Urghh! Correction! I meant there is "no doubt" in my mind.
- Original Message -
From: "Hector Santos" <[EMAIL PROTECTED]>
> Current model:
>
> TCO(DKIM1) = TCO(HASH-BODY)+ TCO(HASH-HDR) + TCO(SSP)
>
> The order of the pro
- Original Message -
From: "Eric Allman" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
>> Current model:
>>
>> TCO(DKIM1) = TCO(HASH-BODY)+ TCO(HASH-HDR) + TCO(SSP)
>>
>> The order of the processing above
ifferently. But it's not impossible, as has been described.
>
> In short, I'm in favor of this change.
>
> Or perhaps I should have just said "me too".
Ditto.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ual storage files, or
2) A smart MTA that performs template macro substitution dynamically
at the SMTP session.
Most models exist, DKIM caters to #1. #2 will require DKIM hashing at the
SMTP stage.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
__
oint over what how
we expect to use it. If it isn't require to be honored than what's the
point?
That said, I think ideas like DDDS and similar concepts is a step in the
right direction. SSP will offer ways to resolve so many issues of
"expectation" in a highly chaotic wo
ge Signing Profile
This keeps the door open to exposing more information about the SIGNER and
not just SENDER.
I like Profile because that is more accurate to what a vendor might help
prepare for operators when setting up DKIM. He is setting up a DKIM Message
Signing Profile.
--
Hector Santos,
address such PAYLOAD based protocols. This
1193 BodyHash proposal will fit exactly with what I expecting in my
proposal:
http://isdg.net/public/ietf/drafts/draft-santos-smtphead-00.html
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
d-DKIM, can anyone
explain to me why BAD actors will avoid the non-standard version?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
- Original Message -
From: "Barry Leiba" <[EMAIL PROTECTED]>
To:
Sent: Friday, March 24, 2006 6:54 PM
Subject: Re: [
ote:
>> Another possibility is "Preferences" maybe?
> I'd prefer a word that is descriptive of what the signer does, rather
> than making a request of the recipient.
I don't understand the last part of this sentence? Can you elaborate?
How about?
DSD - Dom
IM proposal in flux that
it would have a detrimental effect on the network once a better STD DKIM
emerges?
I don't think anyone can answer YES to that with a straight face.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
on't even
remember it (relaxed) even being discussed in the list - the change just
appeared out of thin air when the current proposal was released.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
g with TXT
(besides its obvious simplicity).
Is this correct? If so, it is important?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
. I see no negatives whatsoever thus I didn't agree with Mikes
plus/minus itemized list.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
bother to talking about RR and requiring specific Windows versions
if
it is going to cause problems with allman-01?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://
n we can't even get over the hump with Mike's compatibility
concerns. :-) Doesn't make sense.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
- Original Message -
From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]>
> The statement made
Follow the MARID May/2004 "Wild Card MXes" Thread at:
http://www.mhonarc.org/archive/html/ietf-mxcomp/2004-05/msg00504.html
http://www.mhonarc.org/archive/html/ietf-mxcomp/2004-05/msg00461.html
Bob Atkinson seems to explain in detail.
---
Hector
- Original Message -
From: "Tony Hansen"
- Original Message -
From: "DKIM Chair" <[EMAIL PROTECTED]>
To: "DKIM Mailing List"
Sent: Tuesday, March 28, 2006 9:08 AM
Subject: Re: [ietf-dkim] Draft DKIM minutes from IETF65
> Audio archive:
>
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf65/ietf65monch2.mp3.
1
>
http://li
peoples input and
discussions, providing the synergism for a courageous person to make the
proposal official. So it wasn't just made up, Mike.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
uld you consider
this to be too much overhead, making it impractical to expect clients to
operate in this mode?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ignore DKIM, putt on the idea of dealing with adding new signatures,
and if they break the integrity, the blame is no longer on the middleware
but on the domain owner for allowing risky mail to be put thru their system.
That's my input on this.
--
Hector Santos, Santronics Software, Inc.
ht
pening if its going
to make the whole DKIM issue easier to a) adopt, b) program and c) remove
liability and support responsibilities of the list owners.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ike Dave believe it should be, yet no semantics and
rules applies, then how can you assign responsibility? You need some kind
of interpretation if you wish to assign responsibility.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
at resolves many of the current
signing questions.
See
http://www.winserver.com/public/ssp/ssp.htm
Hopefully this will make some sense.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
oftware and I don't see any common sense
in the current suggestions. I see more harm than good. I am wrong, please
sure how DKIM is safe without SSP. Please sure how you can in a much
clearer and clean matter resolve all these questions without SSP.
--
Hector Santos, Santronics Software,
nflicts and failures.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
- Original Message -
From: "Dave Crocker" <[EMAIL PROTECTED]>
To: "Barry Leiba" <[EMAIL PROTECTED]>
Cc: "Eric Allman" <[EMAIL PROTECTED]>;
Sent: Monday, Apr
is your public central server. The idea is that the bad guy
does not have WRITE/DELETE access to your DNS KEYS. It has only READ
ACCESS. Having WRITE/DELETE acess would be a protocol flaw or threat.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
high degree of failure. Verifiers should consider a
tracking mechanism to limit the long term continued
usage of the t=y flag to bypass any verification scoring
and filtering employed by local policy.
--
Hector Santos, Santronics Software, Inc.
http://www.santronic
| 1. Terminology and Model
|
| ...
|
| DKIM operates entirely on the content (body and selected header
| fields) of the message, as defined in RFC 2822 [RFC2822]. The
| transmission of messages via SMTP, defined in RFC 2821 [RFC2821], and
| such elements as the envelope-from and envelope
protocols
other than SMTP, such as IMAP [RFC3501], HTTP [???], including
during the mail pickup process with POP, IMAP as well
at the MUA endpoint acting as a verifier.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
ill have some standard "header" (Authorization-Result:) that the
reader can use to extract and resent verification results.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
27;t get to them in the normal 20 minutes and declare the
> signature dead.
The x=tag is the less of DKIM worries. See the t=y tag:
// Local Policy:
// - Watch for Perpetual Testing (t=y) Abusers
// - 6 months Default
if (IsTesting() && TestingDays() > LocalPolicy.MaxTes
mplish that,
then maybe it doesn't have any value.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
have a MSG.POSTTIME field So if we
have add or a 3rd party developer adds a MUA based verifier, it would be
faster to get this time rather than read the Received line. Small
distinction, probably not even worth mentioning.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
xpiration descriptor will fall in line with the going on
philosophy.
Any who, I think it is useful. Whether how useful it is for the signer, it
open to many interpretations based on what role you are playing.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ed change to
use the message reception time:
dynamic verification -> msg reception time = current time
delayed verification -> msg reception time = 2822.Received: time
This resolves the question on whether the expiration tag may be used to
invalidate an already stored message based on th
Keep "x="
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
- Original Message -
From: "Stephen Farrell" <[EMAIL PROTECTED]>
> So, if you care, please respond to this message, including the list,
> with one of:
>
> Get ri
ssoc.org/pipermail/ietf-dkim/2006q2/003134.html
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
- Original Message -
From: "Mark Delany" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, April 11, 2006 11:45 PM
Subject: [ietf-dkim] Re: Straw poll on x=
> Remove x=
>
> The tagging mechanism makes it trivial to add new tags. If at some
> point in the future, x= is given a precise and purposefu
- Original Message -
From: "Eliot Lear" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
>> - Quickly disseminate the bad from the good,
>>
> Again, how? And I don't think you meant disseminate, but discriminate.
light prelude to what
> you'll see in SSP debates
Ha! You got that right!
Boy did you make my day. :-)
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ighlights, there are two cases here:
- Expired Valid Signature
- Expired Bad Signature
The current semantics excludes the validity of the signature and probably
this is because the semantic is associated with option (a) above.
---
Hector
- Original Message -
From: "Eli
ight need two things then:
- Some result header (Has this message been verified yet?)
- Specify that the Message Reception Time is the
time to use for expiration comparison.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
fine by me too. We just need to make sure that it is consistent
for both dynamic transport level verifiers and post transpost delayed
verifiers. For the post/delayed verifier, I think it needs to emulated the
dynamic verifier as must as possible.
--
Hector Santos, Sant
o apply to both equally,
otherwise you can run into fuzzy inconsistent operations and sure enough,
new legal issues as well, as you duly pointed out.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operat
at least seven days before being removed from the key
|server.
That basically means that x= must be used if there is planned event for
selector removal within 7 days.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
- Original Message -
From: "Douglas Otis" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
>> That basically means that x= must be used if there is a planned event
>> for selector removal within 7 days.
>
> When the transpo
, but in such a case, as long as the selector is
still active and p= data is empty, x= is not required. You got your
indicator.
I think I might change my vote to "Get Rid of X=" :-)
I still like the idea of expiring a signing on a per message basis. Pretty
powerful option for sig
pickup.
But the more you shift/delay your verification time, the more you get away
from the real time dynamics of the system and you have more potential
failure.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list
ay, hour, seconds, optional. Most
likely most expirations will be to the day or hour, so x=mmddhh would be
sufficient for most needs.
This will also be easier to read for diagnostics when eyeballing.
--
Hector Santos, Santronics Software, Inc
- Original Message -
From: "Douglas Otis" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
>> Unless it has help from the backend server, offline mail systems
>> will not work very reliably when keys are being changed.
>
rom the "s=" tag.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
M, as a payload solution, there will be operations in post
smtp modes too. So this needs to mentioned/addressed as well.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
Thats why I left it as Step Zero.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
- Original Message -
From: "Eliot Lear" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
> Hector,
>
> I'd claim this i
same thing.
Thanks
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
- Original Message -
From: "Eliot Lear" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
Cc: "IETF-DKIM" ; "Eric Allman" <[EMAIL PROTECTE
- Original Message -
From: "Douglas Otis" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
Cc: "IETF-DKIM"
Sent: Friday, April 14, 2006 12:26 PM
Subject: Re: [ietf-dkim] x= lets senders expire responsibility
> One simple soluti
pport SPF customers.
For DKIM, ISP/ESP who begin to offer signing services, free, fee-based or
otherwise will help the process. It will also depend a lot on vendors
and/or 3rd party developers making this near-complex implementation easier.
--
Hector Santos, Santronics Software, Inc.
http://ww
kups on
a regular basis. Delaying mail pickups over extended periods
(Weeks), can cause false positives with DKIM signed messages."
Or something like this. The vendor is aware of the situation and they will
make sure the USER will be aware of the situation as well.
--
Hector Sa
Transport, Delay Verification
c) Offline MUAs
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
o determine if a key is valid or not
is by performing the lookup. I don't think this would be desirable in a
wide-scale DKIM network.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates accor
you will have to address
all the issues with this deprecation, including the high potential for
failed DNS lookups. I failed to see why we would want to limit signers to
expose this important possible key 'event'. I see negatives. No positives
in it.
--
Hector Santos, Santronics Software,
ing the
| domain from the "d=" tag and the selector from the "s=" tag.
But then again, maybe I don't understand the "nit system" here which is a
high possibility.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_
you
don't have to do an DNS lookup, and the specs has an implicit semantics to
this effort, and the end results are the same whether you do or not, then
why enforce it?
Thanks
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
date.
+
| 1. Retrieve the public key as described in (Section 3.6) using the
| domain from the "d=" tag and the selector from the "s=" tag.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE W
ation. :-)
I don't believe we have a complex situation with the x=tag. You have the
same time-shifted issues with it or without it, but in my view, even more
issues are introduced without it.
If you don't think so, see section 6.2 step 2. Do you any rat-hole there?
:-)
Thanks
-
What exactly are we looking for here? What's the goal?
- Average User Mail Reception Time?
- Average POP3/IMAP Polling Time?
---
Hector
- Original Message -
From: "Lyndon Nerenberg" <[EMAIL PROTECTED]>
To: "Stephen Farrell" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, April 18, 2006 11:
ection 6.2 (now step 3).
[X] Allow for optimization consideration (No Verification Required).
[X] Remove Information Note about replay attacks. Considered or not,
DKIM can't control what the VERIFIER will experience and the
knowledge gain to address such issue
don't think this information notes is necessary. I think covered it with
the 3rd note.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
- Original Message -
From: "Paul Hoffman" <[EMAIL PROTECTED]>
> At 2:37 PM -0400 4/19/06, Hector Santos wrote:
>
> >>Verifiers SHOULD support checking of x= values.
> >
> >I think this must be a MUST. In my view, this is risking malpr
t; <[EMAIL PROTECTED]>
To:
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, April 19, 2006 6:22 PM
Subject: Re: [ietf-dkim] Attempted text for x=
> In article <[EMAIL PROTECTED]> you write:
> >At 2:37 PM -0400 4/19/06, Hector Santos wrote:
>
> Try i
and
the 451 recommendation is not something verifiers will just willing honor
across the board. That is definitely a candidate for local policy setting to
551. In short, the coding for the verifier might be:
NXDOMAIN, no tag, not expired ---> 451
NXDOMAIN, signature expired--
tries, so that
> messages with key retrieval problems are not rejected entirely.
Jim,
Wouldn't that create a loophole?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
h
er
Cox Communications, Inc.
Alpharetta GA
404-847-6397
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos
Sent: Thursday, April 20, 2006 2:07 AM
To: Stephen Farrell
Cc: ietf-dkim
Subject: Re: [ietf-dkim] Attempted text for
s. Whether it is the best way for one site to operate, that's a
different question.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
it is, we have no choice but to use the
2822.Received: time.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
erified as good, not today, but when it was used? There doesn't
> seem to be any added storage cost or processing cycles, since either
> way, you have to have the key to test it, just the question of which
> date to compare to.
Right. Defining the timestamp is important. I believe
- Original Message -
From: "Sandy Wills" <[EMAIL PROTECTED]>
> Hector Santos wrote:
>>
>> Right. Defining the timestamp is important. I believe it should be
>> generically described as the transaction reception time - the time
>> it arri
- Original Message -
From: "Michael Thomas" <[EMAIL PROTECTED]>
To: "DKIM Chair" <[EMAIL PROTECTED]>
> IMO, the problem here saying that MUA's can praticipate in
> verification is a large rathole.
+1. The standalone DKIM-ready MUA authors have all the information they
need (2822.Receive
- Original Message -
From: "John Levine" <[EMAIL PROTECTED]>
>> 2) MUST perform the verification within the "transport window",
>> typically 7 days.
>
> Sorry, no, we're back to a previous argument. If someone goes away
> for two weeks, and comes back and picks up his mail, his MUA is go
- Original Message -
From: "Paul Hoffman" <[EMAIL PROTECTED]>
> At 2:08 PM -0400 4/21/06, Hector Santos wrote:
> >Any MUA DKIM-Ready software using the current time is going to quickly
> >slammed and classified as buggy, broken software.
>
> You are f
- Original Message -
From: "Jim Fenton" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, April 21, 2006 8:56 PM
Subject: Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error
>>> This points out another problem: if a verif
a BCP will correct. If it was
that easy, to use incremental BCP documents to correct the design issues
that you knew existed, we wouldn't have these problems today. 20 years ago
I can understand. Not today, we have hundreds of thousands of man-years
here and we know enough to know what the issu
ys broken (or non-verifiable) in
step 2?
PS: The above step I wrote was basically something it should not say. I view
that as a loophole bad actors will exploit.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
NOTE
ware to purge the message from the system.
But while it is still alive and available, once you read it, at best, the
presentation software could or might be fancy enough to tell you that it has
already verified but now expired message.
Anyway, that's my view.
--
Hector Santos,
1 - 100 of 1554 matches
Mail list logo
