[ietf-dkim] DKIM and EAI

2017-12-05 Thread John R. Levine 

If I may change the topic for a moment ...

I'm working on some stuff for ICANN to help people get EAI mail working. 
One of the underspecified bits of EAI is how authentication works with 
SPF, DKIM, DMARC and now, I suppose ARC.  There's a bunch of places where 
one needs to make arbitrary decisions about what's in ASCII (a-labels) or 
what's in UTF-8 (u-labels.)  I did a draft about it last year:


https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/

It would be nice if this could be finished and published, so I have 
something better than an expired draft to point at when people ask me how 
to do DKIM and SPF with their EAI mail.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Fwd: SendGrid, GetResponse and Hubspot being used over DKIM "patent"

2017-12-05 Thread Daniel Dreymann 
Mark Delany most definitely wrote:

> Did the claimants vacuum up the IP of the now defunct Goodmail? Reads
> somewhat similar to what they were once trying to sell. Particularly
> the "contractual" obligations of the senders.

Goodmail indeed sold its patent portfolio, but none of the three patents
asserted is related to Goodmail's intellectual property.

Ironically, Gmail placed Steve's original message in my spam folder.

DTD

On Tue, Dec 5, 2017 at 12:50 PM, Mark Delany 
wrote:

> On 05Dec17, Steve Atkins allegedly wrote:
> >
> > I thought this might be of interest to DKIM implementers.
>
> > The Asserted Patents share a common specification.
>
> Did the claimants vacuum up the IP of the now defunct Goodmail? Reads
> somewhat similar to what they were once trying to sell. Particularly
> the "contractual" obligations of the senders.
>
> From what I can glean, the plan is to digitally sign the email along
> the lines of S/MIME (PKI and CAs are referred to extensively and
> exclusively) and the sender include a "pledge" about the contents such
> as "no more than 5 recipients will get this email". Recipients can act
> on the pledge in the knowledge that senders apparently won't lie in
> their pledge. Or if they do lie something will happen to them -
> exactly what or how is not specified.
>
> How the pledge is validated across the whole of Internet email is
> undefined as is what to do to the sender if the pledge is known to be
> a lie.
>
> There are no references to DNS, no reference to how they determine
> identical mail (canonicalization), no reference to S/MIME or DKIM in
> any of their filings.
>
> I guess the "pledge" on the part of the sender is vaguely novel but
> there is no equivalent in DKIM as far as I recall. Maybe the vendors
> you refer to have features that emulates pledges when sending email?
>
> For moral equivalence, the Date: header is a pledge as to when the
> email was composed/sent and Content-Type: is a pledge as to how the
> MIME part has been encoded so the novelty is not even that there are
> pledges in the email, just the nature of the pledge.
>
> To me they seem to have invented a new mail header.
>
>
> Mark.
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

2017-12-05 Thread Murray S. Kucherawy 
On Tue, Dec 5, 2017 at 2:52 PM, Pawel Lesnikowski 
wrote:

>
> DKIM works as expected, but as you said it may re-enforce an incorrect
> assumption that email is from respected source.
>
>
Only if it's abused by saying "DKIM signature verified, it's safe!" rather
than " signed this, hope that's cool".

-MSK
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

2017-12-05 Thread Murray S. Kucherawy 
I disagree that it's specifically a DMARC issue, because from that I infer
that you think DMARC is at fault here, i.e., that you expected it to deal
with this.

On Tue, Dec 5, 2017 at 1:44 PM, Steve Atkins 
wrote:

> That's DMARC working exactly as designed but not as commonly understood,
> which makes it a DMARC issue (though a usability one of unmet expectations
> rather than anything technical).
>

Then it's also an email issue generally, because it's probably not commonly
understood that there doesn't have to be a relationship between the display
name and the email address, or between either of those and any other
identifier on the message.

This is just another display name attack.  The only thing that's
breathtaking this time is that some MUAs have evidently chosen to say it's
a server problem.

-MSK
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

2017-12-05 Thread Dave Crocker 

On 12/5/2017 1:44 PM, Steve Atkins wrote:

That's DMARC working exactly as designed but not as commonly understood, which 
makes it a DMARC issue (though a usability one of unmet expectations rather 
than anything technical).



probably not.

it's an anti-abuse issue, where there is quite a bit of sloppiness and 
confusion about all of the relevant technologies.


but the problem and the issue is the broad need for much better clarity 
and precision than to assign a particular misunderstanding to that 
particular technology.  (People generally believe DKIM certifies the 
source of a message and even its authorship.)


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Fwd: SendGrid, GetResponse and Hubspot being used over DKIM "patent"

