On Fri, Oct 28, 2005 at 12:30:39PM +0100, Stephen Farrell wrote:
>
> Doug,
>
> This thread doesn't really appear to be going anywhere.
>
> Someone earlier asked you to provide examples. Why don't
> you do that in a new thread - just an example showing the
> worst bad effect you claim but withou
om: IETF-DKIM No-Reply <[EMAIL PROTECTED]>, Douglas Otis
> > <[EMAIL PROTECTED]>
> >
>
> Yes, this is valid 2822. I wonder what it breaks...
While it is valid, can anyone point to it being actually being used?
--
:: Jeff Macdonald | Principal Engineer, Messaging
checks. I do believe he said the banks understood that may mean some
legitimate mail may not be delivered.
This is meant as a simple data point and nothing more.
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA
ven't heard anyone else
> yelling eureka! either.
That's because it takes a while to digest what Doug is trying to say. So
while I'm not saying 'eureka!', I'm also not saying 'nonsense!'. I suspect
that this may be true of others who are lurking.
--
The standard isn't finalized yet, correct? So how can we have vendors
say they have conforming implementations?
I'm talking DKIM, not DK.
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
::
On Wed, Feb 01, 2006 at 08:49:44AM -0800, Dave Crocker wrote:
>
>
> Jeff Macdonald wrote:
> >The standard isn't finalized yet, correct? So how can we have vendors
> >say they have conforming implementations?
> >
> >I'm talking DKIM, not DK.
>
&
nal model of
Originator and Operator.
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com
___
NOTE WELL: This
On Fri, Mar 10, 2006 at 11:27:40AM -0500, Jeff Macdonald wrote:
> However, if we just talking mail streams and not content, then I like
> your original model of Originator and Operator.
Let me ammend that. I just re-read your definition of Originator and
that doesn't talk about mail
t; +0.90
>
> This is much better Dave.
>
> But I'm not use to the term "Retailer." If you can find another term...
+1 when you find another term for Retailer.
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hart
of
> notation or semaphore.
>
> Signer trust semaphores should be coupled with the signature.
I do like this semaphore/opaque token idea. I think it answers Laura
Mathers' question (at the sender authentication summit) about MUA's
showing only quoted parts.
--
:
ated battles to add more key considerations that were
> talked about but ignored.
+1
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: w
tionship and only when the Receiver _wants_ this relationship does
the trust mechanism come into play.
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781
On Mon, Aug 07, 2006 at 06:03:34PM -0700, Dave Crocker wrote:
>
>
> Jeff Macdonald wrote:
> >> senders are not the right people to judge their own importance.
> >
> > So, I've been thinking pretty much the same thing after seeing all the
> > recent t
While I agree with this observation, I find the discussion very
educational.
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: w
he receiver)
and a block or placement into the bulk folder happens.
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com
e of giving different treatments to different
> types of "other".
+1
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com
d mail."
>
> If you want to eliminate that requirement say: +1
> If you want to keep that requirement say: -1
>
> Remember: wordsmithing is for later.
>
> Stephen.
>
> ___
> NOTE WELL: This list operates according t
On Mon, Mar 12, 2007 at 08:43:58AM -0400, Tony Hansen wrote:
> In other words, would folks prefer to:
>
> A. Expedite publishing the Overview documents, in order to facilitate
> development and deployment of the -base specification (with an update
> later on for SSP), or
+
telling the world that DKIM isn't ready.
I don't think the 'world' understands that DKIM is just a building
block.
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwel
of
> that larger community. (Dare I note that even within the working group,
> there is often disparity on basic point about DKIM, which -overview ought
> to be useful in settling?
So who is overview really for? Management or implementors?
--
:: Jeff Macdonald | Principal Engineer, M
-
>
> 1) Exclude this requirement (don't mention it)
> 2) Include this requirement as a MUST NOT
> 3) Include this requirement as a MAY
> 4) Inlcude this requirement as a SHOULD
> 5) Inlcude this requirement as a MUST
#1
--
:: Jeff Macdonald | Principal Engineer, Messaging
name.
I didn't think they were proposing any particular name, just that after
looking up the MX record, the corresponding A lookup failed. Surely all
MTAs should be able to handle that case. Newer ones would realize that
the domain in question doesn't want any mail, while older o
g IP.
If that's the case, shouldn't the deprecating of A lookups when a MX
lookup fails be brought to the SMTP group?
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 7
something else)
>Issue#2: -1 - Don't use TXT at all, only use new RRs for SSP
+1
>Issue#3: +1 - Define an upward query based approach to finding SSP
> statements
>Issue#3: -1 - Define a wildcard based approach to finding SSP
> sta
gcompany.com
[EMAIL PROTECTED]
d=bigmarketingcompany.com
[EMAIL PROTECTED]
etc.
One signing domain, one DKIM entry in DNS, but many identities.
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781
erent type of mail streams
(transactional,marketing,etc) by using IPs. The same can be
accomplished with DKIM and i=.
I also hadn't realized that DKIM was strictly meant to benefit
receivers.
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Har
nts, not different
> categories.
Ah, I see the disconnect. bigmarketingcompany is not the same as ESP.
Here's a better example:
d=mattel.com
[EMAIL PROTECTED]
d=mattel.com
[EMAIL PROTECTED]
d=mattel.com
[EMAIL PROTECTED]
d=mattel.com
[EMAIL PROTECTED]
--
:: Jeff Macdonald | Director o
On Wed, Oct 24, 2007 at 11:57:43AM -0400, Hector Santos wrote:
> Jeff Macdonald wrote:
> >
>> I also hadn't realized that DKIM was strictly meant to benefit
>> receivers.
>
> Did you really think DKIM will alter the deeply embedded mail filtering
> landscape?
equal to d=, why there needs to be further validation.
Why would a signing domain add an i= that would not be responsible? If
the answer is "because you can", why would one believe that d= would be
responsible?
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EM
gle identifer, which clearly
isn't the case.)
this thinking needs to be applied to d= too. And once you do that, then
the logical conclusion (well, to me :)) is that d= isn't any better as
an identifier.
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL
t: Get a great rate today!
You'd accept the message?
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com
___
NOTE WEL
r example, does p=strict, t=testing mean? It seems like a silly-state
to me and ripe for confusion. It's that sort of subjective state that we
should both learn from SPF and avoid.
+1
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell
ion to "originator" need to be changed
to "author",
+1
unless the reference really means rfc2822.sender, in which
case they should be changed to that.
-1
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | L
-party signature, and mail without
valid signature.
+1
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com
rk on SSP is attempting to
instead validate authorship.
DKIM needs to say what part of DKIM asserts a new identity. What is the
output of DKIM? And should that output be treated as opaque.
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell A
On Tue, Jan 29, 2008 at 10:41:05AM -0800, Dave Crocker wrote:
Jeff Macdonald wrote:
In any event, "on behalf of" is key wording that permits more flexibility
than you seem to be acknowledging. Note, for example, that the agent
specified in the Sender field is acting "on
atus codes.
Interesting suggestion Frank. In you mind would this be a 5.7.x
enhanced status code?
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-
On Wed, Jan 30, 2008 at 11:18:08AM -, Charles Lindsey wrote:
On Tue, 29 Jan 2008 17:52:57 -, Jeff Macdonald
<[EMAIL PROTECTED]> wrote:
On Wed, Jan 16, 2008 at 09:46:26AM -0800, Dave Crocker wrote:
In any event, "on behalf of" is key wording that permits more flexi
On Wed, Jan 30, 2008 at 03:34:33PM +0100, Frank Ellermann wrote:
5.7.0 is apparently too unspecific. In theory SSP could create
its own 5.7.x if the eight existing codes are not good enough:
http://tools.ietf.org/html/rfc3463#section-3.8
That is what I'm getting at. A new 5.7.x.
--
::
ot;Author Domain" signs the message,
>the message is complaint with the "Author Domain's Signing Policy" _by
>definition_.
>
>4) Only when the message is not signed by the "Author Domain", is the
>"Author Domain Signing Policy" in need of checkin
> think we do have consensus to prefer "Practice" instead, so I
> made that change.
>
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
--
:: Jeff Macdonald | Director of Messag
r. There is lots of
advice for a company (an identity) to put different types of mail
streams on different IPs. So logically one would use different DKIM
identifiers to accomplish the same thing with DKIM.
I know we can't tell receivers what to do, but I'm sure we don&#x
ng
> one wants for that is a mechanism that groups them all together.
It would be nice that some BCP says d= should be treated as an opaque
value since I don't think the DKIM spec says such a thing.
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL
> Instead of discussing how many angels fit on a pinhead, I suggest
> that we do something sensible, like: ADSP is bound to DNS, and
> therefore it's defined only for author domains that exist in DNS.
+1
--
:: Jeff Macdonald | Director of Messagin
rately discuss what,
> if anything, should go into the security considerations section that
> covers the issue. Actually, even keeping it in, we should probably
> add some new sec. cons. text derived from the recent discussion, but
> let's see if we've consensus first.
>
&g
I too like the wording in draft-levine-dkim-adsp-00, but I'm not sure if
that means a modify or remove. draft-levine-dkim-adsp-00 doesn't list
steps like the current -03 draft does.
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Ha
IM is it provides a verifiable
identity. Nothing more. Does DKIM seek to prevent other protocols from
using this identity as they see fit?
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 |
On Thu, 2008-05-29 at 13:39 +, Jeff Macdonald wrote:
> I too like the wording in draft-levine-dkim-adsp-00, but I'm not sure if
> that means a modify or remove. draft-levine-dkim-adsp-00 doesn't list
> steps like the current -03 draft does.
I'd like to switch this to M
service and be
able to take advantage of a established reputation, they'd sign twice:
d=corp.rep.paypal.com
...
d=123.rep.paypal.com
AND if they wanted ADSP, they'd sign 3 times.
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [EMAIL PROTECTED]
:: 131 Hartw
7;d like us to discard it.
levine-adsp-00 says:
The verifier MUST return an appropriate error result for Author Domains
that are outside the scope of ADSP.
To me, "outside the scope" allows a receiver to assume the message is
legitimate, assuming no other checks besides ADSP are done.
If t
; >
> >> > Stephen Farrell wrote:
> >> >> It might be no harm if folks who do think ADSP should
> >> >> go ahead would respond to this saying so.
> >> >
+1
--
Jeff Macdonald <[EMAIL PROTECTED]>
e-Dialog
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
nt hasn't happened yet. :)
--
Jeff Macdonald <[EMAIL PROTECTED]>
e-Dialog
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
main, or a Valid Signature from an Author Domain that does
>not meet the requirements of Author Signature, .."?
I apologize for not re-reading all of the ADSP document, but I think we
have to remember that a message can have multiple DKIM signatures.
Per
Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of
ed opaquely as it could really represent anything.
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
a header in which I could tell
Mutt to display works for me. :)
But for everyone else, viewing the source (or internet headers) is
always an option. I don't know if that qualifies as "clear to the
reader", but it is close enough for me.
--
Jeff Macdonald
jmacdon...@e-dialo
from the perspective of a
receiver, but it does denote that something is different than a
straight d= value. Is that your thinking too?
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
a mechanism to limit the
amount of potential i= values. If d= is in a some sort of list, then
i= would be included the reputation model.
I'd still think even given that model, you'd let the actions of the i=
determine the trustworthness of the steam independent of what the owner
of d= cl
r
does not control it.
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
= contains.
d= is just an identfier that is used to look up the public key and
could further be used as a key into a reputation system.
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Tue, Feb 10, 2009 at 12:23:02PM -0500, Hector Santos wrote:
> Jeff Macdonald wrote:
>>
>> d=good.rep.example.net or
>> d=bad.rep.example.net
>>
>> do not assume that those identifiers mean "good" and "bad". Good and
>> bad could b
t_of_dkim();
reputation=dkim_rep(identifier_d);
* I say hopefully because I haven't read the latest errata.
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Wed, Feb 11, 2009 at 09:01:39AM -0800, Jim Fenton wrote:
>Jeff Macdonald wrote:
>>
>> As a signer, I may want to do this:
>>
>> i...@transaction.company.com d=company.com for transactional messages and
>> d=company.com for everything else (yes, there is no i=, b
On Wed, Feb 11, 2009 at 11:46:14AM -0800, Murray S. Kucherawy wrote:
> On Wed, 11 Feb 2009, Jeff Macdonald wrote:
>>> It would be equally valid for a signer to apply a different
>>> pseudo-subdomain on each message, perhaps for tracking purposes.
>>
>> I think t
On Wed, Feb 11, 2009 at 01:44:32PM -0800, Murray S. Kucherawy wrote:
> On Wed, 11 Feb 2009, Jeff Macdonald wrote:
>>>> My understanding of opaque allows identical opaque values to
>>>> identify the same "something".
>>>
>>> Then yo
d as being within that sphere with the same
>UAID (but aren't required to). I don't think that's a
>contradiction
>
>The question is whether this introduces enough confusion that we need
>to either 1) clarify the missing side of the coin, as above and/or 2)
>s
On Mon, Feb 16, 2009 at 04:36:03PM +, Stephen Farrell wrote:
>(a) The erratum I-D [1] is ready to go. Process it.
+1
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-l
fil/specs/draft-macdonald-affiliated-nameslist-00-04dc.html
Today we use VBR, but my co-author and I are thinking that we'd
probably wouldn't even need that once things are ironed out.
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
s should be viewed as a violation of DKIM
Base?
I'm thinking John L's use of i= as a cookie and ADSP. I'll note that
John's use of i= would be considered a violation too.
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: T
ly to get towards consensus on issues like
>these.)
>
>That approach gets the gist of the Errata clarifications out in a much
>more timely manner (i.e., almost immediately), and does not preclude
>the generation of the -bis document as rapidly as the process allows.
+1
--
Jeff M
p up a new ADSP draft with an r= tag.
um, I read Jim's draft to use r= for "reputation" and not for ADSP. So
specify a new tag for ADSP.
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
gt;> Replace "Other DKIM values" to "Other information".
>>
>> My logic: what the assessor consumes beyond the SDID is outside the
>> scope of the spec.
>
>And add "by" between "delivered" and "this".
>
>After that, +1.
+1
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
t, it looks fine to me.
>___
>NOTE WELL: This list operates according to
>http://mipassoc.org/dkim/ietf-list-rules.html
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Thu, Mar 26, 2009 at 07:59:48PM -0400, Jeff Macdonald wrote:
> On Thu, Mar 26, 2009 at 03:49:38PM -0700, Dave CROCKER wrote:
>>> 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
>> ...
>>> New:
>>>A single domain name that is the mandato
processing, the name has only basic domain name semantics; any
>>possible owner-specific semantics is outside the scope of DKIM.
>
>A single domain name -> A single, syntactically valid domain name
>
>{{ no, I'm not in love that that wo
t, or at least, please explain.
The following shouldn't be discouraged:
From: f...@bar.com
DKIM-Signature: ... d=43343.rep.bar.com ...
where 43343.rep.bar.com doesn't have any MX or A record.
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Thu, Apr 02, 2009 at 08:15:02AM -0700, Dave CROCKER wrote:
>
>Use d=.
+1
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ld exist, since you need that to be able to install the key records,
>but the domain doesn't have to exist otherwise. Once you remember that
>the big advance of DKIM over its predecessors is to separate the signing
>domain from the domains in various other headers, this is clearly the
>to remove what's there rather than to change it.
+1
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
"I don't care [or I have no opinion] either way."
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Mon, May 04, 2009 at 09:26:15PM +0200, Eliot Lear wrote:
> On 5/4/09 9:17 PM, Jeff Macdonald wrote:
>>>> 2. On whether to move to draft standard
>>>>
>>>> While I was initially in favor of this, I am now uncomfortable
>>>> doing so,
>&
resh correctly, that the Standard draft would be based on
bis, +1.
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
lationship exists. Applying that to this:
FBL-Where-To-Send-Header: f...@example.net
DKIM-Signature: ... d=example.com ...
If in example.net's dns there exists an entry for example.com, then one
can safely assume there is a relationship between the two.
http://mipassoc.org/affil/specs/draft-ma
gt; > >> 3. A few "Yes, adding this is groovy," messages would be good and
>> all.
>> > >
>> > > Yes, adding this is way groovy.
>> >
>> > +1
>> >
>>
>> +1
>>
>
>+1
+1
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
mail (FBL handling,
>> primarily) and enabling rendering email with risky renderers (html,
>> pdf) by default
>
>
> uhhh. h...
>
> that doesn't qualify as clever?
>
> well, ok, maybe not /particularly/ clever, but still...
>
St
white list -- is the value of the "d=" tag. However, this does not
> prohibit message filtering engines from using the "i=" tag, or any
> other information in the message's header, for filtering decisions.
>
>
> For signers and verifiers th
On Thu, Jan 21, 2010 at 10:25 PM, John Levine wrote:
> YES to 1, 7, 8. NO to everything else.
>
+1
--
Jeff Macdonald
Ayer, MA
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
gt; >> voted on. As a working group, we'll need to agree on the wording, and
> >> come up with a few reasonable milestones with dates.
> >>
> >> Have at it.
> >>
> >> Barry and Stephen, as chairs
> >>
> >
> > It looks good to me. I
per definition of a
third-party signature? That would mean:
From: f...@example.com
DKIM-Signature: ... d=i.example.com
would be considered a third-party signature.
--
Jeff Macdonald
Ayer, MA
___
NOTE WELL: This list operates according to
http://mi
. I
> think that's why rfc4871 gives the "From" field foremost importance.
Are you sure you got the right RFC here?
--
Jeff Macdonald
Ayer, MA
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ghlights:
1) policy statements are futile
2) mailing lists are broken anyway
3) the importance of RFC5322From is overrated
* if you didn't see Brett's message, check your spam folder. I replied
using his message as a base.
--
Jeff Macdonald
Ayer, MA
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
s to maintain the signature,
> then offering the option for the list to validate the signature coming from X
> and send a new signature to Z that Z *can* (but doesn't have to) "trust", is
> something immediately useful.
Should the policy statements be ignored at that point?
On Tue, Apr 27, 2010 at 2:31 PM, Alessandro Vesely wrote:
> On 27/Apr/10 17:02, Jeff Macdonald wrote:
>> On Sat, Apr 24, 2010 at 10:14 AM, Alessandro Vesely wrote:
>>> Author signatures are special because the content of the "From" field
>>> is displayed to
On Wed, Apr 28, 2010 at 3:09 AM, Alessandro Vesely wrote:
> On 27/Apr/10 22:38, Jeff Macdonald wrote:
>>> The From header field MUST be signed (that is, included in the "h="
>>> tag of the resulting DKIM-Signature header field).
>>> http:/
fail. Seems like ADSP would make things worse in this
case.
--
Jeff Macdonald
Ayer, MA
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
now this hash been hashed out many times before.
Eventually we'll all be dust and something else will prevail. :)
--
Jeff Macdonald
Ayer, MA
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ears, which
> seems implausible.
That is exactly what I'm saying.
http://en.wikipedia.org/wiki/Asbestos
--
Jeff Macdonald
Ayer, MA
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
> not. Wow.
mail _from_ a mailing list is not the original message anymore.
I know this isn't a popular opinion. Just because something has been
done someway for 40 years doesn't make it right. Thus my link to
asbestos.
--
Jeff Macdonald
Ayer, MA
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ist but still want to accept or reject mail based
>> on assertions the list itself makes.
>>
>
> How about you trust the list, and it says the inbound message wasn't
> signed? The list has left the value judgement to the recipient.
How does one do that if using an email web servi
understood the intent.
I'm willing to go from a world where any system can use my From to one
where only the systems I say can. And that means changes.
--
Jeff Macdonald
Ayer, MA
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
1 - 100 of 170 matches
Mail list logo
