Subject: [Asrg] [Fwd: Yahoo! Mail Publishes Specification for DomainKeys]

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 18 May 2004 21:28:13 -0400

From MARID list.

-------- Original Message --------
Subject: Yahoo! Mail Publishes Specification for DomainKeys
Date: Tue, 18 May 2004 10:46:32 -0400
From: Larry Seltzer <[email-masked]>
To: 'IETF MARID WG' <[email-masked]>

(see http://antispam.yahoo.com/domainkeys in particular)

LJS

Yahoo! Mail Publishes Specification for DomainKeys

E-mail Authentication Solution Filed with IETF;

Alpha Version of Open Source Code Available

WHAT:

On Tuesday, May 18, Yahoo! announces the publication of its 
specification on DomainKeys,
a cryptographic e-mail authentication solution to help fight spam.

DomainKeys: In order to attack spam at its roots, a powerful solution is 
needed that can
verify the identity of the e-mail sender and put an end to spoofing and 
forgery.
DomainKeys help fight spam by providing strong assurance of both the 
sender's identity
and the integrity of the e-mail content through the use of 
public/private key
cryptography.

On Monday, May 17, the company filed the spec as an Internet-draft with 
the IETF
(Internet Engineering Task Force) standards body to begin the 
standardization process.

Additionally, Yahoo! is currently developing a reference implementation 
for DomainKeys
that can be plugged into Message Transfer Agents (MTAs), such as qmail. 
An alpha version
of this software will be released under a royalty free license at 
SourceForge.net.

WHERE:

The specification, license terms and FAQs are posted on Yahoo!'s 
Anti-Spam Resource
Center:  http://antispam.yahoo.com
The alpha version of the software will be hosted at SourceForge.net at:
http://sourceforge.net/index.php

--
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"There is nothing new under the sun" (Eccls. 1:9)

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Chris" <[email-masked]>
Date: Wed, 19 May 2004 12:56:17 +0930

Domian keys works for me :)

Except I believe provision should be made for any intervening MTA's to add
their own Domain Key
thus allowing the injection point be traced for legacy mail systems.

Regards
Chris

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
> Shafranovich
> Sent: Wednesday, 19 May 2004 10:58 AM
> To: ASRG
> Subject: [Asrg] [Fwd: Yahoo! Mail Publishes Specification for
> DomainKeys]
>
>
>  From MARID list.
>

---

From: Barry Shein <[email-masked]>
Date: Wed, 19 May 2004 18:14:52 -0400

FWIW, I still think these sort of approaches might have some utility
with authentication but will have little to no effect on spam so I
wonder why they get so much attention on this list.