2017-12-05 Thread Roland Turner 

On 06/12/17 08:33, Mark Delany wrote:


On 06Dec17, Suresh Ramasubramanian allegedly wrote:

The pledge idea isn???t terribly novel either

Anne Mitchell used a habeas haiku

Gosh. The Haiku. How could I have possibly forgotten that beauty! But,
if you really want to intimidate spammers with poetry I recommend the
very effective Haka instead.


(wonders whether the possible applications of Vogon poetry have been 
adequately explored)


- Roland
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Fwd: SendGrid, GetResponse and Hubspot being used over DKIM "patent"

2017-12-05 Thread Suresh Ramasubramanian 
Works for me. I could never look anything but ridiculous though .. 6 ft 40ish 
potbellied indian guy sticking his tongue out and trying to look like a scary 
Maori warrior, nope.

--srs

> On 06-Dec-2017, at 6:03 AM, Mark Delany  wrote:
> 
> Gosh. The Haiku. How could I have possibly forgotten that beauty! But,
> if you really want to intimidate spammers with poetry I recommend the
> very effective Haka instead.

___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Fwd: SendGrid, GetResponse and Hubspot being used over DKIM "patent"

2017-12-05 Thread Mark Delany 
On 06Dec17, Suresh Ramasubramanian allegedly wrote:
> The pledge idea isn???t terribly novel either 
> 
> Anne Mitchell used a habeas haiku

Gosh. The Haiku. How could I have possibly forgotten that beauty! But,
if you really want to intimidate spammers with poetry I recommend the
very effective Haka instead.


Mark.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Fwd: SendGrid, GetResponse and Hubspot being used over DKIM "patent"

2017-12-05 Thread Suresh Ramasubramanian 
The pledge idea isn’t terribly novel either 

Anne Mitchell used a habeas haiku and then contract law to enforce that any 
email with that haiku in the headers had to be complaint with anti Spam best 
practices or would get sued.

--srs

> On 06-Dec-2017, at 2:20 AM, Mark Delany  wrote:
> 
>> On 05Dec17, Steve Atkins allegedly wrote:
>> 
>> I thought this might be of interest to DKIM implementers.
> 
>> The Asserted Patents share a common specification.
> 
> Did the claimants vacuum up the IP of the now defunct Goodmail? Reads
> somewhat similar to what they were once trying to sell. Particularly
> the "contractual" obligations of the senders.
> 
> From what I can glean, the plan is to digitally sign the email along
> the lines of S/MIME (PKI and CAs are referred to extensively and
> exclusively) and the sender include a "pledge" about the contents such
> as "no more than 5 recipients will get this email". Recipients can act
> on the pledge in the knowledge that senders apparently won't lie in
> their pledge. Or if they do lie something will happen to them -
> exactly what or how is not specified.
> 
> How the pledge is validated across the whole of Internet email is
> undefined as is what to do to the sender if the pledge is known to be
> a lie.
> 
> There are no references to DNS, no reference to how they determine
> identical mail (canonicalization), no reference to S/MIME or DKIM in
> any of their filings.
> 
> I guess the "pledge" on the part of the sender is vaguely novel but
> there is no equivalent in DKIM as far as I recall. Maybe the vendors
> you refer to have features that emulates pledges when sending email?
> 
> For moral equivalence, the Date: header is a pledge as to when the
> email was composed/sent and Content-Type: is a pledge as to how the
> MIME part has been encoded so the novelty is not even that there are
> pledges in the email, just the nature of the pledge.
> 
> To me they seem to have invented a new mail header.
> 
> 
> Mark.
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html

___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

2017-12-05 Thread Grant Taylor 

On 12/05/2017 03:52 PM, Pawel Lesnikowski wrote:
encoded-words are simply not permitted inside email addresses. MUA 
shouldn't attempt to decode this at all.


Perhaps they shouldn't attempt to decode it per say.

I think they should attempt to detect the presence of invalid characters 
and act accordingly.


Attempting to decode is the first problem, incorrectly handling null 
terminators and new lines is the second issue.


Okay.


MUAs simply don't expect new lines and null terminators there.


Isn't expecting something unexpected a tenant of security?

I.e. code defensively.

DKIM works as expected, but as you said it may re-enforce an incorrect 
assumption that email is from respected source.


:-/



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

2017-12-05 Thread Pawel Lesnikowski 
>
>
>> What is "naive" or "incorrect" about the following decoding?
>
> po...@whitehouse.govpo...@whitehouse.gov@mailsploit.com
>
> "=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=" quite literally does decode to
> "po...@whitehouse.gov"
>

