--- Scott Kitterman <[EMAIL PROTECTED]> wrote:
> I guess that depends on exactly what we are talking about. Some
> messages are pretty well inherently abusive while others it depends on
> the context.
>
> If it's a message that has some inherent characteristic that makes it
> abusive (it's fr
--- Scott Kitterman <[EMAIL PROTECTED]> wrote:
> Frankly all this discussion about let's go get the guy that signed the
> message makes me really wonder why I would ever want to sign a message.
> Back to my hobby horse of the week for a moment, unless you offer a
> benifit to the sender, the
On Aug 23, 2005, at 8:09 PM, Earl Hood wrote:
On August 23, 2005 at 16:13, Douglas Otis wrote:
Let's take a real-world example. CPAN provides a permanent email
address for all CPAN account holders. CPAN account holders specify
where to forward all messages address to their CPAN addresses.
Th
Earl Hood wrote:
On August 23, 2005 at 13:53, Jim Fenton wrote:
This goes to what we have been very generically calling first-party and
third-party signatures. The original submission of a message would
normally result in a first-party signature from the supposed author's
domain. A mail
[EMAIL PROTECTED] wrote:
--- Scott Kitterman <[EMAIL PROTECTED]> wrote:
So in your view, what is the accountability entity for a message sent to
you, the MUA/MSA/MTA that signed the message or the MTA that sent you
the message if they aren't the same?
One definition of accountability might
--- Earl Hood <[EMAIL PROTECTED]> wrote:
> Any "accountability" should be explicitly defined.
In the negative sense, let me suggest that an accountable entity is one who can
best stop the traffic
if you don't want it.
If we take a leap of faith that what you don't want is the content, then maybe
--- Scott Kitterman <[EMAIL PROTECTED]> wrote:
> So in your view, what is the accountability entity for a message sent to
> you, the MUA/MSA/MTA that signed the message or the MTA that sent you
> the message if they aren't the same?
One definition of accountability might be; which party is best
On August 23, 2005 at 20:06, Dave Crocker wrote:
> > > Should a forwarder (e.g. college alumni permanent address service) have
> > >
> > > the same level of accountability as the originating domain (the domain
> > > that received the initial submission of a message)?
> > >
> > I don't see why
Dave Crocker wrote:
Let's remember that the primary role for this signature is as input to a
delivery filtering process. So the nature of the 'accountability' is inherently
narrow.
That's one view. I view that role as entirely secondary to the
potential for DKIM to restrict certainly class
--- John R Levine <[EMAIL PROTECTED]> wrote:
> > Should a forwarder (e.g. college alumni permanent address service) have
> > the same level of accountability as the originating domain (the domain
> > that received the initial submission of a message)?
>
> I don't see why not. If they're sending
Yes, yes, yes. I agree completely here.
--
Arvel
- Original Message -
From: "Jim Fenton" <[EMAIL PROTECTED]>
To: "Tony Finch" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, August 22, 2005 11:29 PM
Subject: Re: [ietf-dkim] proposed threat analysis outline
Tony,
While I like your outline
On August 23, 2005 at 16:13, Douglas Otis wrote:
> > DKIM should provide the mechanism to facilitate accountability in
> > an acceptably reliable fashion.
> >
> > Therefore, you are implying that domains may practice policies that
> > selectively sign messages based on what they want to account fo
On 23 Aug 2005 22:42:50 -0400, John R Levine wrote:
> > Should a forwarder (e.g. college alumni permanent address service) have
> >
> > the same level of accountability as the originating domain (the domain
> > that received the initial submission of a message)?
> >
> I don't see why not. If t
> If the DKIM specification explicit states that it provides an
> accountable identity for a message without mentioning what is
> involved for being accountable, then you may get adoption problems.
That hasn't been a problem up to now. I get the impression that most
people anticipate doing triage
On August 23, 2005 at 13:53, Jim Fenton wrote:
> This goes to what we have been very generically calling first-party and
> third-party signatures. The original submission of a message would
> normally result in a first-party signature from the supposed author's
> domain. A mailing list would
>(and today ain't over yet). Since July 26 when I first released it there
>have been 65,392 downloads of it.
Well, that's encouraging.
>The problem I have is that I can't populate DNS with the required entries
>for my customers automagically and they are mostly all incapable of doing
>this on
On August 23, 2005 at 10:09, Ned Freed wrote:
> It seems to me that the underlying disagreement here has to do with the
> term "signature". In DKIM signatures are nothing but a means to an end:
> They provide the means of attaching an accountably identity to a specific
> message.
I am uncertain a
>I don't think DKIM should preclude MUA signing of authored content.
It doesn't. If the MUA wants to apply an S/MIME or PGP signature, it
can do so, same as always.
Since we already have those two signature systems, it's not obvious to
me what the benefit would be of adding their function into D
I think we're in violent agreement. I don't see anything
particularly wrong with SSP, but as far as I know it's still
just a paper design which makes it a poor candidate
for standardization at this point.
I can shed some light on that point. I've got thousands of domains using
DKIM (that mean
> [mailto:[EMAIL PROTECTED] On Behalf Of Keith Moore
> Now maybe we could get businesses to sign their messages with
> S/MIME or
> OpenPGP and solve the phishing problem that way, but somehow I don't
> think they'll go for it. And for any of this to work we need
> widespread
> buyin. If th
On Aug 23, 2005, at 12:24 PM, Tony Finch wrote:
http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-
dkim-rationale.txt
4.1. Hostname (RFC 2821 EHLO)
I agree HELO is currently is not properly configured in many cases,
and RFC 2821 allows this situation.
HELO verificati
>> Same starting line for both, not necessarily the same finish line.
>
>That's been my expectation all along. That was reflected
>in the proposed charter.
I think we're in violent agreement. I don't see anything particularly
wrong with SSP, but as far as I know it's still just a paper design
whi
So only include that token on the BCC copy.
> -Original Message-
> From: Michael Thomas [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 23, 2005 5:11 PM
> To: Hallam-Baker, Phillip
> Cc: Tony Finch; Keith Moore; ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] BCC Recipients
>
>
> Ha
On Aug 23, 2005, at 12:49 PM, Earl Hood wrote:
On August 20, 2005 at 18:21, Douglas Otis wrote:
DKIM should provide the mechanism to facilitate accountability in
an acceptably reliable fashion.
Therefore, you are implying that domains may practice policies that
selectively sign messages based
I thought you said that DKIM is the transmission signature and that
S/MIME and OpenPGP offer the authoring signature. Did I misunderstand you?
Clearly S/MIME and OpenPGP try to provide an authoring signature. They
don't seem to have been very successful, for reasons that appear to be
related
Keith Moore wrote:
Part of the idea that DKIM seems to propose is that more than one
party can potentially sign a message. For instance, an author
might sign a message, or a list might sign the same message. But
different parties mean different things when they sign the message.
If the author
For those who don't know, I've implemented and deployed the full DKIM
(base+SSP) some weeks ago in a new version of my MTA.
My customers are reporting that they are receiving DKIM signed messages from
"s=2005; d=replies.em.bankofamerica.com". These message successfully
interoperate. I have o
no, it "just" means that the MTA has to transmit multiple copies of the same
message to the same SMTP server, differing only in their signature and bcc
header field.
And this breaks existing email functionality (the multiple recipient
optimization) which contradicts one of our goals.
Only for
no, it "just" means that the MTA has to transmit multiple copies of
the same message to the same SMTP server, differing only in their
signature and bcc header field.
My understanding is that BCC should not be seen in SMTP transmission,
except first hop when SMTP is used in place of SUBMIT.
Part of the idea that DKIM seems to propose is that more than one
party can potentially sign a message. For instance, an author
might sign a message, or a list might sign the same message. But
different parties mean different things when they sign the message.
If the author signs a message, it m
Keith Moore wrote:
>>I think that authors that want to protect their reputations can
arrange for
their messages to have DKIM authorship signatures, and also advertise
(say via
DNS) that their messages will have such signatures. Whether this is
done via
an MUA, or via a special submission ser
Scott Kitterman wrote:
Ned Freed wrote:
It appears to me that there are those who do not want SSP for reasons
that aren't clear to me. I'd rather get SSP in scope once and for all
and not have to have the scope arguement again after base is published.
Same starting line for both, not necessa
Hallam-Baker, Phillip wrote:
Or something of that nature. That means that the BCC recipient can
verify it was sent to them while preventing any To: or CC: recipient
knowing anything more than that there is a BCC.
That in and of itself seems like a breach of BCC semantics.
I'd be very alarmed j
> -Original Message-
> From: william(at)elan.net [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 23, 2005 3:33 PM
> To: Hallam-Baker, Phillip
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] BCC Recipients
>
>
>
> On Tue, 23 Aug 2005, Hallam-Baker, Phillip wrote:
>
> >> This
Going back a lot of messages, but only a few hours (apologies if I'm
beating a dead horse):
Keith Moore wrote:
Part of the idea that DKIM seems to propose is that more than one
party can potentially sign a message. For instance, an author might
sign a message, or a list might sign the same m
On Tue, 23 Aug 2005, william(at)elan.net wrote:
>
> Therefore I do not understand how can MTA possibly transmit multiple
> copies "differing in their signature and BCC heaader field".
You should re-read the discussion in RFC 2822 section 3.6.3 about the
three ways in which BCC can be used, in part
OTOH, right now SSP is nowhere near as well thought out as DKIM is.
You mean "right now DKIM-SSP is nowhere near as well though out as
DKIM-base".
I tend to think the approach of DKIM first, SSP next is best.
You mean "I tend to think the approach of DKIM-base first, DKIM-SSP next is
best
Exactly! Well said Scott!
--
Arvel
- Original Message -
From: "Scott Kitterman" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, August 23, 2005 2:08 PM
Subject: Re: [ietf-dkim] Not exactly not a threat analysis
Ned Freed wrote:
DKIM without SSP is useful, but SSP adds significant value.
On August 20, 2005 at 18:21, Douglas Otis wrote:
> > It appears your discussion of accountability is really something that
> > sits on top of DKIM, since trying to standardize "accountability"
> > seems impractical.
>
> I do not understand what you mean by standardized accountability.
> Either th
On Tue, 23 Aug 2005, Keith Moore wrote:
no, it "just" means that the MTA has to transmit multiple copies of the same
message to the same SMTP server, differing only in their signature and bcc
header field.
My understanding is that BCC should not be seen in SMTP transmission,
except first hop
--- Ned Freed <[EMAIL PROTECTED]> wrote:
> THe term I prefer is "accountable". "Responsible" goes a bit too far in this
> context since it carries with it some connotation of authorship.
...
> DKIM isn't supposed to provide a general content signing service, or a
general
> nonrepudiation service
On Tue, 23 Aug 2005, Hallam-Baker, Phillip wrote:
This doesn't help for BCC recipients at the same domain.
The only way to sign BCC in my view is to provide a per user signature
constructed by means of an HMAC.
For example message is "Hello World", Sending it to [EMAIL PROTECTED]
So I const
On Tue, 23 Aug 2005, Hallam-Baker, Phillip wrote:
>
> * The cost of running spam filtering systems is very high for the
> largest ISPs and for providers of spam filtering services. This cost
> could be significantly reduced if there was a better way to identify the
> good incoming mail. Signing
On Tue, 23 Aug 2005, Ned Freed wrote:
>
> The real question is how this affects the threat analysis. I think SSP
> needs to be part of the analysis, but we need to be clear when we're
> talking about base DKIM and when we're talking about SSP. That way we
> know which benefits (and risks) accrue fr
On August 20, 2005 at 17:14, Douglas Otis wrote:
> > You can't stop forgery without stopping forgery. Some things that are
> > perhaps technically forgery are considered desireable. Other things
> > that aren't forgery might be affected by forgery prevention protocols.
>
> Stopping forgery re
> This doesn't help for BCC recipients at the same domain.
The only way to sign BCC in my view is to provide a per user signature
constructed by means of an HMAC.
For example message is "Hello World", Sending it to [EMAIL PROTECTED]
So I construct a BCC identifier HMAC ("[EMAIL PROTECTED]", SHA1
On Tue, 23 Aug 2005, Keith Moore wrote:
>
> no, it "just" means that the MTA has to transmit multiple copies of the same
> message to the same SMTP server, differing only in their signature and bcc
> header field.
And this breaks existing email functionality (the multiple recipient
optimization) w
Title: Message
My threat analysis
has a rather different starting place. My objective is not so much to solve a
particular problem as to identify a 'killer application' where there
is:
A clearly
understood pain point.
A core constituency
that is directly affected by the pain point
Ned Freed wrote:
DKIM without SSP is useful, but SSP adds significant value. OTOH, right
now SSP
is nowhere near as well thought out as DKIM is. So, in the interests of
getting
things done, I tend to think the approach of DKIM first, SSP next is best.
Divide and conquer has often proved to be
However the submission server cannot trivially include the list of
recipients in the message signature and remain compatible with BCC (which
is one of our requirements).
Sure it can. Any recipient in the envelope but not in the message header gets
a separate signature. Easiest thing to do is t
On August 19, 2005 at 23:23, Keith Moore wrote:
> The point is that, for a variety of reasons, From really has no implied
> relationship with who sent the message, and has only a tenuous
> relationship with who wrote the message. People have stood on their
> heads trying to reconcile this wit
>>I think that authors that want to protect their reputations can
arrange for
their messages to have DKIM authorship signatures, and also advertise (say via
DNS) that their messages will have such signatures. Whether this is done via
an MUA, or via a special submission server, or whatever, is up
Ned Freed wrote:
> Now, if at some point in the future, after this group is done and has "walked
> into absence", it makes sense to reuse some or alll of DKIM to provide some of
> these other services in lieu of using S/MIME, PGP or whatever, that's fine.
> Incremental development is A Good Thi
On Tue, 23 Aug 2005, Keith Moore wrote:
>
> I don't think DKIM should preclude MUA signing of authored content.
Agreed.
> > However the submission server cannot trivially include the list of
> > recipients in the message signature and remain compatible with BCC (which
> > is one of our requiremen
>>I think that authors that want to protect their reputations can
arrange for
their messages to have DKIM authorship signatures, and also advertise (say via
DNS) that their messages will have such signatures. Whether this is done via
an MUA, or via a special submission server, or whatever, is up
> [mailto:[EMAIL PROTECTED] On Behalf Of Russ Housley
> Keith:
>
> I thought you said that DKIM is the transmission signature
> and that S/MIME
> and OpenPGP offer the authoring signature. Did I misunderstand you?
>
> If there is consensus on this point, then this helps set the
> scope for t
Ned Freed wrote:
Now, if at some point in the future, after this group is done and has "walked
into absence", it makes sense to reuse some or alll of DKIM to provide some of
these other services in lieu of using S/MIME, PGP or whatever, that's fine.
Incremental development is A Good Thing. But w
On Tue, 23 Aug 2005, Keith Moore wrote:
>
> I think that authors that want to protect their reputations can arrange for
> their messages to have DKIM authorship signatures, and also advertise (say via
> DNS) that their messages will have such signatures. Whether this is done via
> an MUA, or via a
>> no, you keep claiming that I'm wrong, while misrepresenting what I'm
>> proposing. I don't think you're convincing anyone.
>
>
> Keith, I don't mean to be rude, but I think you have this backwards. I
> think you have been wrong from the outset and nothing you have said has
> convinced me oth
> Now, Keith will no doubt argue that DKIM is of marginal value at best unless
we
> extend it into these areas. Simply put, I disagree. For example, even in the
> absence of SSP DKIM at a minimum provides a service that can make
> whitelisting/blacklisting far more reliable.
I strongly disagre
On August 19, 2005 at 13:18, Eric Allman wrote:
> First, by itself, DKIM is not an anti-phishing tool and is definitely
> not an anti-spam tool.
Then the DKIM specification should be careful when refering to
such things. Since the current draft states that DKIM could assist
in dealing with phis
On Aug 23, 2005, at 10:55 AM, Keith Moore wrote:
Some blacklists are more responsible than others, but I haven't yet
seen one that, if trusted to block mail, doesn't block a
significant amount of legitimate mail.
One advantages of DKIM in this regard, is that when reputation can
fully mo
A submission server might be in a good position to sign a message on behalf of
the submitter, but it seems awkward at best to expect a submission server to
distinguish between original messages and re-sent messages.
Which implies that you think that it's impossible to implement your tag in
a no
On Aug 23, 2005, at 8:47 AM, Keith Moore wrote:
Concluding there is significance for a mailbox address assumes
mailbox-
addresses are normally constrained by the signing domains, or that
DKIM
establishes an appendage of mailbox-address authorizations. It also
seems you want this to include
On Tue, 23 Aug 2005, Keith Moore wrote:
>
> A submission server might be in a good position to sign a message on behalf of
> the submitter, but it seems awkward at best to expect a submission server to
> distinguish between original messages and re-sent messages.
Which implies that you think that
Keith:
I thought you said that DKIM is the transmission signature and that S/MIME
and OpenPGP offer the authoring signature. Did I misunderstand you?
If there is consensus on this point, then this helps set the scope for the
DKIM threat analysis and charter.
Russ
At 11:47 AM 8/23/2005, Ke
no, you keep claiming that I'm wrong, while misrepresenting what I'm
proposing. I don't think you're convincing anyone.
Keith, I don't mean to be rude, but I think you have this backwards. I
think you have been wrong from the outset and nothing you have said has
convinced me otherwise.
O
If you can show that publishing base will in no way cripple or weaken SSP
then I for one will get behind your plan. If you can't, I and others
won't. That is the debate here.
This was not fair of me to say because it is not possible to prove a
negative. My apologies Dave, and everyone.
Wh
Now, Keith will no doubt argue that DKIM is of marginal value at best unless we
extend it into these areas. Simply put, I disagree. For example, even in the
absence of SSP DKIM at a minimum provides a service that can make
whitelisting/blacklisting far more reliable.
I strongly disagree. If DKI
The primary deployment scenario for DKIM is to do the signing on the
submission server, so the signature doesn't necessarily identify the
message's author. I'd say the tag you want has at least three settings:
author / submission server / re-sender
A submission server might be in a good position
> > But different parties mean different things when they sign the
> > message. If the author signs a message, it means "I wrote this".
> > If a list signs a message, it means "I sent this".
> Ah, why didn't you just say so two weeks ago? I think you will find
> that you are reading a whole lot
On Tue, 23 Aug 2005, Keith Moore wrote:
>
> If you mean that trusting someone else to decide, on behalf of a large and
> diverse set of users, what is good for all of those users, is a poorly chosen
> policy - then I emphatically agree.
I think that's the only reasonably scalable way to implement
John R Levine wrote:
>>>Right. The context is who signed it.
>>
>>That's not sufficient unless signers who (re)transmit messages are
>>clearly distinguishable from signers who author content.
>
>
> You keep saying that, I keep pointing out that you're wrong. I guess
> we're done.
no, you keep
Keith Moore wrote:
>
> That's not sufficient unless signers who (re)transmit messages are clearly
> distinguishable from signers who author content. That would be a workable
> solution, though I don't think it's desirable to overload addresses in this
> way.
The primary deployment scenario for DK
John R Levine wrote:
Right. The context is who signed it.
That's not sufficient unless signers who (re)transmit messages are
clearly distinguishable from signers who author content.
You keep saying that, I keep pointing out that you're wrong. I guess
we're done.
no, you keep claiming tha
On Tue, 23 Aug 2005, Keith Moore wrote:
> Tony Finch wrote:
> > On Tue, 23 Aug 2005, Keith Moore wrote:
> >
> > > And because "abuse" is subjective (one recipient's spam is another
> > > recipient's useful ad), you end up both legitimizing some amount of
> > > abuse and marginalizing useful and val
> > Right. The context is who signed it.
>
> That's not sufficient unless signers who (re)transmit messages are
> clearly distinguishable from signers who author content.
You keep saying that, I keep pointing out that you're wrong. I guess
we're done.
R's,
John
PS:
> That's a bit like saying
And because "abuse" is subjective (one recipient's spam is another
recipient's useful ad), you end up both legitimizing some amount of
abuse and marginalizing useful and valid behavior.
I don't see any clear signs of the convergence to mediocrity that you
are concerned about,
Well, to me the a
John R Levine wrote:
I concur with Tony's model that a signature only means "I will accept
the blame for this message".
I don't think that flies, or at least, I think that makes DKIM of fairly
marginal value. A message itself is rarely blameworthy; what matters is
the context.
Right. The c
> > I concur with Tony's model that a signature only means "I will accept
> > the blame for this message".
>
> I don't think that flies, or at least, I think that makes DKIM of fairly
> marginal value. A message itself is rarely blameworthy; what matters is
> the context.
Right. The context is
Tony Finch wrote:
On Tue, 23 Aug 2005, Keith Moore wrote:
If you put signing domains in the position of accepting responsibility for any
type of abuse, you do several things. One is that you make it more difficult
for domains to justify signing messages. And because "abuse" is subjective
(one
On Tue, 23 Aug 2005, Keith Moore wrote:
>
> If you put signing domains in the position of accepting responsibility for any
> type of abuse, you do several things. One is that you make it more difficult
> for domains to justify signing messages. And because "abuse" is subjective
> (one recipient's
Concluding there is significance for a mailbox address assumes mailbox-
addresses are normally constrained by the signing domains, or that DKIM
establishes an appendage of mailbox-address authorizations. It also
seems you want this to include some type of path registrations to
regulate forwarding
On Tue, 2005-08-23 at 07:58 -0400, Keith Moore wrote:
> John Levine wrote:
> > I concur with Tony's model that a signature only means "I will accept
> > the blame for this message".
>
> I don't think that flies, or at least, I think that makes DKIM of fairly
> marginal value. A message itself i
Douglas Otis wrote:
On Mon, 2005-08-22 at 21:32 -0400, Scott Kitterman wrote:
Once it gets to the MUA, it's too late. I want to reject the message
during SMTP (after DATA, but before OK).
Your notion seems to consider mailbox address authorization will be the
principle mechanism used to re
John Levine wrote:
But different parties mean different things when they sign the
message. If the author signs a message, it means "I wrote this".
If a list signs a message, it means "I sent this".
Ah, why didn't you just say so two weeks ago?
I think I have said more or less the same thin
On Mon, 22 Aug 2005, Jim Fenton wrote:
>
> While I like your outline quite a bit, my inclination is to stick closer to
> the specific questions that Russ posed (Who are the bad guys and what are they
> capable of? Where are they in the system? What do they want to do?). The
> more that we expand
On Tue, 23 Aug 2005, Frank Ellermann wrote:
> Tony Finch wrote:
>
> > Isn't the i= tag the new identity that Keith is asking for?
>
> Checking the draft, i= is optional, must be below d=, it's not
> required to match anything selected by h=, and it's a "verifier
> policy issue" [XREF TBD] with the
Tony Finch wrote:
> Isn't the i= tag the new identity that Keith is asking for?
Checking the draft, i= is optional, must be below d=, it's not
required to match anything selected by h=, and it's a "verifier
policy issue" [XREF TBD] with the fine print.
I'm not sure, but for Keith's idea the "
On Mon, 2005-08-22 at 21:32 -0400, Scott Kitterman wrote:
> Douglas Otis wrote:
>
> > You wish to include an anti-forgery mechanism directly within DKIM. I
> > fear serious issues will likely derail DKIM deployment when "anti-
> > forgery" mechanisms interfere with normal email, while at the sa
90 matches
Mail list logo