concurs)
+1 to letting the clock run out. What we have is more than sufficient.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
DKIM
design
principle and doesn't need ADSP (or other non-standard measures) for it to
be
something we should care about.
I think the language we've proposed in response to the DISCUSS covers this
appropriately.
+1
+1
--
J.D. Falk
the leading purveyor of industry counter-rhetoric
provoking.
+1
Having the same argument again and again hasn't and won't convince anyone to
change their minds.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org
cruft
removed. I think Pete made the right call. Ship it.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
a stream of short-term certs to everyone it
certifies, or the verifiers have to check CRLs, which is tedious. By the
time you do all that, a DNS check, even one with DNSSEC, looks pretty
attractive.
That's how it works at the IP level today.
--
J.D. Falk
the leading purveyor of industry
like we SHOULD all go back and re-read RFC 2119.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
such as
this:
The author can be a human using an MUA (Mail User Agent) or
an automated process that may send mail (for example, the cron
Unix system utility).
+1
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
On May 13, 2011, at 3:40 PM, Rolf E. Sonneveld wrote:
I'd propose to put this item ('writeup a definition of 'discardable') on
the to-do list of a successor of RFC5617, if there ever will be one. Or
on another future 'policy' document.
+1
--
J.D. Falk
the leading purveyor of industry
On May 15, 2011, at 8:44 AM, John R. Levine wrote:
Hi Hector,
At 15:20 14-05-2011, Hector Santos wrote:
Shouldn't the MLM I-D say something regarding C14N and CR/LF related
mutations?
No.
+1 to the No.
+1 to the No.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric
, for all those messages where l= doesn't cover
the whole body, what's in the naked part.
Agreed.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf
operator decide, since that person knows
whether or not the list software will tend to break signatures on messages it
re-sends.
Or if they don't know, this will encourage them to find out.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
: [ietf-dkim] Ticket #24
I appreciate the work that Doug and Charles put into their proposal,
but for reasons already discussed, I think we should leave section
6.1 as is in -09.
+1. Sections 3.8, 8.14 and 8.15 already say enough about this issue.
+1
--
J.D. Falk
the leading purveyor
this attack, signers should be wary of using
this tag, and verifiers might wish to ignore the tag,
{DKIM 2} perhaps based on other criteria./t
I'm worried that without this, a neophyte won't see what the attack is.
+1
+1
--
J.D. Falk
clear that all the SHOULD ignore are not conflicting
with this.)
Works for me.
+1
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
that
the length extends to the closing MIME boundary string.
Also delete the subsequent INFORMATIVE IMPLEMENTATION NOTE.
The note earlier in the section says the bad guy can replace the displayed
contents, so I don't think we need to say it again.
+1 to three changes above.
--
J.D. Falk
the leading
On Apr 20, 2011, at 4:36, bill.ox...@cox.com wrote:
Indeed lack of support for 3rd party signers was where I gave up any interest
at all in adsp
As I remember it, there was (or appeared to be) consensus to get ADSP out there
for testing by the entities it might work for, AND simultaneously
vendors spreading FUD
about ADSP? Press releases, blog posts, even links to mailing list archives.
It's possible that it happened, but if so I'd really like to know who was doing
it.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
page?
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
about as well as it
could be addressed, and see no advantage in rearguing it.
+1
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Apr 12, 2011, at 1:14 PM, Barry Leiba wrote:
Please post minor editorial things to this thread.
In 3.1, the examples of selectors are january2005 and february2005 and
such, which clearly shows the age of the text. Maybe update 'em to 2011?
(This may be the most minor nit ever.)
--
J.D
On Apr 12, 2011, at 6:03 PM, John R. Levine wrote:
Per Murray's request, here's just the changes to take out the verifier
message editing
+1 to these changes.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL
considerations section also explicitly refer to (see
also...) the security considerations from [DKIM], [ADSP], et cetera?
Appendix A: I prefer J.D. rather than JD, though neither is technically
accurate.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
On Apr 13, 2011, at 12:07 PM, Dave CROCKER wrote:
On 4/13/2011 10:31 AM, J.D. Falk wrote:
I'm generally in favor of updating the document to match the current state
of IDN and EAI work, but I don't know it well enough to comment
intelligently on whether John's proposed text does so
more.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
the end-product.
Much appreciated.
+1
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Jan 11, 2011, at 4:12 AM, Eliot Lear wrote:
2. The mechanisms in DOSETA were designed for DKIM. If we are generalizing
along the lines that Dave has mentioned, I would prefer that DOSETA in
particular not advance to draft status, as it ought to be tested in at least
two separate
On Jan 7, 2011, at 3:48 PM, Rolf E. Sonneveld wrote:
• it has taken some four years to make DKIM what it is now. And with
that, I don't mean the protocol specification itself, but I mean adoption,
deployment, acceptance of DKIM, the level of knowledge about DKIM within
organizations,
On Nov 8, 2010, at 1:20 AM, Barry Leiba 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
that the messages
On Oct 16, 2010, at 9:36 AM, Alessandro Vesely wrote:
*scope*
Apparently, there is consensus that Discussion lists and broadcast
lists are not the same thing [WV]. Section 3.2 exemplifies
newsletters and bulk marketing mail as authoring MLM modes. In
facts, most of the advice covers
On Oct 21, 2010, at 11:01 AM, Steve Atkins wrote:
On Oct 21, 2010, at 9:53 AM, Murray S. Kucherawy wrote:
Take a tour through the eleven parts of Section 7 of RFC5451, and then
Appendices A and C. They provide all kinds of warnings about
misinterpreting the data provided, which amounts
On Oct 14, 2010, at 5:09 AM, Dave CROCKER wrote:
On 10/13/2010 1:52 PM, Jim Fenton wrote:
I propose removing section 3.6.1.1 in its entirety.
Not only do I support this, but I think we can remove all references to
DomainKeys, except for the obvious historical reference to its role as input
On Oct 13, 2010, at 1:59 PM, Mark Delany wrote:
On Wed, Oct 13, 2010 at 04:09:34PM -0400, MH Michael Hammer (5304) allegedly
wrote:
Having said that, if an MUA is going to present an indication of
DKIM PASS to the enduser, then a reasonable person would expect
some relationship between
On Oct 5, 2010, at 4:45 PM, Michael Thomas wrote:
On 10/05/2010 01:36 PM, John Levine wrote:
Still, though, it's a solution to deal with malformations to which
MUAs are susceptible, and not strictly a DKIM problem.
Would it be a good idea to recommend in 4871bis that DKIM
implementations
On Oct 6, 2010, at 1:22 AM, Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Mark Delany
Sent: Tuesday, October 05, 2010 8:06 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] THIS IS A
On Oct 4, 2010, at 5:06 PM, John R. Levine wrote:
to Draft Standard. Everyone please review it, and post
comments/issues. Please also post here if you've reviewed it and think
it's ready to go.
I have reviewed it, and it looks ready to go.
+1
Regarding Hector's complaint, I think a
On Sep 24, 2010, at 11:05 AM, John Levine wrote:
Do concepts generalize enough to allow issuing
draft-ietf-dkim-mailinglists also for these authoring MLMs?
No. All of the complications in mailing lists arise from the fact
that the author of the message is not related to the operator of the
On Sep 15, 2010, at 2:35 PM, IETF I-D Submission Tool wrote:
Filename: draft-lindsey-dkim-mailinglists
Nice work. I totally understand what you're trying to do there, and it all
seems consistent with the idea of separating things that have been tried from
things that haven't been tried.
On Sep 16, 2010, at 11:03 AM, Alessandro Vesely wrote:
On 16/Sep/10 13:05, MH Michael Hammer (5304) wrote:
Ian, this makes no sense to me. If a signing domain is concerned enough
to choose to implement ADSP, why would they reduce what they are signing
to accommodate a small percentage of
On Sep 16, 2010, at 5:58 AM, bill.ox...@cox.com bill.ox...@cox.com wrote:
we can discuss it for the very reason you pointed out, people want to
use/sell 3rd party signing, so lets discuss a policy and write it up. I know
my company wants one and I suspect a few others might as well. I know
On Sep 17, 2010, at 2:50 PM, Murray S. Kucherawy wrote:
If this is primarily a workaround for perceived limitations of
reputation systems, then I humbly suggest that the premise is invalid.
Today's reputation systems aren't static; the operators are constantly
changing them in reaction to
On Sep 15, 2010, at 7:16 AM, McDowell, Brett wrote:
It was my understanding that the MLM BCP was intended to inform MLM operators
of what they should do with DKIM-signed mail.
More of what they COULD do than what they SHOULD do, IIRC.
And, that may provide a path to compromise: keep
On Sep 14, 2010, at 9:52 AM, Murray S. Kucherawy wrote:
I don't think ADSP discardable means simply throw it away because it
leaves out the ifs that are supposed to be in front of it. That simplified
interpretation presupposes the message will pretty much always arrive signed
but not
...but not for the reasons the anti-ADSP folks keep bringing up.
DKIM is failing because every discussion about actually /using/ DKIM inevitably
gets stuck in the same old argument about ADSP. Doesn't even matter what the
argument is about anymore; it stops all forward progress every time.
On Sep 10, 2010, at 7:08 PM, John Levine wrote:
Beyond that, you're right, we're at best guessing and at worst pulling
stuff out of our whatevers.
But if that stuff was signed before entering our whatevers, how can we verify
the signature when pulling it out? This question may entirely
On Sep 10, 2010, at 12:34 PM, John R. Levine wrote:
The problem is that too many people on this WG take the view I believe in
solution-X (TPA, PGP-MIME, don't use ADSP because it's broke, don't use
mailing list if you advertise 'discardable') and I will vote down any
solution other than X.
On Sep 10, 2010, at 6:55 AM, Jeff Macdonald wrote:
http://feedbackloop.yahoo.net/
Step 2 doesn't help. (yes, you can put * for all selectors, but asking for
one when it isn't really needed leads to FUD).
That's a complaint feedback loop. Totally separate system.
(Yes, some mailbox
On Sep 10, 2010, at 2:53 PM, J.D. Falk wrote:
On Sep 10, 2010, at 12:34 PM, John R. Levine wrote:
The problem is that too many people on this WG take the view I believe in
solution-X (TPA, PGP-MIME, don't use ADSP because it's broke, don't use
mailing list if you advertise 'discardable
On Sep 9, 2010, at 9:57 AM, Mark Martinec wrote:
Rumor has is that some large players (such as Yahoo!) are
disregarding such ephemeral property of a selector and
are trying to associate a reputation scheme based on both
the domain *and* the selector.
That rumour is based on a presentation I
On Sep 2, 2010, at 11:54 AM, Hector Santos wrote:
I think the issue is that we don't know what the assessors do
Some of us have a pretty good idea. The people who design reputation systems
don't do so in a vacuum; they're constantly reacting to spammers' latest
tricks. If massive
On Aug 30, 2010, at 11:36 PM, Daniel Black 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.
(This is not to say that I disagree with the recommendations
On Aug 30, 2010, at 11:03 AM, Murray S. Kucherawy wrote:
So can I please get some +1s/-1s on each of the following:
(1) Split the document into three documents: A DKIM MLM BCP that discusses
signing and verifying in the context of MLMs with no value-add items
addressed, a DKIM MLM
On Aug 24, 2010, at 1:07 PM, MH Michael Hammer (5304) wrote:
-Original Message-
From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl]
[ . . . ]
We should not change the
essentials of DKIM for sake of MLM transparancy; the best we can do is
document the status quo of the
On Aug 4, 2010, at 9:51 AM, John Levine wrote:
I'd like to back up a minute and try to understand better what (if any)
problem we're trying to solve here. So here is a straw poll.
Assuming you do any sorting of inbound mail at all, how do you treat
mail from lists to which you have
On Aug 1, 2010, at 3:43 PM, Murray S. Kucherawy wrote:
This makes at least the third time this has been suggested by someone. I
believe (though I'm willing to be corrected) that the draft should therefore
cover this possibility and either advocate it or explain why it's a bad idea.
The
On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote:
--On 26 July 2010 18:24:34 +0200 J.D. Falk jdfalk-li...@cybernothing.org
wrote:
I think it's because, when you implement most protocols, if your end is
broken then you can't even talk to the other end. With ADSP, if your end
is broken
On Jul 26, 2010, at 9:13 PM, Douglas Otis wrote:
A vouching service is unlikely to offer a fix either. How would a
vouching service know better than the Author Domain?
They wouldn't, so a smart vouching service would be working WITH the author
domain to get it right. But that's a business
On Jul 27, 2010, at 10:33 AM, Douglas Otis wrote:
Companies are good at shooting themselves in the foot in respect to
helping bad actors phish. (blush) The other foot injury involves their
email being rejected or discarded. Unfortunately, these two goals are
in conflict when making ADSP
On Jul 25, 2010, at 11:36 AM, Murray S. Kucherawy wrote:
I've engaged some of you off-list trying to understand why ADSP is
fundamentally different than the private agreements known to exist between
PayPal and some large email service providers. I get the philosophical
arguments, but from
On Jul 14, 2010, at 10:34 AM, Dave CROCKER wrote:
Does anyone know of an open-source module that is used to develop a
reputation
table by watching traffic and correlating spamminess with the original IP
Address?
All of the reputation systems I'm aware of are custom. The MAAWG paper on
in the MARF WG, but since it's in aggregate it
probably wouldn't fit in that WG anymore. Would it fit here?
Also: have we beaten the recent ADSP arguments into the ground, or is there
something we could accomplish in person that we didn't on the list?
--
J.D. Falk jdf...@returnpath.net
Return
On Jun 21, 2010, at 1:00 PM, John R. Levine wrote:
As threatened, here's an I-D that says how one would publish a list of
domains for which it makes sense to discard unsigned mail.
Looks like a good start, and almost shockingly simple. Any MTA/MFA support
yet? *grin*
--
J.D. Falk jdf
On Jun 22, 2010, at 11:28 AM, Michael Thomas wrote:
On 06/22/2010 09:46 AM, J.D. Falk wrote:
On Jun 21, 2010, at 1:00 PM, John R. Levine wrote:
As threatened, here's an I-D that says how one would publish a list of
domains for which it makes sense to discard unsigned mail.
Looks like
be very useful in determining what (if anything) needs to be changed in ADSP.
Until then, we keep going in circles
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
were discovered to be going into
their spam folder, and falling for bank phishing messages there.
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
that their implementation would be okay
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to, for example, clear the buffer or
reset the state table, causing the information in the buffer to be
discarded and the state to be returned to some previous state.
5321 uses discard or discarded in other places, too.
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
send messages to mailing lists. I'd
like to know why they thought it was okay. Then, we'll know.
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
addition to the BCP document.
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
Count me as interested in a WG meeting in Maastricht, and I expect to have time
available to edit/review/participate/etc between then and Beijing (which I
probably won't be able to attend.)
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
issues, but it might clarify 'em somewhat.
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
without affecting the rest of the document, I think.
I think it should stay, primarily as a way to prevent confusion from people who
think the authoring/one-way-blast MLM is the only important use of email.
(I'm sure you know some people like that)
--
J.D. Falk jdf...@returnpath.net
Return Path
pretty obvious.) But it's all the places in between
that get complicated -- particularly when MLM developers are (in my experience)
notoriously slow to add features.
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL: This list operates
tend to use ESP - Email Service Provider.
I used to use ESP, but it may be confused with email marketing
services. ISP may mean network provider. Mailbox provider is the
less ambiguous term, IMHO.
+1
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
the riskier suggestions.
I believe that is the exact consensus conclusion we came to when discussing
ADSP discardable the first time.
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
and
not the forest. This may not be the best way to extrapolate recommended
best practices.
Agreed. Absolutely.
Another real question, equally important: who is actually writing this BCP?
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL
as with IP reputation.
(Which pushes it even further out of scope, I believe.)
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
relevant aggregated data within that
timeframe, and participate in the discussions. Not sure if I'll have the time
to lead any of the proposed efforts.
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL: This list operates according
this can be done in parallel, so November IETF.
+1
--
J.D. Falk jdf...@returnpath.net
Return Path Inc
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
the same requirement.
8. Collect data on deployment and effectiveness of ADSP, and consider
future of ADSP
Yes to collecting data on deployment, but it's far too early to draw any
conclusions about effectiveness.
Also, FWIW: yes to meeting in Anaheim.
--
J.D. Falk jdf...@returnpath.net
Return Path
J.D. Falk wrote:
Franck Martin wrote:
Can anyone can point me to one or two domains with published adsp records?
My personal domain, cybernothing.org, is surely one of the very few domains
to publish ADSP and also participate heavily in discussion lists like this
one.
_adsp_
text = dkim=all
I haven't encountered a single problem with that configuration.
The handful of small Mailman lists I host on this server get a DKIM
signature on the way out, no problems there either.
(This is purely anecdotal, not intended to replace serious testing by
serious people.)
--
J.D
operational experience here.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
were discussing
when developing ADSP.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
of users of ADSP,
no practice can be said to be common.
A considerations for use document might help, though I'm not sure what it
could say that the RFC doesn't already cover.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list
Murray S. Kucherawy wrote:
Oh, I can list a pretty large number of mail-related RFCs, some of them
standards track, that are not universally implemented and the world hasn't
blown up yet.
Maybe the world will only blow up after we argue about this for another few
years?
--
J.D. Falk
hector wrote:
IMTO, before any automated concept can work well, the supportive DKIM
network must expect protocol consistency to be established among all
DKIM nodes.
Why are we arguing about it now, then? It'll be years until we reach that
point.
://www.circleid.com/posts/dkim_for_discussion_lists/
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
considerations for... drafts before there's anything close to a BCP.
So, where does that leave the DKIM WG? I think it leaves us exactly where
we were before: reputation assessment is, and should be, out of scope.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net
Franck Martin wrote:
Seems to me something is missing: gather data to establish if DKIM
specifications have in any way alleviated any misuse of the email system, in
particular but not limited to spam, phishing attacks and fraud.
What would that prove, or disprove?
--
J.D. Falk
Return Path
Barry Leiba wrote:
Please comment on it. If you like it, please say so.
I like it.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
of such are.
And, there are others in progress.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
reputation recently, trying
to avoid piling on to the hyperbolic misrepresentations so common on other
email marketing blogs:
http://www.returnpath.net/blog/2009/07/domain-reputation-what-it-mean.php
--
J.D. Falk
Return Path Inc
http://www.returnpath.net
://www3.ietf.org/proceedings/75/slides/dkim-0.pdf
other docs: http://tools.ietf.org/agenda/75/docs/dkim.tar.gz
audio: http://feed.verilan.com/ietf/stream06.m3u
jabber: xmpp:d...@jabber.ietf.org?join
jabber logs: http://jabber.ietf.org/logs/dkim
--
J.D. Falk
Return Path Inc
http
is used in phishing attempts, or similar forgeries.
However, that's the only type of feedback you've mentioned which is related
to DKIM. I'm not sure it makes sense to tie the rest to a DKIM key record.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net
ideals might once have been, but this
particular windmill was rebuilt as a pea soup restaurant decades ago.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
of a popular reputation assessment
service.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Michael Thomas wrote:
There is *NO* *REASON* to strip signatures. NONE.
In fact it is HARMFUL.
You are clearly *VERY* *PASSIONATE* about this, but would you care to share
the logic you used to come to this conclusion?
--
J.D. Falk
Return Path Inc
http://www.returnpath.net
point:
http://www.circleid.com/posts/dkim_for_discussion_lists/
It's so simple and obvious (once you move from theory to practice) that I'm
not sure if it's worth the WG's time.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL
by the facts,
+1
+1 again, in case the facts overrode my previous.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Murray S. Kucherawy wrote:
On Thu, 28 May 2009, Barry Leiba wrote:
3. A few Yes, adding this is groovy, messages would be good and all.
Yes, adding this is way groovy.
+1
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL
1 - 100 of 170 matches
Mail list logo