encoded-words are simply not permitted inside email addresses. MUA
shouldn't attempt to decode this at all.


>
> Or are you indicating that the naivety is the fact that MUAs may
> incorrectly handle the null containing string?  Possibly believing that the
> MUA will use null termination and incorrectly believe that the From:
> address is just "po...@whitehouse.gov"?
>
>
Attempting to decode is the first problem, incorrectly handling null
terminators and new lines is the second issue.
MUAs simply don't expect new lines and null terminators there.


> Although it's not a direct attack on DKIM, if DKIM is implemented properly
>> and email address decoding and displaying isn't, users might be fooled.
>>
>
> That is an MUA issue.  Perhaps DKIM helps re-enforce an incorrect
> assumption based on a bad MUA trait.  But I don't see that as a DKIM issue.


DKIM works as expected, but as you said it may re-enforce an incorrect
assumption that email is from respected source.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

2017-12-05 Thread Steve Atkins 

> On Dec 5, 2017, at 2:23 PM, Grant Taylor  wrote:
> 
> What's worse, no security, or bad / false security?

That's DMARC's motto.

Cheers,
  Steve


___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

2017-12-05 Thread Grant Taylor 

On 12/05/2017 02:24 PM, Pawel Lesnikowski wrote:
I'm not sure if you noticed but it seems many client are affected by 
'mailsploit':

https://www.mailsploit.com/index


$ReadingList++

Basically the attacker uses special characters inside encoded words to 
spoof the sender:


From: 
=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com 



Such header naively decoded incorrectly is: 
po...@whitehouse.govpo...@whitehouse.gov@mailsploit.com 


I'll show my ignorance.  (In the hopes to learn.)

What is "naive" or "incorrect" about the following decoding?

po...@whitehouse.govpo...@whitehouse.gov@mailsploit.com

"=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=" quite literally does decode 
to "po...@whitehouse.gov"


Or are you indicating that the naivety is the fact that MUAs may 
incorrectly handle the null containing string?  Possibly believing that 
the MUA will use null termination and incorrectly believe that the From: 
address is just "po...@whitehouse.gov"?


Although it's not a direct attack on DKIM, if DKIM is implemented 
properly and email address decoding and displaying isn't, users might be 
fooled.


That is an MUA issue.  Perhaps DKIM helps re-enforce an incorrect 
assumption based on a bad MUA trait.  But I don't see that as a DKIM issue.


Of course encoded words are not allowed inside email addresses (address, 
not names), but is seems many clients try to decode them.


Again, an MUA issue.  IMHO not a DKIM (or DMARC) issue.


What are your thoughts?


I feel like this is a play on / adaptation of source routing (which is 
deprecated) in an attempt to make the MUA display a subset of the actual 
address in the from header.  (DMARC would also care about SPF's stance 
on the RFC821.From address.)


I feel like DKIM should 1) dutifully sign what comes in from the MSA.  I 
suspect that DKIM would use a domain (d=) of "mailsploit.com".  I 
further suspect that the RFC821.From address would also reflect 
"mailsploit.com".  Thus the message, seeming to be from "mailsploit.com" 
would pass SPF, DKIM, and likely DMARC.  This is because the message 
would really be from "mailsploit.com".


IMHO this really does boil down to MUAs behaving badly, thus enabling a 
bad belief that the message is from po...@whitehouse.gov, with SPF, 
DKIM, and DMARC supporting this bad supposition.


I really feel like this is an MUA issue.

What's worse, no security, or bad / false security?



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

2017-12-05 Thread Steve Atkins 

> On Dec 5, 2017, at 1:36 PM, Dave Crocker  wrote:
> 
> On 12/5/2017 1:33 PM, Steve Atkins wrote:
>> It's a DMARC issue rather than a DKIM one.
> 
> 
> How is it a DMARC issue?

From: {spoo-that-expands-to bill...@paypal.com\0}@badpeople.ru will be 
delivered and (on some clients) have a recipient-visible 822.From that looks 
like "From: bill...@paypal.com" despite not having a valid DKIM signature with 
a d=paypal.com nor matching paypal.com's published SPF record.

That's DMARC working exactly as designed but not as commonly understood, which 
makes it a DMARC issue (though a usability one of unmet expectations rather 
than anything technical).

Much the same as "From: bill...@paypal.com ", or the 
various approaches that pad headers with various sorts of whitespace or 
v__e_r_y long local parts to hide the real domain part on mobile 
devices, etc.

Cheers,
  Steve
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

