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.
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).
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.
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).
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.
What's more, it might well be COUNTER-PRODUCTIVE to our case just as it's
counter-productive for so many people to be using the same Outlook and
Outlook
Express E-mail clients; it just gives spammers a common, familiar base to
find
and exploit "universal" weaknesses in.
Does that mean we should abondon SMTP and HTTP since people can find
holes in them?
No. Those are basic protocols and are needed for the Net to interoperate.
What
we are talking about here is NOT base functionality.
A protocol that is properly designed and implemented,
will not be a problem.
It's much more difficult to decide what is "properly designed and implemented"
when you're dealing with several orders of magnitude more degrees of freedom.
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).
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.
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."
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.
I think what's the MOST important is that we get SOMETHING out that
significantly helps the recipient users, and soon enough that it's still of
value to them.
Definatly.
Are you suggesting that the receiver simply chooses not to receive certain
kinds of email and that email starts to bounce?
I think the recipient ought to have the choice of how to deal with certain
types
of messages. "Bounce it" might be one option, although probably not a good
one
since there are NO guarantees that there is even a valid POP3 mailbox at the
sender end (and even so, that it's possible to determine what that POP3
E-mail
address might be... clearly, a LOT of spam and viruses go out with
forged/bogus
sender addresses, as we've seen recently).
I believe that in general, either just t-canning (or holding in limbo for
some
time period, pending triage and final resolution) is probably a better
approach
overall. I think that the best approach for most spam and virus mails, and
with
ultimately the lowest total cost to the Net, is to simply route them all
(commensurate with the recipient's established and specified permissions
rules)
down a black hole, and the sooner the better after they're sent.
RFC 3464 defines a DNS format for bounced messages which gets delivered
with the MAIL FROM <> line in order not to bounce again.
That would be fine as one of the options, although I've not seen many messages
of that sort.
If a message
gets "t-canned" and not delivered, the sender will not find out about it
and might assume the email went through.
E-mail has never really been a "guaranteed delivery" medium. Even if it got
into the recipient's inbox, that doesn't mean they got around to reading it
before it timed out, or they changed ISPs and never picked it up, or
accidentally deleted it unread, or had a disk crash, or whatever, And (for
instance) even "confirmed" delivery to a relay doesn't mean that it might not
have bounced or otherwise gotten lost when relayed. (Of course, the same is
true about any "ack" message returned too.)
This would change the semantics
of email on the Net which has already begin from the side-effects of
various spam systems.
I don't think it is a CHANGE of the semantics as much as it is an ACCEPTANCE of
(and extension to, perhaps) the semantics that have ALWAYS in actuality been
there.
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.
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);
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.
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.
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!)
Does that make my thinking clearer?
Gordon Peterson http://personal.terabites.com/
1977-2002 Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment! Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg