[Asrg] 6. Proposals - C/R and "callbacks"

[Tony Toews <[e-mail]>]

At 12:00 PM 2003/12/24 -0500, you wrote:

> >  From my very simplistic view of the email systems it seems to me that
> > the msgid id could be part of the verification mechanism.   The
> > originating MTA stamps the outgoing email with a unique message id.
> > Once the header portion of the email is received then the recipient MTA
> > does a name lookup on the originating MTA and verifies that the
> > originating MTA sent that msgid.  Once the receipient MTA finishes
> > accepting the email the originating MTA then never uses that msgid again.
>...
>
>This approach is outlined by William Elan (he calls it "callback"):
>http://www.elan.net/~william/asrg-emailpathverification-presentation.pdf
>This is also mentioned in the CRI proposal (level 2):
>http://www.ietf.org/internet-drafts/draft-irtf-asrg-cri-00.txt

Thanks for the URLs.  I'll review those

>This basic argument against this is that it is very resource intensive,
>with a lot of extra costs such as more powerful servers that can handle
>callbacks, more bandwidth, and extra disk space to store IDs.

More powerful servers?  Well sure but what are we doing now to handle spam 
with word and Bayesian etc filtering along with RBL lookups?   In addition 
the msgid would only be verified by the receiving MTA when the sending MTA 
is actually sending the email header info.  So the msgid is already in RAM 
thus no cost to do a disk I/O to retrieve information.

More bandwidth?  If this kind of thing cuts spam by a significant margin 
that's a good tradeoff. Also the network traffic is only as many bytes as 
the msgid plus some overhead along with the ack by the transmitting 
MTA.   Along with retrieving the IP address of the sending MTA from the 
domain name in the email header.

Disk space?  Every email currently has, or should have, a unique msgid.

>There are
>also DOS issues: someone forging a domain can cause the forged domain to
>go under with too many callbacks.

DOS could happen today with someone sending lots of emails to a given 
receiving MTA.

>There are privacy issues as well, and
>possible replay attacks.

I don't see the privacy issues here.    Replay attack?  Same as a DOS.

>However, the bottom line here, is that why go through the trouble of
>checking every single message. Granted that it increases costs,
>nevertheless if we can significantly reduce the problem through
>verification of MTAs as opposed to senders and messages, why go through
>the extra costs of message verification. This proposal is on the table,
>but we will pursue it only if a significant advantage vs. costs can be
>proven for this way of doing things, over others requiring less costs.

Ok, this makes sense.   But if I understand the proposals the public key 
will be retained by the DNS servers.   Thus increasing the load on those 
servers.   Mind you they would be cached by your "closest" DNS server so 
that wouldn't be too bad.

Tony
-----
Tony Toews, Microsoft Access MVP
Microsoft Access Links, Hints, Tips & Accounting Systems at
    http://www.granite.ab.ca/accsmstr.htm