3. Requirements - Consent (was Re: [Asrg] Re: 3. Requirements document)

gep2(_at_)terabites(_dot_)com wrote:

> > > > How would you suggest that recipients would go about granting and 
> > > denying permissions (or consent) if there are no standards in place? 
>
> > > I think that that is an issue to be described by the documentation for the 
> > > software involved, and/or the online help files that accompany it.  I don't 
> > > think there needs to be ANY worldwide consensus on how that needs to be done.
> > 
> > What about the MUA communicating with the MTA? 
> > 
> I don't believe that it's necessary to do that.
Just for the record, I meant the receiver's MTA and MUA.

> First of all, either the receiver's mailbox will accept a message in a given 
> format or and of a certain type or it won't (and that could be changed by the 
> recipient at ANY time prior to the message ACTUALLY BEING SENT).
So do you want this to happen at the receiver's MUA? What about his MTA?

> One tenet of good program design is that you should not encourage a program to 
> make irrevocable decisions based on potentially incorrect information.  If the 
> recipient tells the sender that (at this precise instant) a given type of mail 
> is acceptable, and the sender proceeds to send it, the permissions list could 
> still change before the attempted message actually arrives... and then needs to 
> be blocked or bounced or T-canned!  Better, I think, to just let them send it 
> and then the chips fall where they may when the attempted transmission actually 
> arrives.
I see consent as something subject to change at all times. In theory the 
receiver will set his consent policy (at MTA or MUA level). The sender 
will send a message and may receive a consent token back. However, 
nothing prevents the receiver from changing consent policies midstream. 
In that case the original consent token is revoked on the receiver's 
side and the sender will receive a notification either via email or at 
the time he tries to contact the receiver.
> > Wouldn't a standard way of communicating consent between the MUA and MTA help?
>
> I'm not convinced that we need anything beyond what we already have.  (And 
> non-compliant points in the path are STILL going to need to map any "extended 
> result codes" to one of the current basic set of results anyhow).
I am refering to the receiver's MTA and MUA, not the senders. Want to 
make sure we are on the same page.
> In essence:
>
>    1)  Can't find POP3 server there (no need to retry, probably);
>
>    2)  Can't establish connection with POP3 server (down? backbone problem?  
> DDoS?) (retry later, probably);
>    3)  Found POP3 server, but no such user there (no need to retry, probably);
>
>    4)  Found POP3 server and user, but mailbox full (might want to retry again 
> later);
>    5)  Delivered message to POP3 user's mailbox (note that this MIGHT be a 
> relay, in which case one cannot really still draw any conclusions about 
> SUBSEQUENT deliverability...!) 
>
> Unless any "communication of consent" was done during the time the message was 
> being CREATED, at which point ARGUABLY the sender's mail client program MIGHT be 
> able to modify the message, by the time it's in transmission it's probably too 
> late to do anything about it.  This is ESPECIALLY true if there is a relay 
> involved, or if there's a mailing list redistribution perhaps.
> And of course, in the case of spammers, there's usually no obvious way to really 
> return a meaningful status to the "sender", even if it WERE a good idea to tell 
> them anything useful at all about the recipient's presently active level of 
> defenses.  Usually the "sender" is either bogus (nonexistent) or innocent 
> (joe-jobbed).
> If you had a castle being defended by an intelligent forcefield, you don't want 
> the message to go back to the enemy that "this castle's defense forcefield is 
> programmed to only let in shells carrying less than 30 pounds of explosive!".  
> Obviously, in that case, the attacker just configures each of their shells to 
> each carry 29.985 pounds of explosive and fires away.  :-(
> I think that the recipient ought to be able to choose (and in confidence) their 
> own policy regarding what types of messages are bounced, which are refused, 
> which are quarantined, which are delivered, which are perhaps forwarded (or 
> auto-responded, for that matter), and which are simply routed to the bit bucket. 
>  
Once again the consent policy we are talking about is being set by the 
receiver and communciated to his MTA/MUA and possible the ISP. In 
certain cases portions of the policy MAY BE shared with the senders in 
accordance with the rules that the receiver set. Examples of these might 
be C/R systems or hashcash systems. Another example would be your 
attachement-free system where the sender might be optionally notified 
that permission is needed before attachments. That notification would in 
fact be considering having the receiver share a portion of this consent 
policy with the sender.
> >
> >>>Since in a "proper" (IMHO) recipient-chosen, recipient-controlled system 
> > there 
> >>>is NO need for senders to interact directly with the recipient's chosen 
> > software 
> >>>(other than just by existing SMTP/POP protocols) I don't think there's any 
> > > pressing need whatsoever for a worldwide permissions-and-control "standard" 
> > for 
> >>>interacting globally with these programs.  I believe that the market itself 
> > will 
> >>>sort these things out, to the extent the need to be, in a relatively short 
> > time.
> > 
> > The consent exchange protocol would be useful primarly for telling your 
> > MTA or ISP on what types of choices you made. 
>
> Once these choices go much beyond simple grep-type things (i.e. simple 
> braindamaged regex-type pattern matching) you almost really want to be able to 
> (at least optionally) do full-fledged programming to describe the 
> acceptance/permission process... complex (perhaps nested) if/then/else, compound 
> logical expressions, more sophisticated pattern matching, maybe even macros, 
> wildcards, macros, function calls, "fuzzy" weighted criteria, maybe even stuff 
> requiring use of external programs (e.g. "run PKUNZIP -t on any zipped 
> attachments, and then if the CRC isn't correct...:", or "run a virus scan on the 
> attachments, and then based on THAT outcome...", etc etc.)  Unsophisticated 
> users are likely to use this kind of thing (at least initially!) only at a very 
> basic level, such as (in effect) "let Aunt Bertha send me pictures, don't let 
> anybody send me executable attachments."  More sophisticated users might need an 
> (even QUITE elaborate) set of rules depending upon who is sending, and which of 
> the recipient's (perhaps large number of incoming E-mail addresses) they're 
> sending to.
> Anyhow, I think that the requirements at the recipient end (and variety of 
> permission options and criteria) are likely to be varied enough that I don't 
> really think there's a whole lot of point in trying to establish standards to 
> make those meaningful to describe across a wide variety of diverse programs, 
> especially if there are many different levels and versions and implementations 
> of software at the originating end(s).
HTTP is currently being used for many other things besides HTML. There 
is no reason why a transport protocol cannot be used to exchange consent 
rules that are pretty complicated as long as its pretty generic. 
However, there are many basic things in consent that will remain the 
same across all or most systems. Certain types of consent tokens such as 
digital certificates, hashcash, C/R, etc. also would benefit greatly 
from being standarding so the systems using them can interoperate (which 
is the thrust of the CRI proposal). There are many benefits to 
standardizing portions of consent systems, while leaving many portions 
to the implementors.

> > Exchanges between senders 
> > and receivers might only occur in certain cases such as C/R, or opt-in. 
> > This would depend on how the protocol and the framework are designed.
>
> I think that C/R is for the most part a nonstarter.  Way too many mailing lists 
> and other automated software is already in use and whose owners simply have NO 
> ability or willingness to jump through such hoops to get their stuff delivered.
Nevertheless people use these systems, and we should consider them as 
well (a protocol such as CRI or a larger consent protocol is support by 
mailing lists, etc. can alleviate the problem but not make it go away). 
Plus in certain places C/R is great - such as confirming whether people 
actually want to subscribe to a mailing list.
> As for opt-in (and I'm a GREAT believer in opt-in) the way to handle that is 
> simply to NOT MAIL TO ANYBODY *until* that recipient has given you permission to 
> send to them.  And unless you've arranged with the recipient in advance (and 
> presumably by whatever mechanism makese sense under the circumstances), the 
> sender shouldn't IMHO presume to send anybody bulky HTML-burdened E-mail, or 
> attachments of ANY kind.  They ought to send least-common-denominator simple 
> ASCII text E-mails unless and until they are given permission to send anything 
> beyond that.  
>
> That is NOT the same thing as "go ahead and send anything you feel like, and the 
> recipient will tell you if they don't accept that."
A consent standard may help to grant and store record of that grant of 
consent once the receiver decides to opt-in. I am not advocating 
communicating consent after the email is sent, rather this is something 
to be left to the implementors to decide. People who want to receive 
email before exchanging consent can do so, others can choose not to.
> Your permissions might not even be based solely on the CONTENT of the E-mail;  
> for example, it might be conditional based on something totally alien to the 
> sender, such as (to try to prevent inbox overflow) "hold off E-mail containing 
> attachments if I've already got attachments [maybe even just ordinary E-mails] 
> waiting in my Inbox that haven't been picked up for more than an hour".
> There's almost an infinite variety of such kinds of rules one could imagine, and 
> I don't think it's either practical OR desirable to try to envision all possible 
> ones in advance, or to standardize their descriptions, let alone the 
> interactions and priorities of testing/switching/decision trees based on each 
> one.  These are going to be determined by the particular features of the 
> implementing software, mostly at the recipient end.
That's is correct. That's why we are not seeking to define the 
implementation details, rather just the framework and protocols to help 
consent systems interoperate. For example, two specific consent systems 
can be build in completely different ways but they can still benefit 
from a common protocol in cases like C/R, hashcash, digital signatures, 
etc.
> > > > If so, there is still a need to have some form of a format or standard in 
> > > > > > place that the receiver can use to communicate his consent decisions to his 
> > MUA, 
> >>>MTA or ISP.
>  >>>I don't think that that needs to be the result of a worldwide standard, in 
> > part 
> >>>since the capabilities of different permissions list implementing systems are 
> > > likely to be VERY different, and may result in having quite different needs 
> > to control those capabilities.
> > 
> > > For example, some of these filters might be implemented by Web-based tools, 
> > and 
> >>>others might be based on E-mail-type control commands.  These two methods are 
> > > likely to be (even VERY!) different.  These are the types of things which 
> > > individual ISPs and software providers are likely to use for 'product 
> > > differentiation' that will give one ISP or software an edge over another.  I 
> > > don't think these NEED to be the result of a 'standards' effort.
>
> > The consent framework and protocol will define a framework for these 
> > tools to interoperate. The implementation details of what kind of data 
> > is exchanged can be left out of the standard.
>
> I understand the desire, but I think it's misguided.  IMHO there's little reason 
> to exchange information if the format of the information being exchanged isn't 
> useful for any meaningful purpose.  It's sorta like the old programmers' axiom 
> of "don't test for errors you don't know how to handle."
> For example, for MY personal E-mail filtering system, which is written in 
> SPITBOL, I could envision that I might want to program specific little handlers 
> describing the logic to be used for handling E-mails with given to/from address 
> pairs.  (SPITBOL allows program source code to be read from a data file at 
> runtime, precompiled, stored as a variable of type "code" into associative 
> tables, re-activated later, etc etc.)  As a bonus, SPITBOL supports what is 
> probably just about the most sophisticated and powerful text pattern recognition 
> engine and capability of any general-purpose programming language, so I'd want 
> the option to use that capability to describe my filters and transforms too.
> While capabilities like that make MY filter exceptionally useful, there's no 
> reasonable way to presume that someone else (who's likely to be using a tool 
> written in something primitive like Perl or whatever) is going to be able to 
> make sense of a SNOBOL pattern or logical expression... nor should I cripple my 
> own more powerful tool by limiting it to a permissions "standard" based on only 
> just braindead regex-style pattern matching descriptions.
> So anyhow, now you've got (in your end's Perl-based tool) a totally alien 
> SPITBOL-flavored description of my own filters and mail handling criteria 
> expressions, and you haven't a clue what they represent.  So what good does it 
> have you to have a (even "good") copy of them?
> There *might* be a reason to try to standardize stuff like this, IF there were a 
> truly compelling argument to be made about why there NEEDED to be a consensus or 
> communication between various sorts of different software, or more particularly 
> between the sender and the recipients' various mail handling agents.  But I'm 
> not convinced that there is in fact much fertile ground there, despite this 
> fuzzy sorta warm (but still not very convincing) "there oughtta be a way" 
> notion.
There are plenty of reasons. Simply speaking there are no protocols for 
spam tools to talk to each other. And as much as we may hate "opt-in" 
having a standard for audit trails as a side benefit might help.
> What I *actually* expect is more likely to happen, instead, is one or more of 
> the following:
>   1)  Users are going to give up on the ISPs and IETF really getting a grip on 
> this problem, and default to using their own widely divergent array of spam 
> content-based filtering tools (SpamAssassin or whatever);
They have already done that and if you have noticed the ASRG is not 
exactly popular in the newsgroups :)
>   2)  ISPs and domain providers are going to choose one of a perhaps wide 
> variety of tools to attack the problem, even perhaps writing one of their own 
> (AOL, perhaps, might take this approach) and tailor it precisely to their own 
> users and purposes... and use the specificity to differentiate their service 
> offering from that offered by other ISPs, and coincidentally to help "lock in" 
> their customers who will stay with that ISP or domain provider rather than 
> having to "start over" redefining their filters and processes using the 
> dissimilar tools offered by competing ISPs.
They have already begun using tools. We are seeking a way to unify them.