2017-12-05 Thread John R. Levine 

From:
=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@
mailsploit.com


I'm with Steve, this is overclever in a world where most MUAs just show 
you the From: comment.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

2017-12-05 Thread Dave Crocker 

On 12/5/2017 1:33 PM, Steve Atkins wrote:

It's a DMARC issue rather than a DKIM one.



How is it a DMARC issue?

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

2017-12-05 Thread Steve Atkins 

> On Dec 5, 2017, at 1:24 PM, Pawel Lesnikowski  
> wrote:
> 
> Hi All,
> 
> I'm not sure if you noticed but it seems many client are affected by 
> 'mailsploit':
> https://www.mailsploit.com/index
> 
> Basically the attacker uses special characters inside encoded words to spoof 
> the sender:
> 
> From: 
> =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com
> 
> Such header naively decoded incorrectly is:
> po...@whitehouse.gov\0po...@whitehouse.gov@mailsploit.com
> 
> Although it's not a direct attack on DKIM, if DKIM is implemented properly 
> and email address decoding and displaying isn't, users might be fooled.
> 
> Of course encoded words are not allowed inside email addresses (address, not 
> names), 
> but is seems many clients try to decode them.
> 
> What are your thoughts?

It's a DMARC issue rather than a DKIM one.

Most mobile clients and many desktop clients don't display the senders email 
address anyway, just the "friendly from" / human readable comment, so "From: 
POTUS po...@whitehouse.gov " is much simpler and nearly as 
effective.

This[1] is a rendering bug the MUA authors really should fix, but not a 
terrible concern unless maybe you're looking at sneaky targeted phishing mail.

Cheers,
  Steve

[1] mailsploit, I mean. Maybe that other thing too.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Mailsploit

2017-12-05 Thread Pawel Lesnikowski 
Hi All,

I'm not sure if you noticed but it seems many client are affected by
'mailsploit':
https://www.mailsploit.com/index

Basically the attacker uses special characters inside encoded words to
spoof the sender:

From:
=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@
mailsploit.com

Such header naively decoded incorrectly is:
po...@whitehouse.gov*\0*po...@whitehouse.gov@mailsploit.com

Although it's not a direct attack on DKIM, if DKIM is implemented properly
and email address decoding and displaying isn't, users might be fooled.

Of course encoded words are not allowed inside email addresses (address,
not names),
but is seems many clients try to decode them.

What are your thoughts?

-- 
Best regards,
Pawel Lesnikowski
https://www.limilabs.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Fwd: SendGrid, GetResponse and Hubspot being used over DKIM "patent"

2017-12-05 Thread Dave Crocker 

On 12/5/2017 12:50 PM, Mark Delany wrote:

For moral equivalence, the Date: header is a pledge as to when the
email was composed/sent



I've done only two user studies in my life.  The first -- for the Rand 
system --produced the email command name 'reply'.  The second -- for the 
DRUMS production of RFC2822, I believe, clarifying RFC822 -- was for the 
semantics of the Date: field.  It's meaning was not lear in 822 and the 
result of the survey of users I did was to define it as the time of 
posting.  Hence the 'send' you cite, rather than the 'compose'.


Thank you for tolerating this distraction.  You are now returned to 
matters of substance...


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Fwd: SendGrid, GetResponse and Hubspot being used over DKIM "patent"

2017-12-05 Thread Mark Delany 
On 05Dec17, Steve Atkins allegedly wrote:
> 
> I thought this might be of interest to DKIM implementers.

> The Asserted Patents share a common specification.

Did the claimants vacuum up the IP of the now defunct Goodmail? Reads
somewhat similar to what they were once trying to sell. Particularly
the "contractual" obligations of the senders.

From what I can glean, the plan is to digitally sign the email along
the lines of S/MIME (PKI and CAs are referred to extensively and
exclusively) and the sender include a "pledge" about the contents such
as "no more than 5 recipients will get this email". Recipients can act
on the pledge in the knowledge that senders apparently won't lie in
their pledge. Or if they do lie something will happen to them -
exactly what or how is not specified.

How the pledge is validated across the whole of Internet email is
undefined as is what to do to the sender if the pledge is known to be
a lie.

There are no references to DNS, no reference to how they determine
identical mail (canonicalization), no reference to S/MIME or DKIM in
any of their filings.

I guess the "pledge" on the part of the sender is vaguely novel but
there is no equivalent in DKIM as far as I recall. Maybe the vendors
you refer to have features that emulates pledges when sending email?

