ietf-asrg
[Top] [All Lists]

Re: [Asrg] The Consent 4-Tuple

2003-03-06 18:34:49
On Thu, 06 Mar 2003 14:07:23 -0500  "Alan DeKok" wrote:
 +------------------
 |      The Consent 4-tuple
 |      -------------------
 | 
 |   The general model for email traffic is that there is an email
 | originator (end-user), a local SMTP gateway, a remote SMTP gateway,
 | and a final recipient of the email.  To use unique terms:
 | 
 | #--------
 |   email originator -> SMTP sender -> SMTP receiver -> final addressee/user
 | #--------
 +------------------

I applaud your effort to make an algebra for spam. But I think that your
notation misses the target.

The common literature uses the terms Sender MUA, Sender MTA, Recipient
MTA, and Recipient MUA. I'm not sure that there is much to be gained by
changing the terminology. I think that there is room for definitions of
true sender and true recipient too. Also I'm fuzzy on the difference
between * and 0 in your notation.

Each of these components is an agent for "real people", namely: the
sender and the recipient. I might need a little hand waving here to cover
bots, reflectors, list managers and the like but even they are setup on
the behalf of real people.

The goal of the Sender MUA/MTA pair is to implement the wishes of the
sender and the Recipient MTA/MUA is to implement the wishes of the
recipient.

The sender always "consents" to send the mail (modulo accidents). So we
would never see mail that it is unlikely that the Sender MUA would work
in a way against the senders wishes. And it would be totalitarian indeed
if it did. The Sender MTA may choose to throttle traffic from the Sender
MUA on grounds of self preservation but it seems unlikely that it would
implement any higher policy that prevents it from attempting to achieve
the senders desires.

So the job for the senders MUA/MTA are simple: Get the mail into the
hands of the recipients MTA/MUA.

The recipient MTA/MUA on the other hand works for the recipient.
Its goals are more complex. It must attempt to meet two conflicting
wishes on the part of the recipient. First of these wishes is to
see mail that the recipient wishes to see. Second is to not see
what they don't want to see.  Because the recipient has not yet seen the
mail this is a problem of prediction and thus has lots of interesting
failure modes.

Both the recipient MTA and the recipient MUA and the network surrounding
them may provide some traffic shaping/blocking features to protect their
availability.  Then both the recipient MUA and MTA may run various
categorization and markup features that allow the recipient to
select/sort her email.

An algebra to describe spam will involve the recipients view of
email.  Mostly it will require notations for functions on the feature
space of the email message and the recipients wishes.

--
    Chris Fedde
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>