Subject: Re: RE: [Asrg] Several Observations and a solution that addresses them all

From: "Jon Kyme" <[email-masked]>
Date: Tue, 11 Mar 2003 08:08:10 +0000

> I'm not concerned. Get the spam off the net, and watch reliability go up.
> ;-)
> 

You're not concerned that your proposal would impose a cost (any cost) on
innocent systems which haven't subscribed to it?

You're not concerned that validating a "from address" is a non-trivial
problem?

Fine. However, that doesn't stop these being "concerns" in a non-personal
sense.

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

---

From: Jason Hihn <[email-masked]>
Date: Tue, 11 Mar 2003 09:35:41 -0500

You have to break eggs to make an omelet. There is no solution to spam that
will not wind up costing the same as or being cheaper than current email.

What we can do is create a system where the cost of email+spamproofness <
cost of email+spam. I believe that is a good technical definition of success
in this task.

Validating a from address is trivial.

And don't understand your last statement.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Jon
Kyme
Sent: Tuesday, March 11, 2003 3:08 AM
To: Jason Hihn
Cc: ASRG
Subject: Re: RE: [Asrg] Several Observations and a solution that
addresses them all

---

From: [email-masked]
Date: Tue, 11 Mar 2003 11:47:50 -0500

> Validating a from address is trivial.

OK. It's trivial?  Validate the From address on this mail.  Explain in
detail what you did, and what steps you took to make sure that the
data you used wasn't faked. Sure- those Recieved: headers *LOOK* like
they're correct, but *are* they?

Now repeat your analysis, but this time for the following headers:

Date: Fri, 09 Aug 2002 09:08:45 -0400
From: [email-masked]
Subject: Re: TeXinfo 4.2 - We *SHOULD* Be Using It.
Sender: [email-masked]
To: "Stephen J. Turnbull" <[email-masked]>
Cc: XEmacs Design <[email-masked]>

How validated are you feeling now?  Incidentally, your validator *should*
have validated the above headers, as that's the looped-back headers from
an item I actually posted while travelling...

/Valdis

---

From: Jason Hihn <[email-masked]>
Date: Tue, 11 Mar 2003 12:08:15 -0500

PSEUDO CODE:
user=left_of('@', email_addr)
domain=right_of('@', email_addr)
server=find_mx(domain)
socket=open(server, some_std_port)
write(socket, "VALIDATE user\n")
read(socket, response)
if (find(response, "USER UNKOWN"))
   valid=false;
else
   valid=true;

DONE

You can't EVER use headers because they are forgeable. You have to go right
to the source.
Incendentally, the other server's code is like:

bind()
while (con=accept()) {
	read(req)
      result=dispatch(req, con)
	write(result)
}

Dispatch is the heart of it all. It will pass on the request to sub mail
servers if it cannot be determined on this one. It also makes sure that the
connection comes from a recenelty sent-to domain to keep spammers from
asking for validations of email addrs out of the blue.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 11:48 AM
> To: Jason Hihn
> Cc: ASRG
> Subject: Re: [Asrg] Several Observations and a solution that addresses
> them all
>
>
> Received: from gwyn.tux.org (gwyn.tux.org [207.96.122.8])  by
> steiner.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA)
> with ESMTP id ALY11182; Mon, 12 Aug 2002 12:57:12 -0400 (EDT)
> Received: from gwyn.tux.org (localhost.localdomain [127.0.0.1])
> by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA04906; Mon,  12
> Aug 2002 12:55:01 -0400
> Received: (from turnbull@localhost) by gwyn.tux.org (8.9.3/8.9.1)
>  id MAA04868 for [email-masked]; Mon,  12 Aug
> 2002 12:54:38 -0400
> Received: (from mail@localhost) by gwyn.tux.org (8.9.3/8.9.1)  id
> MAA04864 for [email-masked]; Mon, 12 Aug 2002 12:54:38 -0400
> Received: from turing-police.cc.vt.edu (natted.Sendmail.COM
> [63.211.143.38])  by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id
> MAA04854; Mon,  12 Aug 2002 12:54:30 -0400
> Received: from turing-police.cc.vt.edu ([127.0.0.1]) by
> turing-police.cc.vt.edu  (8.12.5/8.12.5) with ESMTP id
> g79D8j58001879; Fri, 09 Aug 2002 09:08:45 -0400
> X-URL: http://black-ice.cc.vt.edu/~valdis/
> In-reply-to: "Your message of Fri, 09 Aug 2002 12:31:16 +0900."
> <[email-masked]>
> Errors-to: [email-masked]
> Message-id: <[email-masked]>
> MIME-version: 1.0
> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
> Content-type: multipart/signed; boundary="==_Exmh_-1612254088P";
> micalg=pgp-sha1; protocol="application/pgp-signature"
> Content-transfer-encoding: 7bit
> Precedence: bulk
> X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to
> decode picture
> X-Face:
> 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS
> 7(8t(
> ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[<!v4
> -0bVIpaxF#-)
> %9#a9h6JXI|T|8o6t\V?kGl]Q!1V]GtNliUtz:3},0"hkPeBuu%E,j(:\iOX-P,t7lRR#
> X-XEmacs-List: design
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.0.1
> List-Help: <mailto:[email-masked]?subject=help>
> List-Post: <mailto:[email-masked]>
> List-Subscribe:
<http://lists.xemacs.org/lists/listinfo/xemacs-design>,
<mailto:[email-masked]?subject=subscribe>
List-Id: Discussion of design and features for XEmacs.
<xemacs-design.xemacs.org>
List-Unsubscribe: <http://lists.xemacs.org/lists/listinfo/xemacs-design>,
<mailto:[email-masked]?subject=unsubscribe>
References: <[email-masked]>
<[email-masked]>
<[email-masked]>
<[email-masked]>

/Valdis

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 11 Mar 2003 13:04:13 -0500

>asking for validations of email addrs out of the blue.

What you said was that it was "trivial".

What you have described requires that the primary and secondary MXs 
for a domain all run custom software which connects to the 
centralized server that sends all email for a domain, and that that 
server keep track of all outbound mail, who it came from and where it 
went.  And it assumes by convention that nobody from that domain is 
allowed to send email via any other server.

There's also another little problem.

MAIL FROM:<[email-masked]>
RCPT TO:<[email-masked]>

Now I go back to your server and say, "is [email-masked] a 
valid address" and your server says, "what the hell are you talking 
about, I've gotten hundreds of queries about this person, but they 
did not send mail to [email-masked], they only sent email to 
[email-masked].  Must be a spammer.  Not valid."

So if you want this to work you need to extend the SMTP protocol. 
There isn't enough information in the transport to uniquely identify 
a message.

But in any case, it's clear that the operative word is *not* "trivial".
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Jason Hihn <[email-masked]>
Date: Tue, 11 Mar 2003 13:27:37 -0500

> From: Kee Hinckley [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 1:04 PM
> To: Jason Hihn
> Cc: [email-masked]; ASRG
> Subject: RE: [Asrg] Several Observations and a solution that addresses
> them all
>
>

Indeed. If you don't consider that trivial... ;-)

> allowed to send email via any other server.

You need not track from who to who, just from where to where. Or better yet,
make it configurable. Let the UE suffer higher spam rates because of their
privacy laws.. (Ironic don't you think?)

> [email-masked].  Must be a spammer.  Not valid."

Exactly. You have no rights to my info if I did not send to you. Don't speak
until spoken to. If I sent you mail then that means I don't mind you knowing
who I am. I don't see how this is incorrect or undesired behavior.

> So if you want this to work you need to extend the SMTP protocol.

Yes.

> There isn't enough information in the transport to uniquely identify

Nor would I want there to be. Assume that we do have spammers in the new
system. I'd still like to remain at large to them. By saying "I got this
message from you, addressed to me" allows covert software to log the unique
validation request. Assuming we only validate emails we get (as opposed to
those we don't get) we'd expose our email address. Where as if you say this
is "yahoo.com(by reverse lookup), I want to verify blackrider@yourdomain"
the spammer has to slow things down to the point that there is only one
outstanding address to his request, per domain. It gets even hairer for the
spammer if yahoo.com and another domain cooperate, and the requests can come
from earthlink.net too. Get enough cooperation and any lonk od overlap
really does a number on the spammer. Then there can ever only be one
outstanding address at once. This would require the validation server to be
able to ask yahoo.com who are you cooperating with (or present it at
validation request time)

> But in any case, it's clear that the operative word is *not* "trivial".

Lets define trival. Anything that can be solved in polynomial time is
trivial.
Our techniques are lexography and syntax and some elemenaty structure
navigation. All polynomially complete, and therefor trivial ;-)

---

From: [email-masked]
Date: Tue, 11 Mar 2003 13:41:33 -0500

On Tue, 11 Mar 2003 12:08:15 EST, Jason Hihn said:

> if (find(response, "USER UNKOWN")

Spammer code:

 open(socket);
 while (accept(socket))  {
	write(socket,"USER IS A GOOD GUY NOT A SPAMMER");
 }

You were expecting anything different when you do a callback to an
address provided by the spammer?

---

From: Jason Hihn <[email-masked]>
Date: Tue, 11 Mar 2003 14:21:10 -0500

That is *exactly* what I expect to see happen.

This is where the nuances of the system really start to show/work.
Realize this:
1) The spammer owns a domain.

2) The spammer has provided a return address accurate up to at least the
domain (which they own, or the compromised someone else's server, but that
is highly illegal, not to mention 'hard') There is absolute certainty that
the email came from this domain. Therefore, it can easily be black-listed.
There's also no reason why you can't first check for a query for a black
listed domain and return INVALID USER for them regardless of user. If you
are using the promoted/demoted chars I speak of frequently, then you can
safely demote the email so the message will get through. Else if you're
taking a hard-line stance, you can just reject the email.

We now have a traceable route back to the spammer. At there very least, we
have their MX IP, which can be traced to their ISP and so on.

> Sent: Tuesday, March 11, 2003 1:42 PM
> To: Jason Hihn
> Cc: ASRG

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 11 Mar 2003 15:40:37 -0500

> until spoken to.

But you _did_ send email to him.  Via _this_ mailing list.  How was your 
mail server supposed to know that the IETF mailing server forwarded it 
to him?

---

From: Chuq Von Rospach <[email-masked]>
Date: Tue, 11 Mar 2003 12:46:34 -0800

On Tuesday, March 11, 2003, at 12:40  PM, Chris Lewis wrote:
> But you _did_ send email to him.  Via _this_ mailing list.  How was 
> your mail server supposed to know that the IETF mailing server 
> forwarded it to him?
>

I'd argue that the relationship is between the subscriber and the 
mailing list, and that's what ought to be validated. It's up to the 
mailing list to validate what can be sent by it, but the user's 
relationship is with the list, not with all of the users on the list.

-- 
Chuq Von Rospach, Architech
[email-masked] -- http://www.plaidworks.com/chuqui/blog/

No! No! Dead girl, OFF the table! -- Shrek

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 11 Mar 2003 16:00:17 -0500

> relationship is with the list, not with all of the users on the list.

True, but you'd not only have to get mailing lists "fixed" first, you'd 
have to change the mailing list standards and the MTAs so that the 
receiving MTA could figure that out...

Given how easy this is to circumvent (plus the difficulties of handling 
TEMPFAIL, and services that simply aren't reachable directly by TCP/IP 
at the best of times), I don't think it's worth going down this hole.

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 11 Mar 2003 16:04:15 -0500

>have their MX IP, which can be traced to their ISP and so on.

As I have said before on this list.  There are spammers out there who 
are registering new domains every week.  They don't forge their 
domains, and you can't blacklist them based on the domain because it 
keeps changing.  If we require domain authentication, then all 
spammers will move towards this model.  That is not necessarily a bad 
thing, but it argues for a level of authentication that comes with 
certificates and certificate revocation.

As for "nailing" the spammer...

He sets up an authentication server on a dialup connection.  He uses 
a free dynamic dns system to point his mx at the dialup.  And then he 
sends spam from all over the world using proxies and relays.  Anyone 
who gets email checks the mx, that sends them to his dialup machine, 
and it says the mail is valid.

What happens if you report him to his ISP?  He loses his dialup 
connection.  Just like now.

So then I suppose the ISPs block inbound connections to your 
authentication port.  And then once that happens someone starts up a 
server offshore selling authentication services for domains.  And 
they keep moving the IP address around using different relays at 
different offshore machines.

In other words--we are fighting the same battle then as now, just in 
a different space.

Just as content filtering doesn't detect spam, it detects content. 
Domain authentication doesn't identify spammers, it identifies 
domains.  Both are very useful.  I'd love a mechanism that kept 
people from forging my domain name.  But it won't stop spam.  Nor (as 
described) will it drive the spammers into a small enough box that we 
can stop them.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Jason Hihn <[email-masked]>
Date: Tue, 11 Mar 2003 16:24:18 -0500

> different offshore machines.

By detecting a burst of auth requests for this user, we can make sure he
gets limited to 50 or 100 messages - far less than the 1000s he could send
before he can show up on any kind of spam list. This greatly effects his
delivery rate and makes it hard for him to make any kind of money. (Assuming
he gets paid by address, or if he buys by the address, it turns most of his
list into junk.) It also makes it a lot more hassle to spam.

---

From: Jason Hihn <[email-masked]>
Date: Tue, 11 Mar 2003 16:31:28 -0500

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Chris
> Lewis
> Sent: Tuesday, March 11, 2003 3:41 PM
> Cc: ASRG

I did not send to him, I sent to the list. The list then sent it out. 
The list would be authenticated by his server, and pass. 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Jason Hihn <[email-masked]>
Date: Tue, 11 Mar 2003 16:43:53 -0500

Addendum. See below.

> From: Jason Hihn [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 4:24 PM
> To: Kee Hinckley
> Cc: ASRG
> By detecting a burst of auth requests for this user, we can make
> sure he gets limited to 50 or 100 messages - far less than the
> 1000s he could send before he can show up on any kind of spam
> list. This greatly effects his delivery rate and makes it hard
> for him to make any kind of money. (Assuming he gets paid by
> address, or if he buys by the address, it turns most of his list
> into junk.) It also makes it a lot more hassle to spam.

In the even that a spammer who does not own his domain abuses and account
(by tripping a validation/sec limit) we can pro-actively black list this
person. I don't think it will technically work due to timing, but it is
entirely possible that the server can get the user's address on the black
list and get it propagated out so that the server can save itself from the
stampede (and save users from receiving spam)

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 11 Mar 2003 16:54:53 -0500

>relationship is with the list, not with all of the users on the list.

And in fairness to Jason, that would work properly in his system. 
Because the mailing list changes the envelope from.  It would, 
however break with forwarders and more simplistic lists.

That assumes we are validating the return-path though.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: [email-masked]
Date: Tue, 11 Mar 2003 17:04:31 -0500

> That assumes we are validating the return-path though.

MAIL FROM:<>

What do you do there?  You can't even say "anything sent with this must
be a multipart/report" - I know for a fact that LSoft's Listserv package
sends out the "your subscription request must be confirmed" messages with
MAIL FROM:<> specifically so it doesn't get back bounces for non-existent
users....

---

From: Jason Hihn <[email-masked]>
Date: Tue, 11 Mar 2003 17:05:27 -0500

> Sent: Tuesday, March 11, 2003 4:00 PM
> To: ASRG

I think they are already 'fixed' unless they are already broken ;-) (="bad
implementation")

> at the best of times), I don't think it's worth going down this hole.

This may be a bit cavalier, but if you're having connection problems then I
think your spam/email would be having problems too...

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 11 Mar 2003 17:16:16 -0500

> relationship is with the list, not with all of the users on the list.

  I agree.  The list has the choice of forwarding a message or not.
So any messages received are sent by the list, not by the subscribers.

  The list server can do whatever work it deems necessary to verify
the originator of a message.  After that, the subscribers only verify
that the message came from the list.

  This understanding simplifies a number of verification systems, and
removes any objections of the kind "but you've got to verify every
party which handled the message."

  Alan DeKok.

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 11 Mar 2003 22:59:04 -0500

> I think they are already 'fixed' unless they are already broken ;-) (="bad

They're not already fixed.  A substantial number of all mailing lists 
are broken.  Ie: can't even detect mailing lists in general.

If they're not fixed now, it's going to be a very difficult problem 
fixing them all (the currently busted and the currently non-busted) to a 
_new_ standard.

> think your spam/email would be having problems too...

Nope, works just fine thanks.  You ever heard of UUCP?  Consider all of 
the non-TCP/IP and non-direct-internet-connected-TCP/IP networks.

Authentication really needs to be inband to be practical.

I've seen a web registration tool that insists on doing a VRFY to your 
mail server to "validate" an email address.

Such things are hideously broken.

We turned off VRFY and EXPN for a reason.  We're not going to turn it 
back on again.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 01:59:32 -0800 (PST)

That simple code for email verification as was discussed in thread
"RE: [Asrg] Several Observations and a solution that addresses them all" 
will not work -  it breaks mailing lists and is otherwise easily abused by 
spammers. But I'v probably spent more time looking at various verification
and callback ideas then almost anybody else on the list, so I'v put my 
notes in format that can be sent by email (see below). But beware these 
solutions are also breakable by spammers and generally require modification
to SMTP prootocol (but same applies to most other proposals, I simply 
have not seen any one idea that can actually work in the long run). 

if you do not mind in a couple days I'll publish notes on callback email 
retrieval as this has not been widely discussed yet. I have notes 
for most of ideas/proposals presented so far to ASRG, some notes are in 
good form (like below), some are not well organized (but I can try to find 
time to do organize it as below and if people are interested, post this 
to the list). I planned to post all this to website as well, never got 
around to it so far...

From what is listed below, read #3. It does same as MAIL-FROM even more, 
but does not break anything (i.e. mailing lists, forwarders). 

1. Simple callback to verify email address
 Technology/Idea:
    When email is received and MAIL FROM command has been issues, the 
    receiving email server looks up MX for the domain entered in MAIL FROM
    and then connects to that server to verify sender address exists
 Origin: Postfix mailing list
 Pros:
   a. Easy to do using existing SMTP commands (like VRFY, EXPN or using RCPT)
   b. Implementations already exist and works fairly well
   c. Does not require modifications of SMTP or breaks anything
 Cons:
   a. Nothing is stopping spammer from using valid email address in FROM 
      even if they are not authorized to do it. Futhermore they could 
      still use different "From" header which will be seen by users as 
      the actual sender email address
   b. Nothing is stopping spammer from having valid domain name and having 
      it answer yes to all verification requests (but valid domain name 
      makes it easier to track spammer if we know where his mailserver is 
      located permanently)
   c. Email server operators do not want to allow email address verification 
      because this is abused by spammer to gather list of valid email addresses
 Summary:
   Usable now with no downsides but offers little protection against spammers

2. Callback verification with messageid tracking
 Technology/Idea:
    MTAs keep track of all outgoing messages for certain period of time
    (say 5 days) and when email is received, the server looks up MX and 
    then tries to verify that email really came from that domain by check 
    with mail server through special verify command to see if messageid is
    real. Variations require either messageid to be synchronized among all 
    MX servers or that verification be done for each MX servers listed or 
   that only first (MX 0) keep messageids and all other syncronize with it.
 Origin: (not entirely certain, one of mailing lists, TBD)
 Pros:
 a. Unlike #1 it allows verification only if email was sent, so no chance 
    of email address harvesting
 Cons:
 a. Spammers can use valid email domains and verification - see 1.cons.b
 a. Requires modification to SMTP (new command of extension to VRFY)
 b. Requires mail server to keep track of messageids for all outgoing email, either
    with separate database or using log files
 c. Breaks ability to send email directly and set from address unless email is 
    relayed through proper domain's from address 
 d. Syncronization of messageids among all MXs is difficult to accomplish and 
    all MXs being checked for messageid create too much delay
 e. Message can not be rejected at mail transmission time as messageid is 
    not available then, so entire message HAS to be received and then go 
    through filter and if messageid is wrong its, then returned back. 
 f. This approach relies on that email messages are received within 
    certain period of time (no long delays during transmission), otherwise 
    the message tracking information may no longer be available. It should 
    be noted that because of this, all verification must be done by 
    receiving mail server and not by mail client, because mail clients
    may check email several weeks too late and if this filter is installed 
    on mail client it could say that message is not authorized because it 
    checked email after message tracking information has already been deleted.
 Summary:
   Because of cons c & d this is not likely to be accepted by entire community 

3. Complex callback verification requirying full message tracking server 
   functionality with dns extensions
 Technology/Idea:
   Either new protocol/system is used for tracking mail message or its 
   integrated into SMTP as new extension. Either way this is complete system
   where outside autorized agent program can add and possibly delete message 
   tracking information into special database. A new Message Tracking 
     Header is introduced that has at least the following information:
   - sender email, - unique message id, - name of message verification server
     Additional extension to DNS is also necessary to list all possible mail 
   verification servers for the domain, this maybe either new field (MC) 
   or special agreed DNS name (mail-verify with CNAME or A) or with 
   possibly in-addr representation of agreed subdomain with A 127.0.0.1
     When mail server has received an email and supports this functionality, 
   it should parse message tracking header. First it needs to verify that
   listed sender email address is either one of mail transmission FROM or 
   the one in "From" header. It should then check on verification server by 
   by finding ip for listed name and then checking in dns for sender email
   domain to see if its one of authorized verification servers. If it is, 
   then connection should be made to that server to verify that listed 
   message id and message from (and possibly date) are as then are in that 
   server, and if it is, tracking information should be deleted (special 
   command is issued from connecting party when its verified and n
   mail can then be delivered.
     When new message is being sent, it can be sent from arbitrary location
   and arbitrary email address can be intered into "From" if necessary, but
   email message must be entered into correct verification server for that
   From domain and its up to the verification server to provide functionality
   to verify that you're allowed to use that particular email account 
   - this can be based on ip (most simple way)
   - if integrated into SMTP it it can be made part of AUTH
   - Possibly certificates can be used (maybe with STARTTLS) with certificate
     being issued and verified by user's ISP (so no central authority is needed)
   Whenver possible verification server should not only check that user is allowed
   to send email with from address from that domain but that user is actually
   who he says he is (i.e. his email address).
     Possibly message tracking should include also details on how long message
   ids are kept on message tracking server (expiration time).

 Origin: Compilation of several ideas (spaml & other mailing lists) plus DNS
         part taken from Vixies mailfrom. Actual proposal this full form is mine.
 Pros:
  a. Provides functionality to verify that email was sent by particular 
     sender and he has right to use that email
  b. System is similar to MAIL-FROM proposals but does not break mailing 
     lists or forwarders and in fact can be implemented with full backward 
     compatability
 Cons:
  a. Spammers can use valid email domains and verification - see 1.cons.b
  b. Probably will require modification to SMTP protocol for verificaiton
  c. New verfication server must keep track of all messages which requires 
     serious additional resources (cpu & storage)
  d. Message can not be rejected at mail transmission time. See #2.Cons.e
  e. Messages must be transmitted quickly (within period of time, tracking 
     is done). See #2.Cons.f for details
 Summary:
   Generally pretty good at determinning if user is allowed to send email 
 from mail domain (like RMX proposals) and does not break existing system.
 It does require modification to all mail servers and to protocol to be 
 of any use. Since this does not provide global verification, spammer can 
 make new system in compliance with new protocol/extensions and self-verify
 his emails, but having ip address of verification server can allow to 
 keep track of origin of emails sent by spammers.
 Additional Notes (STSA):
   Idea should be explored futher to use this with certificates, possibly
 approach is to issue certificates to verification servers and they can 
 issue certificates to users. 
   Possible if emails are groups together on the verfication server by who 
 sent it, a special command can be established to check how many emails
 this particular user has sent to determine if emails are sent in bulk
 (but because sender is providing his own verification, he can easily lie...)
    It would usefull to be able to deleted message tracking when message
 has been received (i.e. destination mail server can delete it after 
 verifying the message), unfortunetly this does not work well with mailing
 lists where multiple receipients receive the same message and all need 
 to verify it. But possibly sender can specify if email is certainly for 
 one user or possibly after delete command is received, message would not 
 be deleted immediatly but faster then usual.

3b. Complex callback verification with dynamic dns used for verification
 Technology/Idea:
   This is not idea on its own but variation of #3, so read #3 first.
   Particular to this variation is the idea that dynamic dns can be used
 for verificaiton which would not require modification to SMTP. In particular
 the setup would be such that when some server/user sends out email, it contacts
 special one of specially listed dynamic dns servers (as listed with special
 record for a zone its using for FROM) and adds new zone to it being actual
 messageid. The zone would include, several records - EMAIL (TXT record with 
 actual email address), VRFY (either A or CNAME of verification server). 
 SOA of the zone would already include date and expiration info, which is
 usefull. DNSSec can be used for secure verification and to establish identity.
 Origin: 
    My unpublished idea to go along with complex verification.
    Late addition - around March 02, 2003 (most other notes are from Nov/Dec 2002)
 Pros:
   a. Everything listed for #3.Pros applies here
   b. Particular to this is that this would not require modification to SMTP
      protocol
   c. Since DynDNS software is already written and widely used, this can 
      be implimented fairlyquickly
 Cons:
   a. Everything listed for #3.Cons applies here
   b. This will most likely require dedicated ip address for dyndn sserver 
      as such this can be a problem for those who currently run everything
      (dns, mail, etc) from one ip address
   c. I have serious doubts that DynDNS can handle such a high frequency 
      of updates/additions that would happen (though retrievals would be 
      no problem) and that it can actually handle millions of subdomain 
      zone files. STSA and preferably ask dns experts
   d. Even without modification to SMTP its still necessary to modify transmission
      servers to enter correct info about eash message as well as modify 
      receiving servers to check for special header, etc. So in the end 
      this still requires changes to how SMTP works
  Summary:
     While pretty neet idea, it probably will not work because of con c

3b. Complex callback verification with modifications to MAIL FROM
 Technology/Idea:
   This is something to go with #3, and is not an idea on its own. Read #3 first.
  Main addition here is that MAIL FROM as used during transmission can be modified
  to indicate that message has tracking information. This can be done as extension
  (ESMTP extension to MAIL FROM). Or it can also be done by modifying actual email
  address, so instead of [email-masked], this becomes:
    [email-masked]
  Hopefully everything after the + can be ignored. But because full FROM address
  is passed along all between all servers used in relaying the message, it'll end
  up going up to the very end (receiving server) even if servers in between
  do not support new extensions. The receiving server that does support the
  extensions can use this information to bounce messages during transmission
  instead after email is already received and email headers can be retrieved.
 Origin: 
   My idea to go along with complex verification, part of original notes separated
   because this particular extension can break mailing lists
 Pros:
  a. See #3.Pros
  b. Additionally bad email can be bounced during transmission in most cases
  c. This basicly automaticly cloaks sender's email address which makes it 
     more difficult for email harvesters. 
 Cons:
  a. See #3.Cons
  b. This would fail with many mailing lists and there everything would 
     still rely on special header. This can not be used as substititure 
     for this "tracking" header
  c. Very long MAIL FROM can be a problem with old email servers.
 Summary:
  Because of cons b & c, probably better to go with ESMTP extension but 
  still STSA

----
William Leibzon
Elan Communications Inc
[email-masked]