For moral equivalence, the Date: header is a pledge as to when the
email was composed/sent and Content-Type: is a pledge as to how the
MIME part has been encoded so the novelty is not even that there are
pledges in the email, just the nature of the pledge.

To me they seem to have invented a new mail header.


Mark.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Fwd: SendGrid, GetResponse and Hubspot being used over DKIM "patent"

2017-12-05 Thread Steve Atkins 
I thought this might be of interest to DKIM implementers.

> Begin forwarded message:
> 
> From: Laura Atkins 
> 
> A company called TrueMail is suing the above 3 companies claiming DKIM is an 
> infringement of 3 patents they own. 
> 
> Docs are up:  
> 
> https://www.courtlistener.com/docket/6173128/truemail-technologies-llc-v-getresponse-inc/
> https://www.courtlistener.com/docket/6178679/truemail-technologies-llc-v-hubspot-inc/
> https://www.courtlistener.com/docket/6173696/truemail-technologies-llc-v-sendgrid-inc/
> 
> I’ve only taken the briefest look through one of the complaints. Here’re the 
> relevant bits: 
> 
> The Asserted Patents share a common specification. 
> 
> 21. The ’126 patent claims, among other inventions, a method for identifying 
> unwanted email messages, by which the sender is assigned a unique, private, 
> digital signature. The sender, in turn, agrees to conform to a set of rules 
> of conduct, and the recipients receive the email with a public digital 
> signature, which allows them to verify the identity of the sender. This 
> method allows for the monitoring of the number of substantially identical 
> emails being sent to different recipients, and allows for distinguishing a 
> given email message from unsolicited and unwanted email messages. See ’126 
> patent, 7:6-48 
> 
> 22. The ’126 patent specification describes an email system in which a sender 
> is limited in transmitting identical emails to a predetermined number of 
> recipients over a specified period of time. The sender, who is identified by 
> its unique digital signature, also manifests a promise to not solicit 
> business or contain unsolicited advertising. The unique digital signature 
> provides a method to distinguish unsolicited email messages from ones in 
> which the sender has promised that the recipient has made a prior request or 
> granted permission to receive said email. This promise is legally binding and 
> traceable to the sender by its unique digital signature. See ’126 patent, 
> 7:6-67 & 8:11-64.
> 
> 23. The ’655 patent claims, among other inventions, a method for identifying 
> unwanted email messages, by which the sender is assigned a unique, private, 
> digital signature. The sender, in turn, agrees to conform to a set of rules 
> of conduct, and the recipients receive the email with a public digital 
> signature, which allows them to verify the identity of the sender. This 
> method allows for the monitoring of the number of substantially identical 
> emails being sent to different recipients, and allows for distinguishing a 
> given email message from unsolicited and unwanted email messages. See ’655 
> patent, 7:11-45. 
> 
> 24. The ’655 patent specification describes an email system in which a sender 
> is limited in transmitting identical emails to a predetermined number of 
> recipients over a specified period of time. The sender, who is identified by 
> its unique digital signature, also manifests a promise to not solicit 
> business or contain unsolicited advertising. The sender also promises that no 
> further email messages will be sent to the recipients upon receipt of a 
> cancellation request by the recipients. The unique digital signature provides 
> a method to distinguish unsolicited email messages from ones in which the 
> sender has promised that the recipient has made a prior request or granted 
> permission to receive said email. This promise is legally binding and 
> traceable to the send by its unique digital signature. See ’655 patent, 
> 7:46-67 & 8:1-9:31. 
> 
> 25. The ’084 patent claims, among other inventions, a method for identifying 
> unwanted email messages, by which the sender is assigned a unique, private, 
> digital signature. The sender, in turn, agrees to conform to a set of rules 
> of conduct, and the recipients receive the email with a public digital 
> signature, which allows them to verify the identity of the sender. This 
> method allows for the monitoring of the number of substantially identical 
> emails being sent to different recipients, and allows for distinguishing a 
> given email message from unsolicited and unwanted email messages. See ’084 
> patent, 7:17-8:9.
> 
> 26. The ’084 patent specification describes an email system in which a sender 
> is limited in transmitting identical emails to a predetermined number of 
> recipients over a specified period of time. The sender, who is identified by 
> its unique digital signature, also manifests a promise to not solicit 
> business or contain unsolicited advertising. The unique digital signature 
> provides a method to distinguish unsolicited email messages from ones in 
> which the sender has promised that the recipient has made a prior request or 
> granted permission to receive said email. This promise is legally binding and 
> traceable to the send by its unique digital signature. See ’084 patent, 
> 8:10-56.
> 
> laura 
> 
> -- 
> Having an Email Crisis?  We