As far as I can tell spammers have now become domain registries and
just generate random-appearing, generated domains like www.fxbrezd.com
(or, more often, .info or .somecountryyoudon'twanttoknowmoreabout.)
For example, these whacko domains usually have functioning MX's.

Which means they can just as easily set up SPF or Domain Key or
similar services for those randomly generated domains.

Also, much spam from hijacked PCs seems to use the hijacked
PC's host, as in [email-masked]

That sort of thing will get around these SPF/YDK approaches, right?

And of course there's the whole problem of the envelope vs the header
since these generally check the envelope but the user generally sees
the header so can be spoofed anyhow. I realize this generally prompts
a response about how there's some effort, somewhere, to extend all
this into the header which is passed off as an answer but it quickly
starts to sound like "oh we'll invent that too!" back-patching on an
apparently weak idea.

Again, I don't know for a fact that this is completely useless
technology (like proof-of-work which is useless technology), but I
think it's only potentially useful against certain types of scams,
domain forgeries with malicious intent, in a very weak way, and as
such really has little to nothing to do with spam per se except
inasmuch as we can rationalize that ``anything which comes via email
and might harm or annoy me'' is hereby spam.=

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

---

From: John Levine <[email-masked]>
Date: 19 May 2004 23:00:41 -0000

>That sort of thing will get around these SPF/YDK approaches, right?

No, a valid DK signature tells you that the message really was signed
by the domain in the From: line.  If there's a zombie'd PC at
tiscali.fr, and it sends mail through Tiscali's mail servers using a
tiscali.fr address, and the servers sign it (which, with half decent
volume checks they wouldn't) it'll pass DK checks.

I agree that knowing that mail really came from woifnsdnskensk.com
isn't very useful without a reputation system, but DK at least
validates the actual mail that you see, not the envelope which you
don't.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

-- 
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711
[email-masked], Mayor, http://johnlevine.com, 
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail

---

From: Philip Miller <[email-masked]>
Date: Wed, 19 May 2004 19:13:41 -0400

Barry,
> wonder why they get so much attention on this list.

It will have little immediate effect on the *volume* of spam sent. However, 
it will have an effect on certain characteristics of the spam that is 
received. I'll get into specifics as I go along.

> (or, more often, .info or .somecountryyoudon'twanttoknowmoreabout.)

These types of things could potentially be blacklisted. Has anyone created a 
functioning BL of domain registrars, rather than domains?

> For example, these whacko domains usually have functioning MX's.

Functioning MX's would mean no rejection by Hector Santos's Call Back 
Verification. However, having a functioning MX gives us something beyond a 
domain name: an assigned or hijacked IP address, which can be traced, 
(black/block)listed, and/or dealt with by an upstream provider. It's easier 
to hunt down a real person if you can find where IP packets are being 
routed, compared to having just falsified whois records.

> similar services for those randomly generated domains.

SPF simply says that they control the domain they're using, which is an 
improvement over the present state. In this case, if they're using zombies, 
they need some way to ensure that all of those zombies end up authorized by 
the SPF records. Perhaps SPF lookup libraries should keep a count of the 
total hosts authorized by the domain in question, which could be 
cross-referenced to an external list or other reputation service. I.e. 
domains that list a lot of sending hosts would need a much better reputation 
for their mail to be accepted than domains that list a very restricted set.

> PC's host, as in [email-masked]

And no ISP worth its salt would authorize any host to send as an internal 
host name, so spammers can't play the pin-it-on-the-ISP game.

> That sort of thing will get around these SPF/YDK approaches, right?

Wrong. See above.

> starts to sound like "oh we'll invent that too!" back-patching on an

There's not that much 'invention' to go into it, once something more 
primitive than 2822.From is authenticated. Either messages claiming a given 
domain will only come from hosts that can send return-paths in the domain, 
or there will be others, or they could come from anywhere.
Since only certain hosts are authorized, the domain owner can enforce 
local-part policy, so we need only worry about the domain.

> technology (like proof-of-work which is useless technology), but I
                    ^^^^^^^^^^^^^       ^^^^^^^^^^^^^^^^^^^^^
I still haven't seen proof of that, from you or others...
> and might harm or annoy me'' is hereby spam.

Since this group has largely agreed that a formal, consensus definition of 
spam is non-existent, any methods that can be used to hinder messages that 
any people might not want is in scope as 'anti-spam research'.

You are using useful here to mean 'volume of spam (by my as-yet-unstated 
definition) will decrease'. I and others look at a much broader range of 
things as useful:
1. Practically eliminate receipt of DSNs about messages that were never sent
2. Protect domain owners (both large providers and joe-job targets) from 
accusations of abuse by letting them point to their DNS records and say 'you 
can see from that record that we did not authorize the transmission of that 
message'
3. Provide domain-name level accountability for messages. Really, any 
domain, appearing anywhere in the message, will do, so long as you can point 
to them and say "that domain said that they have no problem with their name 
being attached to this message"

Sincerely,
Philip Miller

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 19 May 2004 19:14:51 -0400 (EDT)

> That sort of thing will get around these SPF/YDK approaches, right?

No; tiscali.fr is unlikely to publish that
dyn-83-155-31-99.ppp.tiscali.fr is an authorized sender of email from
its domain.

Seth

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 19 May 2004 19:23:03 -0400

> similar services for those randomly generated domains.

  <shrug> Blacklist the DNS IP.

> That sort of thing will get around these SPF/YDK approaches, right?

  Yes and no.  It depends on how it's implemented.

> and might harm or annoy me'' is hereby spam.=

  Is there a better suggestion on the table?

  This isn't to say we should do something nonsensical, simply because
it's better than nothing.  But it does have some applicability, a
number of domains are implementing it, and the implementors are strong
proponents.

  Alan DeKok.

---

From: "George Ou" <[email-masked]>
Date: Wed, 19 May 2004 16:29:53 -0700

----- Original Message ----- 
From: "Barry Shein" <[email-masked]>
To: "Chris" <[email-masked]>
Cc: "Yakov Shafranovich" <[email-masked]>; "ASRG" <[email-masked]>
Sent: Wednesday, May 19, 2004 3:14 PM
Subject: Re: [Asrg] 6 - Yahoo Domain Keys

> similar services for those randomly generated domains.

But they only get to spew spam from fxbrezd.com once with their brand
spanking new SPF/CallerID/Domain Key for a few days.  Once it becomes clear
that fxbrezd.com is a spammer, then you permanently blacklist that entire
domain and announce it to the entire world so that no one else will ever
receive mail from fxbrezd.com again.  Yes, they can still register 1000s of
domains, but its a bit more difficult.  From that point on, the registrars
need to be pressured to track these people down and the law needs to
severely penalize them.  Additionally, at least you won't be receiving junk
from the hundreds of thousands of zombies out there.

---

From: Mark Baugher <[email-masked]>
Date: Wed, 19 May 2004 16:30:31 -0700

At 11:46 AM 5/19/2004, William Leibzon wrote:

>Big problem I have with it is that yahoo domain keys breaks with email
>forwarders, mail lists and roaming users (and they fully acknoledge that
>it does not work with them and say there is no good work-around). That
>makes it no-go as far as I concerned for initial deployment unless
>changes are made.

You're assuming that there's no way to fix the break.

>And frankly, I'm less then satisfied after so many promises and lots of
>wait for it. Its long document (which I ready fully) that primarily just
>pounds on rather old idea of entering public key in dns and using private
>key to add signed header to email, this idea had been around for at least
>4 years (possibly more) and I thought they found ways around above listed

What is new is the signing of the header.  I don't believe that this
has been practiced since the days of PGP.  I don't know about PEM.

Mark

>and other similar problems when email content must be changed in process
>of tranmission by intermediate server, but unfortunetly they did not. Nor
>do they address entering keys too well, again we're back to reusing TXT
>(where as what we need is standard for entering public keys in DNS and
>this is needed not only for email but for several others things and in
>general would come usefull, there have been drafts about this actually).
>
>On Tue, 18 May 2004, Yakov Shafranovich wrote:
>
> >  From MARID list.
> >

---

From: Matt Sergeant <[email-masked]>
Date: Thu, 20 May 2004 00:50:38 +0100 (BST)

> validates the actual mail that you see, not the envelope which you

Unless the spec has changed since last time I read it, there's nothing in 
DK to say "mails from this domain are always signed with DomainKeys". 
Without that spammy just has to omit the DK header to get his mail 
through.

The problem as I see it is that DK is a whitelist system (where SPF is
really a blacklist system). It tells you that the mail is "valid"  
according to the signature. Mail without a DK header tells you nothing.

And so once spammers start publishing domainkeys we're pretty much back 
to square 1.

Matt.

---

From: Barry Shein <[email-masked]>
Date: Wed, 19 May 2004 20:52:25 -0400

Without going point by point (because that gets tiresome, fast):

I agree with you that a valid motivation for SPF/DK kinds of solutions
is to "protect" (for some value of protect) domain owners.

I have little doubt that a billion msgs per day (more) get forged with
the domain of ISPs whose names you hear on prime time TV commercials
and many of those cause consequences for those ISPs.

         [just a minute have to block a few hundred stock pumping IP addrs]

Even as a smaller ISP we've suffered such consequences, irate victims,
inappropriate blocking, even subpoenas, etc., when itn the end none of
it ever passed thru here.

None of that, to me, is strictly spam, even if it might be A Good
Thing to eradicate.

Something that has concerned me is...

	  [damn, there they go again, be right back...]

where was I? Oh, right, is exactly this problem of judging what is a
spam problem and what isn't?

For example, should we require a valid DUN identifier to do business
via email?  That's essentially what an SSL certificate is, one has to
present a valid DUN to get a cert. Maybe anyone offering prescription
drugs should be required to include a valid pharmaceutical license.

I'm not going into a libertarian space here, just that fraud etc is a
very, very, very big problem.

And it does drag us further and further into trying to validate the
content of a message, perhaps even its worthiness tho I don't think
that's a problem with SPF/DK per se.

        [Again! ok, that was only 25 /24's blocked, progress?]

I'll leave that on one observation which is to note that neither the
(paper) postal system or phone system has developed a reliable,
general way to authenticate "senders" in over 200 and 100 years
respectively. In the case of the postal system they offer it as an
option (which I suppose is what ANI for the phone system is also) but
I wouldn't view that observation too flippantly.

>> technology (like proof-of-work which is useless technology), but I

We have to prove that something WON'T work now?

           [oh there goes the cheap software jerk...]

How easily we go through the looking glass...

But I believe some compelling criticisms have been raised.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Wed, 19 May 2004 20:57:08 -0400

Well, everyone keeps saying this but I don't particularly see why this
should be the case. I'm sure some, even many, such ISPs will do as you
say but are you really going to vouchsafe for all those broadband and
dialup ISPs currently a source of so many problems? How many tens of
millions of exceptions will we need for the result to be severely
diminished?

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Wed, 19 May 2004 21:01:54 -0400

> from the hundreds of thousands of zombies out there.

The optimism is touching, particularly the part about "the law needs
to severely penalize them". That's a big hole you're filling in with a
worldview that unfortunately hasn't had much credence thus far.

-- 
        -Barry Shein

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 19 May 2004 21:32:36 -0400 (EDT)

Barry Shein <[email-masked]> top-posted:

> dialup ISPs currently a source of so many problems?

The ones that are too fucking cheap, stupid, and/or lazy to do
anything about their infected lusers spamming and emitting worms?
They're going to go to a lot of extra effort to allow their idiot
lusers to spam?  I don't think so.

Seth

---

From: der Mouse <[email-masked]>
Date: Wed, 19 May 2004 23:25:51 -0400 (EDT)

> Has anyone created a functioning BL of domain registrars, rather than
> domains?

I doubt it, if only because it is hard to tell when the same registrar
is used across TLDs.  Some TLDs have no whois servers at all (or at
least if they do, whois.iana.org doesn't show them, which amounts to
the same thing); others have them but don't report registrar identity
in any useful form (and have proven totally impervious to requests that
this be fixed - .biz, .org, and .info come to mind as the most notable
offenders in my experience).  Is "R17-LROR" the same registrar as
"ENOM, INC." (to pick the two handiest examples)?  I don't know and I
don't see any way to find out, short of filing a lawsuit so as to
invoke discovery powers.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Barry Shein <[email-masked]>
Date: Thu, 20 May 2004 00:02:00 -0400

Well I suppose but isn't there some way of effectively wildcarding?
Can't they just set it up so...ok, "it"...SPF yes, easy anyhow, DK no
because they have to work on each msg, but hell someone will just
stick that in whatever they use for a mail server. It's not like it's
saying a lot, just that [email-masked] is one of
ours.

Maybe some of this stuff needs more analysis in terms of
non-cooperative or even anti-cooperative participants. How many times
do we need to beaten over the head with *that* fact?

I know...just blacklist miscreant isps...we see how well that's worked
thus far.

-- 
        -Barry Shein

---

From: William Leibzon <[email-masked]>
Date: Wed, 19 May 2004 21:15:37 -0700 (PDT)

> functioning BL of domain registrars, rather than domains?

How seriously is this needed? 

Completewhois has most of what is necessary and could do this but it'd 
require additional investment in time to program the proper transformation 
to create daily static dnsbl list (which I estimate at least 20 hours of 
programming time), plus additional necessary work to provide documentation 
and support and hardware to run this all. This is beginning to exchaust my
resources and I'd only be willing proceed and invest in programming of 
this functionality if at least dozen other people tell me for certain that 
they would use it and in the help with at least documentation.

> the SPF records. 
SPF records for INADDR space will allow ISPs to tell if particular computer
should be running mail server or not. SPF for direct domains can override
negative response for for those few who actually do want to run mail server
on their broadband line and do not have an ISP that is cooperative enough
to whitelist that ip.

----
William Leibzom
[email-masked]

---

From: "George Ou" <[email-masked]>
Date: Wed, 19 May 2004 21:29:38 -0700

----- Original Message ----- 
From: "Barry Shein" <[email-masked]>
To: "George Ou" <[email-masked]>
Cc: "Barry Shein" <[email-masked]>; "Chris" <[email-masked]>; "Yakov
Shafranovich" <[email-masked]>; "ASRG" <[email-masked]>
Sent: Wednesday, May 19, 2004 6:01 PM
Subject: Re: [Asrg] 6 - Yahoo Domain Keys

> worldview that unfortunately hasn't had much credence thus far.

I realize that my optimism may be misguided, and the more I look into these
things the more jaded I become like yourself.  However, should we not try at
all?  Right now, the government makes laws that have little or no use in the
fight against spam.  If we force the spammer to at least make bulk purchases
of Domain names, rather than using anonymous zombies with impunity, there is
a much better chance we can track down who is doing the spamming and try to
make some partially effective laws.  I'm sure any of these anti-spam
measures have counter measures, but does that mean we don't even try?
Having a reliable domain authentication system in SMTP that is widely used
may not be the solution, but at least a step in the right direction.

George

---

From: Matthew Elvey <[email-masked]>
Date: Wed, 19 May 2004 21:17:19 -0700

Apropos Yahoo's DK I-D wannabe-
http://antispam.yahoo.com/domainkeys/draft-delany-domainkeys-base-00.txt 
posted to this thread:
 It fails to meet IETF requirements for publication as an I-D, or for 
serious consideration by this group.

This text is not allowed:
"This document may not be modified, and derivative works of it may not
be created. This document may only be posted in an Internet-Draft."

I discussed DK with John Levine privately.  My conclusions as a result 
of the conversation*:

DK requires orders of magnitude more
work to adopt, though not as much as SPF+SRS.

DK is about as reliant on blacklists/reputation services as other 
proposals. Without them, CSV is not easier for a spammer to circumvent 
than DK or SPF.  They all require that something be put in a DNS entry 
for a domain that costs approximately nothing to put there beyond the 
cost of the domain itself. DKs aren't signed by CAs, remember.
Exploit: A spammer would have control of the DNS server for the 
responsible domain, and a BotNet spamming node would spam with a valid 
DK.  The DK would be in the zombie worm that created the BotNet, or even 
communicated via IRC.

So, I think DK is shown to be about as trivial to circumvent as the 40% 
solution / CSV+++.

As has been said before, all the extant I-Ds, including this one, and 
C-ID can only work against spamers long term in conjunction with
either
A)RHSBLs or
B)mandatory (but not necessarily monopoly/oligopoly) reputation services.

*(Don't want to quote from private email without asking for an OK, so 
here's just what I said that stood.)

---

From: "Chris" <[email-masked]>
Date: Thu, 20 May 2004 15:59:57 +0930

Hmmm after skimming thru all that's been said and that's a lot. I get the
feeling of being caught in a whirlpool.

I am of the opinion and have stated it before, there is no single solution
and nothing is perfect, and can never be because Spam is different to
different people.

So the first step to my mind is to take away anonymity. If you want to say
something be prepared to stand by it.

Whether it be Spam, something controversial or a virus. it doesnt matter.
(you want anonymity go to a news group or forum)

So whats the next step ?

Better filters. its easier if you know the source of the email.
Better Laws. its easier if you know the source of the email.
something else altogether.  its probably easier if you know the source of
the email.

Well you get my drift.

Zombies are another problem. but at least if the machine is more reliably
traced it can be more reliably stopped.
and if the machine was zombified by an email borne virus. tracing the origin
of the virus is MUCH EASIER.

Domain Keys gives us this traceability and with the addition of "MTA
DomainKeys" people hiding behind "legacy" systems can be traced to the
injection point. and probably further using the injection points logs.

Most Importantly Domain Keys can be grafted onto SMTP without any major
changes just a software upgrade. its only one more header.

You watch there will be all sorts of software avaliable soon marked
"DomainKey Ready".

If we stand by and argue semantics. we will be left behind.

Regards
Chris

---

From: "Chris" <[email-masked]>
Date: Thu, 20 May 2004 17:43:42 +0930

> forwarders, mail lists and roaming users

I don't understand why you say this.

Roaming users still have to log into an ISP somewhere to send their email.
if The ISP is prepared to let them access the mail system the ISP becomes
responsible for what they do. So they should at the very least validate
them.

Mail forwarders can sign the mail. they must accept responsibilty for the
forwarding as above.

Mailing lists must also be held accountable for what they send. they are
simply another 'injection point' and can validate the sender before
inserting it into the list.

> email content must be changed in process
> of tranmission

Why 'must' content be changed?

headers need to be added and those should be signed off as well as the
previous mta's signature. granted this additional signing increases the load
especially for the MTR, but if Spam is reduced then the initial load would
be reduced anyway.

If content MUST be changed then the authority changing the content becomes
the owner. and therefore responsible for the 'new' email.

Regards
Chris

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> William Leibzon
> Sent: Thursday, 20 May 2004 4:17 AM
> To: ASRG
> Subject: Re: [Asrg] [Fwd: Yahoo! Mail Publishes Specification for
> DomainKeys]
>
>

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 May 2004 14:26:48 +0100

>functioning BL of domain registrars, rather than domains?

It's easier to blacklist nameservers than registrars -- working out a
domain's name servers is much simpler than getting to grips with whois.
You need the right kind of blacklist for this purpose, because it must
target nameservers that are only used for spam domains. Fortunately
such a blacklist already exists: the SBL. SpamAssassin 3.0 includes
a module that checks the nameservers of any URL in the message against
the SBL, and this has proved to be very effective. The same technique
should work well against the nameservers of domains in email addresses.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
THE MULL OF GALLOWAY TO MULL OF KINTYRE INCLUDING THE FIRTH OF CLYDE AND THE
NORTH CHANNEL: WEST 3 OR 4 VEERING NORTHWEST 4 OR 5. VARIABLE CLOUD AMOUNTS,
RISK LIGHT SHOWER. MAINLY GOOD. SLIGHT TO MODERATE BECOMING MODERATE.

---

From: John Capo <[email-masked]>
Date: Thu, 20 May 2004 13:19:05 -0400

> work to adopt, though not as much as SPF+SRS.

Nod.

> So, I think DK is shown to be about as trivial to circumvent as the 40% 

Unless I'm missing something I think its even easier to circumvent
and Yahoo! seems to agree:

    6.5 Envelope audit

    [ To be discussed: Identify the preconditions in the base document
    that allow for envelope auditing to protect against replay and
    joe-jobs ]

All that is signed is what is received by the signing MTA.  Get a
Yahoo! throwaway account.  Send email from Yahoo! to yourself at
another account.  Strip headers added in transit and you have a DK
signed message that can be wrapped in a new envelope and it will
verify as signed by Yahoo!.

If widely adopted, DK or something like it might go a long way
towards stopping phishing.  But the phisher can still register a
domain that looks like paypal.com, valued-paypal-customer.com, and
sign that himself and the naive user will still get sucked into the
fraud.

John Capo
Tuffmail.com

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 20 May 2004 16:13:18 -0400

> be created. This document may only be posted in an Internet-Draft."

Slight correction: it meets the IETF requirements for publication as an 
ID. HOWEVER, it does not meet the IETF requirements for a standards 
track ID. There is a slight difference.

I am not involved with the DK/IETF discussions but my hunch is that the 
Yahoo guys are waiting to see if they can proceed in the IETF Standards 
process before modifing the ID. Same as what took place with the SPF ID 
- the -00 draft has the same problem, the current -01 draft does not. I 
would assume that they are probably discussing things with the ADs at 
the IETF.

Yakov
--
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass" (Unknown)

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 20 May 2004 16:35:35 -0400

> B)mandatory (but not necessarily monopoly/oligopoly) reputation services.

Reputation/accrediation/trust stuff is something that the ASRG should 
probably be looking into. We had some discussions on this in the 
SMTP-VERIFY subgroup before.

Yakov
--
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Some lies are easier to believe than the truth" (Dune)

---

From: Matthew Elvey <[email-masked]>
Date: Thu, 20 May 2004 15:04:15 -0700

My statement is based on http://www.ietf.org/ietf/1id-guidelines.txt :

Mandatory Statements
====================

All Internet-Drafts must begin with ONE of the following three
statements:

         This document is an Internet-Draft and is subject to
         all provisions of Section 10 of RFC2026.

         This document is an Internet-Draft and is subject to
         all provisions of Section 10 of RFC2026 except that the
         right to produce derivative works is not granted.

         This document is an Internet-Draft and is NOT offered in
         accordance with Section 10 of RFC2026, and the author does not
         provide the IETF with any rights other than to publish as an
         Internet-Draft

On 5/20/04 1:13 PM, Yakov Shafranovich sent forth electrons to convey:

> Slight correction: it meets the IETF requirements for publication as 
> an ID. HOWEVER, it does not meet the IETF requirements for a standards 
> I am not involved with the DK/IETF discussions but my hunch is that 
> the Yahoo guys are waiting to see if they can proceed in the IETF 
> Standards process before modifing the ID. Same as what took place with 
> the SPF ID - the -00 draft has the same problem, the current -01 draft 
> does not. I would assume that they are probably discussing things with 
> the ADs at the IETF.
>
> Yakov
> --

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 20 May 2004 19:35:14 -0400

See RFC 3667, section 5.2(b) which changed that. It seems that the 
secretariat did not yet update the ID guidelines to match RFC 3667.

Yakov

---

From: William Leibzon <[email-masked]>
Date: Fri, 21 May 2004 00:36:57 -0700 (PDT)

You're missing the point. You can't assume that everybody would start 
running DomainKeys systems all over the world. As such any proposal 
should ensure that if sender system is using it, that the MTA server on 
the recepient side can safely verify the email even if somewhere in 
between it passed through MTA systems which have no idea about what
this proposal is about. Domainkeys in the way its been published does
not meet this criteria as there are many cases when intermediate MTAs
change or add additional headers.

---

From: "Chris" <[email-masked]>
Date: Fri, 21 May 2004 17:22:19 +0930

Ok I am with you now.

But the draft is really only in its initial stage. the Author states that
quite emphatically.
So it is far too early to say "It won't work because"

There may be problems that need to be overcome. and can be.

Perhaps for the problem you mention do not include the "normal" headers in
the Domain Key digest
but add some special headers e.g.
DK-FROM: [email-masked] ; the original sender
DK-SENTBY: [email-masked] ; for mail forwarding roaming etc..

Then sign the message body and the special headers. leave the rest alone.
software that knows how to deal with DomainKeys can use those fields. other
software is on its own.

if an intervening MTA changes those headers or changes the body then the
mail could be seen as tainted and then refused.

Regards
Chris

> From: William Leibzon [mailto:[email-masked]]
> Sent: Friday, 21 May 2004 5:07 PM
> To: Chris
> Cc: ASRG
> Subject: RE: [Asrg] [Fwd: Yahoo! Mail Publishes Specification for
> DomainKeys]
>
>
>