> Alternatively, we might come up with some kind of a standard here which is nice 
> but not sufficiently flexible that even after it's adopted net-wide, then some 
> ISP comes up with something more powerful and flexible (say, more like a 
> SPITBOL-based filter evolved from what I've been using here) and while not being 
> standard-compliant, is compelling enough that it makes the "standard" version 
> obsolete.  
We are not seeking to create a standard implementation - we are only 
seeking a generic framework and some protocols, and formats. ALL or MOST 
of the implementation details will be left upto the implementors. I 
think we need to clear this point up.
Additionally as a long term goal we might seek to change the 
architechture and email standards on the entire Internet such as (gasp) 
kill or change SMTP. As a short-term that is not possible, but as a 
long-term goal it might become an option. That is something that only 
the IETF can accomplish since they are the keepers of SMTP and related 
standards.
> I think there's a lot to be said for keeping the process single-ended (i.e. not 
> doing anything special or even different between sender and recipient agents)... 
> in fact, not changing the sender end AT ALL (other than, hopefully, encouraging 
> plain ASCII text as the 'standard' format for unexpected transmissions and 
> discouraging unexpected attachments and spamming!)
We would seek to address the receiver first and his MTA. Then we can 
work our way from there upstream. Also, BCPs - plenty of possibilities 
there.
> Does that make my thinking clearer?
A bit but I am still not on the same page as you. I also want to make it 
clear that "consent" is not the only options available to us. Even 
though the charter focuses on consent it is not cast in stone and can be 
changed if a strong enough reason arises. So we are open to other 
"non-consent" possibilities, but as of now, the consent framework is 
looking to be a good direction to research.
Yakov


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