At 11:40 AM 6/30/2003 -0500, gep2(_at_)terabites(_dot_)com wrote:
> ...This can be considered a consent-based concept, as it can be a
parameter at
the ISP end for each mail user. It adds quite a bit of overhead to the mail
server as it requires two additional messages for each one sent. I see it
being part of the MTA process. I send a message to someone. The MTA
replies to the message with a "proof of sender request, " basically a
specially formatted email message that goes back to the server that sent it
based on the return address.
The idea sounds promising other than that initial,
perhaps-not-quite-fatally-flawed premise. You've fallen into a big trap that
confuses many folks... folks who don't realize that SMTP mail servers and
POP3
mail servers represent in fact two quite different entities (despite the fact
that SMTP servers at some point talk to POP3 servers). Specifically, at the
sender's send, the SMTP and POP3 mail servers are not only not (usually) the
same program, they are *quite* often not on the same machine (and
moreover, may
not even be under the ownership of the same company!).
[..]
This is also a concern with C/R since it relies on a similar approach.
Currently I believe C/R companies such as MailBlocks are web based and thus
all of their servers are together. Implementing this approach and C/R,
would cost users in flexibility to be able to work with multiple servers.
This problem might be alleviated slightly by writing a protocol for these
servers to communicate with each other, but then all kinds of other
problems pop up (mainly resistance to change).
But even disregarding that problem, a more basic issue with this whole
avenue of
thinking is that it has to be handled by basically the whole Net before it
can
be useful... it's not a scheme (as mine is) which can be implemented
incrementally, starting with as little as one single POP3 server.
Unless this POP3 server can communicate with the SMTP server. If a
communication protocol exists, then this approach can start of with pairs
of SMTP/POP3 servers. Another approach would be to do the verification in
the MUA.
> The sender's MTA responds with a "confirmation
request" if it did send the message and the message is now available for
download based on moving it from the pending directory to a user directory.
If there is no response within a certain period the message is discarded.
It's a similar concept that I use when I get a telemarketer who I may want
to pursue what they are selling. I ask for their phone number and call then
back. Granted I don't do this very often as I usually tell them to take me
off their call list and hang up. If this has been mentioned I apologize as
the volume of messages is quite large on this list.
[..]
Yes this has been mentioned prior.
[..]
> The bottom line is that consent should be easy for the general user to deal
with and understand.
On THAT part we're definitely on the same page.
How about something like:
mail to gep2(_at_)terabites(_dot_)com
default
allow plain ASCII
from cluelessaunt(_at_)aol(_dot_)com
allow HTML only safe
allow attachments only (JPG,DOC)
from friend(_at_)china(_dot_)net
allow encoding including (base64,printable)
from george(_at_)arthurandersen(_dot_)com
allow attachments including (XLS)
from internalsupport(_at_)mycompany(_dot_)com
allow HTML including (scripting,Javascript)
allow attachments including executable
from md5hash(reallysensitive(_at_)secretisp(_dot_)gov)
allow attachments including (JPG,ZIP,PGP)
allow encoding including (base64)
from sailboatphotos(_at_)yahoogroups(_dot_)com
allow attachments only (JPG,DOC)
from statements(_at_)mybank(_dot_)com
allow HTML
from susanprogrammer(_at_)trustedcompany(_dot_)com
allow attachments including executable
from tom(_at_)adagency(_dot_)com
allow attachments including (TTF,GIF,DOC,PPT)
from trustedfriendtom(_at_)hisisp(_dot_)com
allow attachments
allow HTML
mail to gep2hobby(_at_)somdomain(_dot_)com
from sailboats(_at_)yahoogroups(_dot_)com
allow attachments only (JPG,GIF)
mail to gep2bot(_at_)otherdomain(_dot_)com
from senderbot(_at_)somecompany(_dot_)com
allow attachments only (ZIP)
from otherbot(_at_)othercompany(_dot_)com
allow attachments only (XML,ZIP)
Initially, this permissions list could be simply edited, although
longer-term it
probably should be manipulated by incremental add/update through some kind of
menu system, Web page, or maybe E-mailed commands. A good implementation
would
probably maintain at least two copies of the list, one a local copy on the
user's own machine (just for a safeguard backup copy) and the other at the
user's ISP or domain provider (wherever the filtering is going to be done).
If one wanted to use hashing or something (I've hinted at that ability above)
there are a variety of things that might be implemented there (again, we
don't
need worldwide consensus for any of my proposals, since they're basically
single-ended and only involve the recipient user and their ISP or domain
provider). Presumably hashing or encryption would be done, if done at
all, in
whatever way would provide adequate security and not revealing secret
information to those who shouldn't have it (and don't have it anyhow).
Lots of good ideas here.
Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg