On Fri 09/Feb/2018 23:31:41 +0100 John R. Levine wrote:
>
> The DKIM v=2 hack I proposed is a lot like SMTP extensions in that if
> your signature doesn't need the new semantics, don't ask for them, so
> you should sign with v=1, so the old and new will coexist forever.
> Since they can easily be
On Thu 08/Feb/2018 19:23:09 +0100 Dave Crocker wrote:
> On 2/8/2018 10:05 AM, Pete Resnick wrote:
>>
>> RFC 7405 is also useful along these lines.
>
> If those modifications are used, sure. If not, not so much.
>
>
>> So, no error in 5322. As for the erratum below, not having ABNF for the
>>
Hi,
someone asked me about case sensitiveness of the header field name. I looked
for an ABNF in RFC6376, but only found examples and informative notes.
Is that an error worth being reported?
Ale
___
NOTE WELL: This list operates according to
On Wed 16/Nov/2016 21:12:45 +0100 Murray S. Kucherawy wrote:
On Thu, Nov 17, 2016 at 3:47 AM, Alessandro Vesely <ves...@tana.it> wrote:
That way it will stay dormant until someone gets hurt and has to activate
it, at which time it may cause more damage than improvement. A loose
On Wed 16/Nov/2016 14:00:26 +0100 Murray S. Kucherawy wrote:
On Wed, Nov 16, 2016 at 7:57 PM, Alessandro Vesely <ves...@tana.it> wrote:
That way it will stay dormant until someone gets hurt and has to activate
it, at which time it may cause more damage than improvement. A loose
On Wed 16/Nov/2016 03:28:08 +0100 Murray S. Kucherawy wrote:
On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink wrote:
Large email receivers forward tons of email. This proposal causes email
from DMARC-passing messages to be incapable of forwarding. As a large
email receiver who gets tons of
Apologies for jumping in late; just to note that 1024-bit keys seem to have
been accepted until quite recently:
https://www.sophos.com/en-us/support/knowledgebase/122327.aspx
On Wed 13/May/2015 13:54:04 +0200 Martijn Grooten wrote:
[...]
I don't think such a BCP should be so broad as to
-short hash
added to an SRS address, making it possible to avoid the database
entirely, except for address length worries. That's where EDSP can save
the day.
On Mon 01/Jul/2013 21:24:25 +0200 Michael Deutschmann wrote:
On Mon, 1 Jul 2013, Alessandro Vesely wrote:
Well, not really. MAIL FROM
On Tue 02/Jul/2013 17:37:20 +0200 Michael Deutschmann wrote:
On Tue, 2 Jul 2013, Alessandro Vesely wrote:
(subject adjusted)
A sender using SRS would need to maintain a database of valid addresses.
[...] That's where EDSP can save the day.
That's off in the weeds. EDSP would not take any
On Sun 30/Jun/2013 15:21:29 +0200 Michael Deutschmann wrote:
EDSP would only pay attention to signatures where the d= matches
the right hand side of the RFC821 MAIL FROM:.
This means that someone can publish the strictest possible EDSP
without causing mailing list false positives. Mailing
On 07/Jul/11 16:13, Dave CROCKER wrote:
On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote:
I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise
Postel's statement, do we?)
You're either liberal in your application of the RFCs, or you're not. I
don't see how adding that word
On 06/Jul/11 20:34, Murray S. Kucherawy wrote:
Anyway, with a few nitty edits from me as well, here's the current
8.15 for -15 for everyone's consideration.
A few comments:
8.15. Attacks Involving Extra Header Fields
[...]
Many email components, including MTAs, MSAs, MUAs and
On 27/Jun/11 23:38, Michael Deutschmann wrote:
* Put it in its own RFC *
I think there's room for a Minimum Quality of Forgery Supression BCP.
Such an RFC would outline a number of faults a message can have, and
declare that any of those faults mean the message MUST NOT be delivered
to
On 17/Jun/11 20:01, Murray S. Kucherawy wrote:
From: [...] On Behalf Of Alessandro Vesely
does anybody know about commercial/free DKIM verifiers that produce a
certificate of valid email message, or similar, for archival usage
by the requesting party?
What, other than an Authentication
Hi all,
does anybody know about commercial/free DKIM verifiers that produce a
certificate of valid email message, or similar, for archival usage
by the requesting party?
TIA
___
NOTE WELL: This list operates according to
On 31/May/11 17:28, John R. Levine wrote:
Chain of trust is always an appealing model. Unfortunately, it hasn't
been used successfully over the open Internet.
I agree with your doubts about the utility of chain of trust, but I would
have to say that SSL signed web sites are used
On 31/May/11 00:23, Murray S. Kucherawy wrote:
-Original Message-
From: On Behalf Of Steve Atkins
The most obvious thing that MLMs do that invalidate signatures are 1.
append content to the body and 2. prepend content to the subject line.
Any approach that allows me to replay
On 27/May/11 19:16, Murray S. Kucherawy wrote:
I'm all for including experimental code in future releases of our
stuff, especially if it's an experiment other implementations are
trying. But I need to see a spec first, or enough detail that I
could write one.
For the body, I brought some
On 26/May/11 23:52, Murray S. Kucherawy wrote:
From: On Behalf Of Franck Martin
2) do we need a mechanism to alert the receiving MTA that you have
subscribed to a mailing list, and all messages should pass through?
Yes, desperately.
Certainly a possible feature, but it seems like it won't
On 25/May/11 20:23, Dave CROCKER wrote:
On 5/25/2011 9:59 AM, John Levine wrote:
The idea is to anticipate any unknown signature breaker.
I'm pretty sure that's specifically out of scope.
And I promise that whatever you do, short of wrapping the whole
message in opaque armor, I can come up
On 25/May/11 18:42, Hector Santos wrote:
Alessandro Vesely wrote:
Yes, dot is one of the punctuation characters that should be removed.
This turned out to be a bug in our beta code, revamped to support I/O
completion ports and the code for undotting of the leading dot (per
RFC5321 4.5.2
On 27/May/11 18:29, John R. Levine wrote:
2) do we need a mechanism to alert the receiving MTA that you have
subscribed to a mailing list, and all messages should pass through?
Yes, desperately.
Certainly a possible feature, but it seems like it won't scale very well.
Why not?
If I were
On 25/May/11 10:03, Hector Santos wrote:
How would 7/8 bit be considered?
Personally, the STRIP C14N idea would work just fine by removing all
trailing WSP (CR, LF, SP) and for QP text, decode it first. I'm
considering updating my 2006 I-D to include the QP decoding logic.
I propose a
On 25/May/11 14:27, Hector Santos wrote:
Alessandro Vesely wrote:
On 25/May/11 10:03, Hector Santos wrote:
How would 7/8 bit be considered?
Personally, the STRIP C14N idea would work just fine by removing all
trailing WSP (CR, LF, SP) and for QP text, decode it first. I'm
considering
On 23/May/11 22:04, Hector Santos wrote:
Alessandro Vesely wrote:
On 23/May/11 06:35, Hector Santos wrote:
Alessandro Vesely wrote:
For example, MTAs that autoconvert from quoted-printable to 8bit, a
rather common circumstance.
I did the following Content-Transfer-Encoding failure analysis
On 24/May/11 15:22, John Levine wrote:
Of the 31, 20 were from Keith Moore signed messages into the IETF-SMTP
list with a 3rd party signature and Hoffman's list server (non-dkim
aware) doing this:
Oh, it's a mailing list. Why are we even having this discussion? We all
know there's a
On 24/May/11 16:14, John R. Levine wrote:
Although it is a minor number of messages, I don't think that
ignore-by-design could play a winning role here, because --unlike
mailing lists-- there is no way to eventually fix this at the
forwarding MTA.
If the EAI work is any guide, in the long
On 23/May/11 06:35, Hector Santos wrote:
Alessandro Vesely wrote:
For example, MTAs that autoconvert from quoted-printable to 8bit, a
rather common circumstance.
I did the following Content-Transfer-Encoding failure analysis:
Failure rates for message top level encoding type
On 19/May/11 05:17, John Levine wrote:
The point I was making was that ever more complex ways to decide that
two mutated versions of a message are the same aren't likely to help
much, certainly not compared to the large cost of implementing code
even more complex than what relaxed does now.
On 20/May/11 15:33, John Levine wrote:
of what paths are likely to downcode a message and what paths aren't,
so I would prefer not to purport to offer advice about it.
Actually, I kinda prefer to leave it in. It seems to me assume a
downgrade will happen unless you're certain it won't, and
On 17/May/11 20:17, Dave CROCKER wrote:
On 5/17/2011 1:54 PM, Murray S. Kucherawy wrote:
The remaining changes are inconsistent with the rest of the section or don't
clarify anything. For example, the hash-alg function on the body-hash line
takes the canonicalized body and the l-param as
On 17/May/11 16:45, Ian Eiloart wrote:
However if some of the messages were never properly signed (whether
failed attempts to spoof, or administrative or technical failure),
then that 20% must be higher. It could even represent 100%
reduction in false negatives due to (otherwise benign)
Version -10 says
More formally, pseudo-code for the signature algorithm is:
body-hash = hash-alg (canon-body, l-param)
data-hash= hash-alg (h-headers, D-SIG, content-hash)
signature= sig-alg (d-domain, selector, data-hash)
where:
body-hash: is the output from hashing
On 15/May/11 21:04, Hector Santos wrote:
The author can be a human using an MUA (Mail User Agent) or
an automated mail robot with an MTA.
Both the human and the robot use an MTA (or an MSA.)
___
NOTE WELL: This list operates according to
On 16/May/11 06:15, Murray S. Kucherawy wrote:
From: On Behalf Of Barry Leiba
2. We wanted to cover the vast majority of the cases, though we knew
there'd always be outlying situations where some mail would get broken
because what we had didn't *quite* cover some other case. We decided
to
On 16/May/11 15:00, John R. Levine wrote:
In retrospect, it probably would have been better only to provide
simple and tell people more firmly to do the signing after and the
checking before any local modification.
That implies hop to hop rather than end to end. What would the
advantage over
On 16/May/11 15:41, John R. Levine wrote:
http://www.opendkim.org/stats/report.html#hdr_canon says
Header canonicalization use:
canonicalization count domains passed
simple 653688 6786591938
relaxed 3940377 56621 3640854
Although they only differ by
On 16/May/11 19:00, Michael Thomas wrote:
On 05/16/2011 09:39 AM, Dave CROCKER wrote:
The problem with the above is the biasing factor of signers' choosing to use
one
or the other, based on criteria we can't know about. Their criteria might
have
greatly affected actual survival rates. Or
On 14/May/11 22:16, Hector Santos wrote:
SM wrote:
From http://www.rfc-editor.org/rfc/rfc5321.txt
DATA
I: 354 - data - S: 250
E: 552, 554, 451, 452
E: 450, 550 (rejections for policy reasons)
Ok.
I recommend (prefer) text
On 13/May/11 20:17, Murray S. Kucherawy wrote:
From: On Behalf Of SM
By my read, the bulk of your comments fall into these categories:
(1) Remove the normative language, publish as Informational
My reading of SM's comments is for replacing Best Current Practices,
not normative language in
On 13/May/11 09:15, SM wrote:
In Section 4.1:
In an idealized world, if an author knows that the MLM to which a
message is being sent is a non-participating resending MLM, the
author SHOULD be cautious when deciding whether or not to send a
signed message to the list.
The
On 08/May/11 19:13, Dave CROCKER wrote:
In practical terms for the current world, what is the likelihood that a
signer
has any information about the 'type' of an email address? How can a signer
possibly know that an addressee is a mailing list???
Currently, it has to query the
On 07/May/11 15:39, Hector Santos wrote:
I would like to know why 6% of the mail use [l=] but don't need it.
One possible answer is that the signing agents have no clue about that
mail's destination. The easiest way to configure DKIM in order to use
l= on some messages, is to enable it on _all_
On 06/May/11 20:37, Murray S. Kucherawy wrote:
Verifiers SHOULD ignore those signatures that produce a PERMFAIL
result (see Section 7.1), acting as though they were not present
in the message. ...
s/Verifiers SHOULD ignore/Identity assessors SHOULD ignore/
(and probably in other
On 06/May/11 21:09, John R. Levine wrote:
this, but I need to get a clear view of consensus. Doug agrees with
Hector's note, below, and Dave and Murray do not. I'd like to hear
from others within the next few days, about whether you think we
should make the change Hector requests or not.
On 04.05.2011 21:13, MH Michael Hammer (5304) wrote:
boun...@mipassoc.org] On Behalf Of Dave CROCKER
On 5/4/2011 11:34 AM, Murray S. Kucherawy wrote:
So the issue is that someone might read it as leave l=value out
of what you feed to the hash versus hash it, but ignore what it's
telling you?
On 03.05.2011 15:28, Hector Santos wrote:
Authentication-Results: dkim.winserver.com;
dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1;
adsp=fail policy=unknown author.d=tana.it signer.d=mipassoc.org
(unauthorized signer);
The (unauthorized signer) was added
On 04.05.2011 14:56, Hector Santos wrote:
Alessandro Vesely wrote:
The only difference between setting unsigned and letting it be derived
by default should be the ability to control the expiration of such
value.
Can you rephrase this so I can better understand your thinking?
ATPS wasn't
On 01.05.2011 14:13, John R. Levine wrote:
I don't think we actually understand all the ways that l= allows you to
shoot yourself in the foot, so I would prefer not to give the impression
that if people avoid a few cases we describe, they're safe.
-1, I agree we don't know all the ways DKIM
On 01.05.2011 10:38, Hector Santos wrote:
Again, its about protocol consistency. So maybe I should ask the
chairs for:
Consensus needs to be reevaluated
IMHO, it needs not: It is premature to define an ODID now. ADSP is
considered somewhat broken, and for this message, for
On 01/May/11 06:18, John R. Levine wrote:
What's your counter-proposal to Alessandro's proposal to modify 9.1.1?
Oh, that. Replace all of sec 9.1 with:
As noted in Section 4.4.5, use of the l= tag enables a variety of
attacks in which added content can partially or completely changes
On 29/Apr/11 19:56, Dave CROCKER wrote:
As for the second part, with or without Content-Type, messing with the
message
in any interesting way will break the signature.
I'm not sure what you mean by second part and interesting way.
The change to that security consideration section was meant
On 29/Apr/11 19:39, Murray S. Kucherawy wrote:
Here’s a more comprehensive proposal for an output summary (excuse the
“diff” output):
+4.9. Output Requirements
+
+ For each signature that verifies successfully or produces a TEMPFAIL
+ result, the output of a DKIM verifier module MUST
On 27/Apr/11 21:29, Dave CROCKER wrote:
On 4/27/2011 12:17 PM, Murray S. Kucherawy wrote:
Actually if we're talking about A-R fields, RFC5451 talks plenty
about this. Rather than duplicating advice, we should just refer
to it.
as long as it's informative rather than normative, that seems
On 27/Apr/11 22:18, John R. Levine wrote:
We check ADSP every time we run DKIM and see the following policy
distribution:
97.98% unknown (including domains not explicitly publishing policy)
2% discardable
0.02% all
In my much smaller sample, I see discardable on mail from Paypal,
and I
On 27/Apr/11 01:25, John Levine wrote:
Whether the name in the DNS record should be brisbane or
brisbane._domainkey or brisbane._domainkey.example.org depends
entirely on the most recent $ORIGIN line in the master file. If the
$ORIGIN is _domainkey.example.org, an entirely plausible scenario,
On 26/Apr/11 23:50, MH Michael Hammer (5304) wrote:
However I suggest adding the usual waffling qualifier:
claiming (some) responsibility
I think we should drop signed from it, since that's what the entire
specification is about in the first place.
I think it is better to leave
On 26/Apr/11 23:13, Dave CROCKER wrote:
I think I understand the intent, here, and I'm supportive of the goal.
However
the text is technically invalid. A DKIM signature has only one meaning,
relative to existing, formal specification.
Inferring meanings beyond what is defined is very,
I'm puzzled by this message
http://www.ietf.org/mail-archive/web/ipr-announce/current/msg00447.html
Its date is Tue, 26 Apr 2011 09:01:41 -0700 (PDT), and it talks about
a submission on 2011-04-10. However, the given datatracker URL
(1530) results in a 404 Not Found error, and the mentioned
On 27/Apr/11 01:42, John R. Levine wrote:
I agree with Dave's changes,
+1, and also for Murray's advice of signing A-R fields. However, in
such case, the last phrase in Sec 7.2 (INFORMATIVE ADVICE to MUA
filter writers) should be changed from
To circumvent this attack, verifiers may wish to
On 26/Apr/11 06:19, Hector Santos wrote:
While I agree with your version, if there is anything else to
reconsider it would be the last sentence:
However, compliant verifiers might not implement rsa-sha1;
they will treat such messages as unsigned.
That seems to say rsa-sha1
On 26/Apr/11 07:09, Murray S. Kucherawy wrote:
-Original Message-
From: Dave CROCKER [mailto:d...@dcrocker.net]
So with all that in mind, here's my suggestion for replacing the first part
of
this section:
[...]
o Subject
o Date,
I guess Message-ID is among those
Section 6.8 proposes a binding between List-Post and the signing domain:
A signing MLM could add a List-Post: {DKIM 12} header field (see
[LIST-URLS]) using that DNS domain matching the one used in the d=
tag of the DKIM signature that is added by the MLM. This can be used
by {DKIM 12}
On 21/Apr/11 14:25, John R. Levine wrote:
Use of A-labels within header fields supporting UTF-8 is a bad idea.
Since DKIM is defined on RFC 5322 messages, and 5322 is ASCII-only, no
header fields in a compliant message can contain UTF-8.
It would be surprising if DKIM supported UTF-8 in the
On 16/Apr/11 18:45, Dave CROCKER wrote:
The problem with ignoring UTF-8 issues is, of course, that that's no longer
acceptable.
Would it be acceptable to put some text like the following?
Internationalized domain names MUST be represented as A-labels
as described in [RFC5890].
NOTE:
Section 3.3 has the phrase
Verifiers MUST implement rsa-sha256
Implementers will understand that they can go away with a verifier
that does not implement rsa-sha1. Their verifier would then return
PERMFAIL for the sha1-signed newsletter in the following informative
note. I suggest to
On 03/Apr/11 18:45, Murray S. Kucherawy wrote:
I think when it's clear there's no more progress that can be made,
you close down and move on. You can always start up a WG later
when there's a chance for better progress or new work to be done.
Is there a difference between the WG and the
On 01/Apr/11 23:08, Murray S. Kucherawy wrote:
*2.3**. Identity*
A person, role, or organization. In the context of DKIM, examples
include the author, the author's organization, an ISP along the
handling path, an independent trust assessment service, and a mailing
list
On 04/Apr/11 06:09, John Levine wrote:
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
On 04/Apr/11 18:03, John Levine wrote:
Signers SHOULD NOT remove any DKIM-Signature header fields from
messages they are signing, even if they know that the signatures
cannot be verified. Instead, when a relay alters a message such
that any valid signature gets broken, it SHOULD
On 02/Apr/11 09:08, Hector Santos wrote:
I would suggest an aura is present that the job is not done
especially when there are still active discussions about removing,
deprecating, changing this and that, and there is still a chartered
POLICY standard development work item yet not complete.
On 05/Mar/11 02:02, Jim Fenton wrote:
1. Introduction: The opening paragraph has lost the sense that the
signer has to be authorized by the domain owner to apply a signature on
behalf of that domain. While the previous draft was a bit too
restrictive (implied that the signer had to
On 13/Jan/11 18:10, Dave CROCKER wrote:
3. For authentication uses, it's unlikely that the DKIM-Signature header field
should be shared, because it is an explicit flag for specific DKIM semantics,
including the meaning of a signature. Any other signature scheme is going
to
have different
On 11/Jan/11 20:15, John R. Levine wrote:
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,
On 07/Jan/11 21:58, Dave CROCKER wrote:
Here's the proposal that Barry just announced, for splitting the DKIM
specification into a DKIM-specific portion and an underlying, more generic
portion that could be re-purposed for other services. It's current working
acronym is DOSETA.
I'm
Like RFC 4871, draft-ietf-dkim-rfc4871bis-02 says
3.3.1. The rsa-sha1 Signing Algorithm
The rsa-sha1 Signing Algorithm computes a message hash as described
in Section 3.7 below using SHA-1 [FIPS-180-2-2002] as the hash-alg.
That hash is then signed by the signer using the RSA algorithm
On 24/Nov/10 16:46, Ian Eiloart wrote:
DKIM and SPF both permit the use of domain based reputation
databases. Unfortunately, both have problems with various paths
that emails may take. Fortunately, the problematic paths are
different - mailing lists are problematic for one, and forwarding
is
Hi Tsuneki,
first of all, since I write, let me make my welcome-on-list explicit!
On 22/Nov/10 03:43, Tsuneki Ohnishi wrote:
Senders in dkim.jp are committed to attach DKIM signature
withing 6 months, and possibly ready to write their ADSP
discardable. Since we have major ISPs on our member
On 09/Nov/10 03:05, John R. Levine wrote:
Signers SHOULD take reasonable steps to ensure
that the messages they're signing are valid according to [RFC 5322,
etc]. Leaving the definition of reasonable out allows flexibility. It
may be waffly, but I like the approach in this case.
This
On 08/Nov/10 06:25, Murray S. Kucherawy wrote:
Filename: draft-kucherawy-authres-vbr
Revision: 00
Title: Authentication-Results Registration For Vouch By
Reference Results
Creation_date: 2010-11-07
WG ID: Independent Submission
On 08/Nov/10 10:20, Barry Leiba wrote:
As participant:
[...]
Proposal:
1. The DKIM spec is responsible for describing the problem in terms of
how it relates to signed and unsigned versions of the fields. That's
the stuff in 8.14.
+1. IMHO, 8.14 may avoid giving any advice, if we are
On 08/Nov/10 15:52, Hector Santos wrote:
Alessandro Vesely wrote:
2. The DKIM spec should probably say that signers need to sign valid
messages, and, therefore, SHOULD NOT sign things like this. Text
along the line of this might work well:
Signers SHOULD take reasonable steps to ensure
On 02/Nov/10 22:58, Douglas Otis wrote:
On 11/2/10 11:47 AM, Alessandro Vesely wrote:
On 01/Nov/10 22:56, Douglas Otis wrote:
If big-bank.com asserts a restrictive policy, the relevant author
address should make that message fail ADSP verification, since no
author domain signature
On 01/Nov/10 22:56, Douglas Otis wrote:
On 10/30/10 3:05 AM, Alessandro Vesely wrote:
On 28/Oct/10 03:36, Douglas Otis wrote:
I'll repeat the example given previously. The multiple listing of a
header in the h= parameter can not mitigate exploitation of DKIM PASS
results where a valuable
Rolf E. Sonneveld wrote:
I'm not very happy with the introduction of the word 'some' in front of
'responsibility'. The way it is mentioned now is like one can say
'somewhat dead' or 'a bit pregnant'.
It involves domains. For comparison with the web, how would we describe the
varying degree
On 28/Oct/10 03:36, Douglas Otis wrote:
I'll repeat the example given previously. The multiple listing of a
header in the h= parameter can not mitigate exploitation of DKIM PASS
results where a valuable domain is prefixed to that of large domain.
The large domain is unlikely concerned by
On 25/Oct/10 06:54, Steve Atkins wrote:
On Oct 24, 2010, at 9:05 PM, Murray S. Kucherawy wrote:
3) For any header field listed in Section 3.6 of [MAIL] as having
an upper bound on the number of times it can appear, include the
name of that field one extra time in the “h=” portion of the
On 26/Oct/10 19:08, Murray S. Kucherawy wrote:
On Behalf Of Alessandro Vesely
On 26/Oct/10 06:58, Murray S. Kucherawy wrote:
a verifying module might return a syntax error code or arrange not to
return a positive result even if the signature technically validates.
-1. How does might
On 26/Oct/10 06:58, Murray S. Kucherawy wrote:
a verifying module might return a syntax error code or arrange not to
return a positive result even if the signature technically validates.
-1. How does might differ from MAY?
___
NOTE WELL: This list
On 23/Oct/10 21:25, Barry Leiba wrote:
DKIM makes no statement about the validity of a sender address.
DKIM makes no statement about the validity of an Author address.
No matter how many times it is stated and repeated, it will never be
true. If one wants this to be true, then remove the
On 22/Oct/10 18:06, Charles Lindsey wrote:
On Thu, 21 Oct 2010 16:17:18 +0100, Alessandro Veselyves...@tana.it
wrote:
DKIM-Signature: d=Big-IPS.com; h=from; (supposedly)...
From accou...@big-bank.com
From some...@big-ips.com
Subject: Audit notification
body of text saying
On 20/Oct/10 19:48, Douglas Otis wrote:
On 10/20/10 7:27 AM, Alessandro Vesely wrote:
For example, the initial paragraph of section 5.4 could be
modified so as to read:
The From header field MUST be signed; that is, it MUST be included
at least once in the h= tag of the resulting DKIM
On 21/Oct/10 17:47, John R. Levine wrote:
If Big-Bank had been added after signing, verifiers are already
authorized to delete that field from the message, according to the
current PS. Isn't that enough?
I don't know any DKIM verifier that modifies the message, and I doubt
that many people
On 18/Oct/10 20:50, Dave CROCKER wrote:
There is a premise that is motivating the proponents of giving instructions to
MUA designers about DKIM outcomes. The premise is that providing DKIM
information will be useful, and possibly that providing /more/ DKIM
information
will be more useful.
On 19/Oct/10 04:55, John Levine wrote:
There's a strong correlation between badly structured emails (SMTP,
MIME, HTML) and email that the recipient doesn't want to see.
You're right, but I think that's largely orthogonal to DKIM. If a
message has a good signature from a credible signer, I
On 16/Oct/10 21:24, John R. Levine wrote:
Which header fields are essential to protect?
How much of the message body is essential to protect?
Your questions are noted. Other than the MUST to sign the From:
header, the DKIM spec offers the technical latitide to create a
totally worthless
On 14/Oct/10 20:09, Mark Delany wrote:
On Thu, Oct 14, 2010 at 08:01:17PM +0200, Alessandro Vesely allegedly wrote:
On 13/Oct/10 20:45, Scott Kitterman wrote:
On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
If we can extract DKIM from the equation entirely
On 15/Oct/10 17:13, John Levine wrote:
In article201010151013.26823.ietf-d...@kitterman.com you write:
On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote:
why don't we just deprecate l=?
Yes. Please.
Agreed. Has anyone ever found it useful for its nominal purpose of
On 15/Oct/10 18:59, Jim Fenton wrote:
On 10/15/10 2:12 AM, Alessandro Vesely wrote:
Fuzziness stems from the fact that a signature on a given message may
either verify or not depending on how meticulously the verifier
interprets that SHOULD. The MUST immediately following
On 14/Oct/10 00:22, Jim Fenton wrote:
Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.):
6.1.1 Validate the Message Syntax
The verifier SHOULD meticulously validate the format of the message
being verified against the requirements specified in [RFC5322],
[RFC2045], and
1 - 100 of 160 matches
Mail list logo
