Jiankang Yao:
Is there any RFC which deals with EAI DKIM ?
how to deal with EAI message in the DKIM?
Do we have a decision about it?
According to RFC 6530, in-transit downgrading of messages (described
in detail in RFC 5504) is eliminated from EAI. Downgrading to an
ASCII-only form may occur
Rolf E. Sonneveld:
On 06/20/2013 03:05 AM, John R. Levine wrote:
Now on the other hand, if an administrative domain wanted to go to the
trouble to authenticate down to the user level, we didn't want to prevent
that, either. The primary audience for DKIM includes regulated industries,
On 06/20/2013 03:05 AM, John R. Levine wrote:
Seems to me that works fine as is. If a stock broker wants to set
up its mail system to put an i= into DKIM that reliably identifies
the person who sent the mail, they can do that.
But unless I have external knowledge that they do that, and trust
John Levine:
Another way is to have a dkim tag that specify the header that
indicates the stream classification
Many ways to kill the same bird.
If there is a reason why people aren't able to use a d= domain per
stream, I wish someone would explain in simple terms that even a
dimwit like
John Levine:
2. Advice about wildcards in TXT records.
Proposed change: Add a note in section 6.1.2 warning about the effect
of wildcard TXT records on finding DKIM key records.
Section 3.6.2.1 currently says:
INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g.,
John R. Levine:
The new docs willuse the CORRECTED rfc4871bis text.
Considering how far along we are with rfc4871bis, and keeping mind mind
the objections from Jim and others, my inclination would be to finish and
publish rfc4871bis as a standalone document, and after that do the
Ian Eiloart:
Unless the intermediary co-operates by re-signing, mailing lists can break
DKIM signatures. Since mailing lists generally use their own rfc5321 return
paths, SPF failures should not result. Of course, a broken DKIM signature
is equivalent to none at all. You should not reject
Mark Delany:
My problem is that if some valuable domain like paypal sends me a
bunch of bits that I or my MUA or my MTA ties to paypal.com then the
end goal of DKIM is, IMO, that those bunch of bits I see are the
ones that paypal sent. No more, no less.
But the user does not see a bunch of
Mark Delany:
But the user does not see a bunch of bits. The user sees the combined
result of software layers that render those bits. DKIM has no
control over that rendering process.
Really? Do you mean doesn't or shouldn't or can't?
Does DKIM control text-to-voice conversion, or
MH Michael Hammer (5304):
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com
Sent: Friday, October 15, 2010 11:59 AM
To: dcroc...@bbiw.net
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim]
Charles Lindsey:
On Fri, 08 Oct 2010 18:25:40 +0100, Wietse Venema wie...@porcupine.org
wrote:
If I understand things correctly, the solution is already available
in DKIM today. It involves signer configuration (sign for N+1
instances of each header that is covered by the signature
Charles Lindsey:
When the bad guy sends mail with (multiple) forged headers, the
best they can get is that naive mail programs render their forged
header with an indication that THE BAD GUY'S DKIM SIGNATURE VERIFIED.
Sending forged headers with bad guy's DKIM signatures is not an
John R. Levine:
a) Author creates a 100% compliant message
b) Signer signs 100% compliant message
c) Bad guy adds an extra header, making it non-compliant, and
sends it to someone
...
Mike, I only have vague recollection of the h= trick anymore...
You list all the headers you sign in
Dave CROCKER:
On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote:
I'm still cringing at the layering violation of fixing in DKIM the fact
that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother
to enforce normative portions of that specification.
Is there precedent
If I understand things correctly, the solution is already available
in DKIM today. It involves signer configuration (sign for N+1
instances of each header that is covered by the signature) and
requires no change in protocol or semantics. It merely hardens the
DKIM signature and I see
Wietse:
What I describe would be a best practice application of DKIM
mechanisms that already exist.
Mail is signed as if there are N+1 instances of each header that
is covered by the DKIM signature. The verifier will then fail if
any such header is added after-the-fact.
With this, there
Mark Delany:
That this is not in 4871 seems to be mostly a WG assumption that
should be made explicit.
I think several of us thought it was in there, but on review it apparently
was indeed lost somewhere along the way. We've certainly, as I understand
it, been proceeding from
Alessandro Vesely:
On 23/Sep/10 21:16, John R. Levine wrote:
All of this emphasis on complex designs for MLMs strikes me as a waste
of time, since it's a tiny corner of the mail space that has not
historically been a vector for abuse, and shows no sign of becoming one.
That's why my
Scott Kitterman:
On Wednesday, September 01, 2010 05:18:02 am John Levine wrote:
ANNEX A - MUA Considerations
Is a draft about mailing lists the right place to make recommendations
to MUA developers? Seems like those should probably be in a separate
document.
No, but the entire
Hector Santos:
IMO, it is these statements that continues to raise confusion and
raise the barrier of industry wide adoption that includes the general
population of MTA developers and operators from tiny to small to even
large.
As a part-time MTA developer I am not confused. The DKIM
Should the MLM draft suggest From: replacement and addition of Reply-
To: as a specific example of DKIM-friendly MLM behavior?
No. DKIM doesn't really say much about either the From: address or the
Reply-To: address, so such a suggestion for DKIM-friendly behaviour
would be
John Levine:
YES to 1, 7, 8. NO to everything else.
(I.e., do find out what people are doing, do not invent new unlikely
to be used mechanisms. Not opposed to 9, but seems contingent on 7
and 8 happening first.)
+1. No new features before we have real-world experience.
Wietse
Michael Deutschmann:
If this is indeed the official semantics of the protocol, then I would
petition to add a dkim=except-mlist policy. Which means I sign
everything that leaves my bailiwick, but may post to signature-breaking
MLs.
Are you going to announce all your users mailing list
Dave CROCKER:
Proposed text:
tThis currently leaves signers and assessors with the potential for
making different interpretations between the two identifiers and may
lead to interoperability problems. A signer could intend one to be
used for reputation, and
Siegel, Ellen:
Eliot Lear wrote:
The basic question is simply this: is it sufficient to list the key
algorithm in the header? I don't see a plausible attack, so I'm okay
+1
+1
with that. But let's at least have the debate based on facts.
yup.
+1
+1
Charles Lindsey:
On Mon, 01 Jun 2009 15:49:28 +0100, Barry Leiba barryle...@computer.org
wrote:
I think it's a terrible idea to (1) leave signatures in a message
after you break them, (2) add A-R without removing any already there,
or (3) add A-R without a signature covering it.
And
Dave CROCKER:
Let's make sure everyone is in synch about what is being proposed:
The suggestion is to drop a tag from the *DNS record*, /not/
from the *DKIM-Signature* header field.
What is the benefit of having the DNS record list possible
algorithms?
A protocol like this
J.D. Falk:
J.D. Falk wrote:
MailMan is covered, though
[ . . . ]
(This message will be signed, too, with a different key on the same box.)
Even better! The MIPAssoc server (also running MailMan) swapped my
signature for Authentication-Results, and signed the new message.
Michael Thomas:
I just don't get it. It seems to me that people who are advocating
changing the spec are doing it in a complete vacuum of the wide
deployment out there. Is DKIM broken? Manifestly not even a little
which is quite remarkable.
Every single suggestion has been debated in the
Hector Santos:
Wietse Venema wrote:
signed and invalid
unsigned
This distinction helps the bad guys/gals, and hurts the good guys/gals.
Thats an opinion and not one based on any engineering proof.
The fact is, the value of DKIM will be realized on anonymous
John Levine:
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.
I'm with Steve, I'd like to deprecate the useless stuff.
I too am in favor of less complexity. We could start by
keeping only
Jim Fenton:
Barry Leiba wrote:
This discussion seems to have settled down, but I don't see a clear
consensus on it. Let's take a little poll, then, on this thread. No
further discussion, for now, just the poll, and please don't assume
that silence means anything.
Post to this
Charles Lindsey:
From: some...@foo.exampleFrom:some...@foo.example
Valid signature from foo.example Absent/broken signature from foo.example
ACCEPT DISCARD
Right.
From some...@bar.example From some...@bar.example
Valid
Murray S. Kucherawy:
On Thu, 26 Mar 2009, Hector Santos wrote:
And as long as this mindset persist, you are going to get the funny
looks from many disciplines in this market - mainly SMTP vendors!
I represent an SMTP vendor, and I'm not sending funny looks. I'm pleased
with these
Florian Sager:
According to the mails below the RFC compliant change of content
encoding in MTA-forwarding may break signatures that follow the RFC 4871
recommendation to include header Content-Transfer-Encoding in the
signature. This header should be removed from section 5.5. Recommended
Wietse:
Unfortunately, this does not solve the problem. The 8bit-MIME to
7bit conversion as required(*) in RFC 1652 replaces the entire
message body, and therefore it invalidates DKIM signatures even
when the Content-Transfer-Encoding header is not signed.
Just like other MTAs that
John Levine:
7. RFC4871 Section 2.10 Agent or User Identifier (AUID)
Old:
A single, opaque value that identifies the agent or user on behalf
of whom the SDID has taken responsibility.
New:
A single domain name that identifies the agent or user on behalf
Dave CROCKER:
Is anyone /against/ using AUID?
d/
Suresh Ramasubramanian wrote:
On Thu, Mar 12, 2009 at 3:54 AM, Barry Leiba barryle...@computer.org
wrote:
Somewhat whimsically but wholly serious: Would simply changing the
acronym to AUID (for Agent or User IDentifier) avoid
John Levine:
I'm not sure what my opinion is on that last point, but on the first
point I think it's best to define an identifier that's specifically
for ADSP's use, if we want that function. Some signers may give that
tag the same value they give i=, and there's no harm done. Some
signers
Eliot Lear:
The question one has to ask is broader than inputs and outputs. Are
each of the protocol elements described in the specification clear
enough to be understood as to their meaning? If they are not then that
is what needs to be clarified. Regardless, this debate about
Stephen Farrell:
(a) The erratum I-D [1] is ready to go. Process it.
Motivation:
Adding tweaks to a confusing document does not remove the confusion
(you can consider this my variant of Brooks's law).
Confusion is removed by stating clear terms up-front, and by casting
the discussion into
Siegel, Ellen:
I for one would prefer a straight up +1/-1 vote on the errata draft as
it stands.
+1
I do agree that it would be a Good Thing to roll this and all the
other errata into a -bis spec draft, but think that it would be
better to nail down what we have as errata first
Jim Fenton:
I'd like to see if there is consensus for my proposal to remove the term
before suggesting specific language.
I suggest: you propose a concrete replacement, and if it is better,
then we adopt it.
Wietse
___
NOTE WELL: This list
Thiyaga:
Hi,
We recently decided to implement DKIM in our organization.
While reading through the RFC, I found a possible case, where the
authentication is lost. (Sorry if it is already discussed and a known
issue)
Scenario:
Let's assume a spammer wants to spam email accounts on
J D Falk:
On 20/09/2008 08:06, Dave CROCKER [EMAIL PROTECTED] wrote:
Stephen Farrell wrote:
It might be no harm if folks who do think ADSP should
go ahead would respond to this saying so.
+1
+1
+1.
Wietse
___
NOTE WELL:
Frank Ellermann:
The version in ssp-04 IMO misses the following wildcard TXT points:
(1) There is no explicitly specified way to identify an ADSP record,
when it comes as one of several TXT records in a q=txt reply.
In the terminology of an IAB draft ADSP defines no TXT subtype.
Note: The results from DNS queries that are
intended to validate a domain name unavoidably approximate
the set of Author Domains that can appear in legitimate email.
...
I'd like to suggest that we use a different word than approximate in
the above discussion and in the Levine draft.
...
I
modify
(clean up the definition of what is out-of-scope, clean up the
handling of out-of-scope domains).
Wietse
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Arvel Hathcock:
What do you feel are the technical deficiencies of draft-levine-dkim-adsp?
The biggest problem of course is that it's not a working group document.
If we're to start working now on other documents then Doug Otis is ahead
of you guys in line since he's had a replacement
MH Michael Hammer (5304):
Focusing on subdomains, I believe it may be useful for both senders and
checking receivers if a domain were to be able to assert whether it's
policy applies to all of it's subdomains. Given that we don't know how
receivers or reputation services might utilize such an
Delete. And bury six foot deep, so that it won't come out again.
Wietse
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
J D Falk:
Wietse wrote:
How would a receiver discover the top-level domain given example.com,
example.ac.uk, example.org.au, etc.?
The same way we do now: annoying, manually maintained case statements.
And who will provide updates to all the ADSP verifiers in the field?
Wietse
Jim Fenton:
Dave Crocker wrote:
J D Falk wrote:
Wietse wrote:
How would a receiver discover the top-level domain given example.com,
example.ac.uk, example.org.au, etc.?
The same way we do now: annoying, manually maintained case statements.
This relies
SM:
At 16:27 29-04-2008, Douglas Otis wrote:
Do you think there should be a statement indicating the ADSP lookup
procedure should not be done when there is a valid Author Domain
signature? Perhaps the receiving domain only validates DKIM
signatures when ADSP indicates Discardable. : )
My
Dave Crocker:
Arvel Hathcock wrote:
I propose that the side advocating removal of the NXDOMAIN check agree
to language which makes this step AT LEAST a SHOULD and preferably a MUST.
Having the ADSP specification include normative text that calls for
validating
the From field
John Levine:
I think I'm not the only one making assumptions here.
Of course not.
I'm honestly trying to figure out whether any mail systems treat mail
from sub.foo.com as being from foo.com when they make decisions about
sorting, filtering, and so forth. That's why I'd really appreciate
Wietse Venema wrote:
Frank Ellermann:
[EMAIL PROTECTED] wrote:
Would it be better if error were a specifically defined
result in addition to unknown / all / discardable?
The fourth bullet in chapter 3.2 ASP results offers the
domain does not exist after unknown/all/discardable.
I
a) DKIM is for declaring the presence of an accountable identity.
If a signature is present, you know something. If it is absent,
you know nothing extra.
b) ADSP attempts to tell you something, in the absence of a
signature. It does that by defining something else that must be
present.
Wietse Venema wrote:
a) DKIM is for declaring the presence of an accountable identity.
If a signature is present, you know something. If it is absent,
you know nothing extra.
b) ADSP attempts to tell you something, in the absence of a
signature. It does that by defining something else
Stephen Farrell:
Poll ends: April 3rd AoE (*)
Please mail the list with your preferences.
Tick the box for any of the name options you like.
You can pick more than one option.
If you change the subject line or mess with the
body of the mail, I may miss or miscount your
opinion, so don't
Frank Ellermann:
Dave Crocker wrote:
third-party can be confusing.
Later in the draft and after posting the issue I saw
non-author. That's also fine, but the interesting
case isn't an originating operator (that is still
end-to-end), but signatures by mediators.
And how would receivers
Michael Thomas:
Dave Crocker wrote:
Michael Thomas wrote:
It doesn't take much of a logic chain: the label first was _policy.
Then it was _ssp. Now it's _asp. Tomorrow it might be _frodo. Next day
something else. Each time you change it, implementations break in a
showstopper
Eric Allman:
Since we decided to change SSP to ASP to be more precise (thereby
breaking the existing implementations out there, which Dave seems to
think are irrelevant, Mike seems to think are critical, and I think
are somewhere in between), I'm in favor of making one more change (my
Douglas Otis:
The current assumption used when asserting DKIM policy is that this
policy might apply across _all_ protocols used to carry messages that
might contain DKIM signatures. Either DKIM policy records need to
declare the scope of the protocols covered by the policy, or the
Wietse Venema:
Douglas Otis:
The current assumption used when asserting DKIM policy is that this
policy might apply across _all_ protocols used to carry messages that
might contain DKIM signatures. Either DKIM policy records need to
declare the scope of the protocols covered
Dave Crocker:
The practices that SSP describe are specific to the RFC2822 From:
header field, which defines the author of a message. It does not
seek to describe practices of other agents in email handling.
As such, the name of the specification should reflect its precise
scope. The
Hallam-Baker, Phillip:
[ Charset ISO-8859-1 unsupported, converting... ]
My problem here is that Phill Hallam-Baker is the Author of this
email but verisign.com would be the signer.
I would be somewhat nervous about making the assertion that a
domain is the author of a message. That might
Frank Ellermann:
From my POV discardable is worse. Above all receivers have
to follow 2821bis. SSP does not guarantee that discardable
mails match what is specified in 2821bis section 6.2.
One possible deployment of ASP would work like this:
- Have the MTA/Verifier tag discardable mail with
Douglas Otis:
To better ensure the minimum number of DNS transactions occur while
processing DNS SSP and key TXT records, especially for domains that do
not implement email, the SSP draft should mandate publishing MX
records whenever an SSP record is also published. Since the SSP
Michael Thomas:
Eliot Lear wrote:
Wietse Venema wrote:
You do what you want to do.
I would hope that receivers don't discard mail simply because the
domain owner says so. Instead, I would hope that their hint goes
into a weighting process together with other indicators.
Ain't
MH Michael Hammer (5304):
If a domain chooses to sign DKIM with respect to a From field email
address that purports to be from that domain and that domain has the
ability to make an assertion (of any sort) through SSP with regard to
it's practices:
Is the potential benefit afforded a
Steve Atkins:
My original observation was that discardable was a reasonable term
for mail for which the sender prefer the recipient not deliver a small
fraction of legitimate email and a small fraction of non-legitimate
email rather than deliver either.
There was an assertion made
MH Michael Hammer (5304):
Is the potential benefit afforded a receiver by checking that SSP
assertion AND taking whatever (unspecified) action worth the effort
of doing so? If receivers are likely to have little or no
benefit/interest in checking SSP then the rest of the discussion
is moot.
Michael Thomas:
Wietse Venema wrote:
MH Michael Hammer (5304):
Is DKIM checking sufficient in itself without SSP? How might DKIM-SSP
help receivers (the 3 aforementioned as well as others) leverage their
evaluation of received email whether signed (valid or not) or unsigned?
known
Hector Santos:
Dave,
Is it fair to conclude that you no longer feel it is necessary to do a
Security Threat Analysis?
Unfortunately, I know you are not going to respond, so I want to put in
F.Y.I. Text is being drafted, but you will have to wait until it is ready.
Wietse
In my opinion, as one of the authors listed on the ASP draft, SSP-02
is close enough in spirit to ASP that I could live with either.
The protocol is extensible. Let's gain experience with this basic
protocol and let experience teach us where extensions will be useful.
Wietse
Frank Ellermann:
John L wrote:
This is the exact problem for PRA in the SIDF implementation.
Quite right. What would be the point in inventing yet another
authentication scheme that fails in all the same places that
SIDF and SPF do?
SPF has no problem with non-standard mailing
Dave Crocker:
Stephen Farrell wrote:
1521Limit the application of SSP to unsigned messagesnew dkim
Nobody0 [EMAIL PROTECTED]9 days ago9 days ago0
Proposal: REJECT, but some wording changes may be needed for the next
rev, thread is [4] I mainly saw
Arvel Hathcock:
I would take this further: remove all text that says when to apply
SSP. Instead, provide text that states the contribution that SSP
can make under different conditions: mail with valid first-party
signature, mail with valid third-party signature, and mail without
valid
Jim Fenton:
Arvel Hathcock wrote:
I would take this further: remove all text that says when to apply
SSP. Instead, provide text that states the contribution that SSP
can make under different conditions: mail with valid first-party
signature, mail with valid third-party signature, and
Arvel Hathcock:
No worries. The proposed change is to focus the benefits that SSP
can provide in scenarios as outlined above, not to discourage the
deployment of SSP.
Could there be broader agreement on an SSP specification that lays out
how to do an SSP lookup but doesn't rigidly
For the record, one minor correction for sloppy language.
Wietse
Wietse Venema:
Arvel Hathcock:
No worries. The proposed change is to focus the benefits that SSP
can provide in scenarios as outlined above, not to discourage the
deployment of SSP.
Could there be broader
Is no signature equivalent to a bad signature?
Is a bad signature the result of malice or accident?
Some don't distinguish between these cases, arguing that favoring
bad signatures over no signatures only encourages criminals to send
mail with bad signatures. For example:
Doug Otis:
This
Steve Atkins:
On Dec 16, 2007, at 9:10 AM, Dave Crocker wrote:
Jon Callas wrote:
Dave Crocker wrote:
With the use of language like suspicious, SSP is making value
judgement on messages that do not satisfy SSP's criteria, even
though those message well might be entirely
Damon:
SSP does not help me decide which bank is real.
Again, I know who my bank is. If I get a message from BoA or a message
from the First Mountain Trust of Namibia, I believe I would not have
any trouble distinguishing between the two.
I don't expect burglars to put WARNING: BURGLARY IN
I don't think SSP is hostile to the DKIM deployment, but helps its
deployment because it will at least provide some avenue of protection
for domains and receivers who don't wish to get into 3rd Party Trust
Service dependencies where there is no standard definition and
absolutely no
Scott Kitterman:
On Sunday 09 December 2007 10:07, Wietse Venema wrote:
After yesterday's massive agreement, today I'll expand some of my
statements with examples, and expose some limits.
Statement 1
With DKIM, The Signer Domain says I signed this mail. It does
not approve content
After yesterday's massive agreement, today I'll expand some of my
statements with examples, and expose some limits.
Statement 1
With DKIM, The Signer Domain says I signed this mail. It does
not approve content, or state that content is benign. The receiver
decides whether to give this
Hector Santos:
[ Charset ISO-8859-1 unsupported, converting... ]
Wietse Venema wrote:
Perhaps an analogy from a different but familiar world will help.
Consider DKIM or SSP as broadcast radio transmissions (or TV if
you must). The point is that it is a UNIDIRECTIONAL thing. The
sender
Hector Santos:
Overall, although I do have many comments about the SSP draft, there is
really just 1 thing that sticks out.
Section 4.4, item 3:
3. The Verifier MUST query DNS for an MX record corresponding to
the Originator Domain (with no prefix). This query is made only
]
[mailto:[EMAIL PROTECTED] On Behalf Of Wietse Venema
Sent: Friday, June 08, 2007 6:19 AM
To: Hector Santos
Cc: IETF DKIM WG
Subject: Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
Hector Santos:
I don't expect mail from this domain - kill it, don't
tag
Hector Santos:
I don't expect mail from this domain - kill it, don't
tag it or mark it as bad for user's to see, kill it,
don't pass it on. Its not ours! - If you do, it is
no longer our responsibility as DKIM-BASE suggest it
is.
Enough is enough.
I
Issue#1: +1 - include use of XPTR as part of ssp-00
Issue#1: -1 - exclude use of XPTR from ssp-00
+1
Issue#2: +1 - Define how to use a TXT RR for SSP policies (with or
without something else)
Issue#2: -1 - Don't use TXT at all, only use new RRs for SSP
+1
Like many I was asked to for comments on DKIM after the RFC was
announced. Below is my simplified, mostly correct, summary.
Feel free to copy, modify, or distribute.
Wietse
What DKIM is
DKIM (domain keys identified mail) is email authentication technology,
developed in an IETF
Hector Santos:
This is exactly the same problem that the industry evolved to over the
past two decades and what has brought us together here. The problem is
dealing with the legacy market of old SMTP systems and how the bad guys
use this to gain entry into systems. If that wasn't the
Tony Hansen:
However, I'd like to hear some discussion on the issue: Should we put
out a version now (without the SSP references), or hold off until SSP is
totally finished?
I would not wait with an Overview document until SSP is ready for
prime time. I would encourage deployment of DKIM-base
Charles Lindsey:
On Thu, 01 Mar 2007 13:44:21 -, Wietse Venema [EMAIL PROTECTED]
wrote:
On a friendly internet with only cooperating parties, this might
make sense. But the world has changed. With today's internet it
would be a fundamental mistake to make more distinctions than
Charles Lindsey:
On Wed, 28 Feb 2007 13:21:55 -, Hector Santos [EMAIL PROTECTED]
wrote:
There are three basic outcomes with a message:
VALID SIGNATURE
INVALID SIGNATURE
NO SIGNATURE
No, there are four basic outcomes with a message. You omitted
Hector Santos:
Wietse Venema wrote:
If the verifier gives different treatments to different types of
other, then the bad guys will exploit the verifier's behavior.
Applying equal treatment should be done across the board, the valid and
invalid, not just for the so called elite messages
John Levine:
From my perspective having a message have a valid signature with one
implementation and having a broken signature with another is an
incompatibility. I don't think that's speculation. ...
No, it merely reflects a difference of opinion by the sites concerned as
to what
1 - 100 of 146 matches
Mail list logo
