I would like to re-investigate pull mail systems as a viable solution to
reducing unsolicited mail and apologise in advance for the length of this
e-mail.
for a refresher course, a pull system is where the recipient is notified
that e-mail is waiting for them at xyz.com from person(_at_)xyz(_dot_)com(_dot_)
they then can connect and accept the e-mail or not.
from what I have read people have only considered a *pull* as recipient
initiated.
I suggest moving that responsibility to the recipients ISP's server.
Thus negating the need for any changes to occur at the recipients address
(no need for new software)
neither does the sender require any new software, standard SMTP will
suffice.
To make the following description easier I will make some clarifications
a/ sender is the person sending the e-mail (can be a bulk mail system) and
can be on a dial up connection
b/ senders host is the senders smtp server and is usually his ISP
c/ recipients host is the recipients smtp server and is usually his ISP
d/ recipient is the person to whom the mail is intended and can be on a dial
up connection
e/ transport system is not mentioned and is largely unchanged (probably some
new commands)
d/ "his" means his or her or an automated system and is not meant to be
sexist.
in a classic configuration, mail transport occurs something like this...
1/ sender connects to senders host machine
2/ senders host accepts mail from sender (usually authenticated)
3/ senders host contacts recipients host machine
4/ mail is forwarded to recipients host machine
5/ receiver connects to his host machine and uploads mail
I know this is very rough, it is not meant to be precise. so please lets
move to the next stage
In my preferred implementation of a pull system some additional steps are
added..
1/ sender connects to smtp host machine
2/ senders host accepts mail from sender (usually authenticated)
3/ senders host contacts recipients host machine
3a/ senders host sends mail waiting command (pull request)
3b/ recipients host acknowledges receipt of mail waiting command with a
unique message identifier.
3c/ senders host queues message tagged with ID
4/ recipients host processes request and can apply filtering algorithms
based on recipients personal preferences
4a/ recipients host contacts senders host with unique identifier, thus
authenticating sender.
4b/ recipients host issues a message accepted or denied command (with the
reason)
4c/ if accepted mail is forwarded to recipients host machine
5/ receiver connects to his smtp host machine and uploads mail
You will notice that for the sender and receiver the process is unchanged.
while on the surface this may appear to increase network traffic ultimately
it will significantly reduce it
a lot of the mail that is currently blasted into the network simply will not
happen, including e-mails where the recipient no longer exists (bounced
e-mail).
In addition I propose that e-mails all have a "Class" header this class
header should be sent with the original pull request and can form the basis
of class filtering.
The user can then select to accept mail that is unsolicited based on its
class.
i.e. I will accept unsolicited mail from computer sales companies but not
from tampon manufacturers (I'm a guy ok)
How these would be categorised is open to debate. I assume that such
classification systems are already in wide use and can be tailored to suit.
Yes it is true a sender could abuse this system but of course would soon be
identified. also this header could become the centre piece of legislation
(for those who believe a legislative approach is the only way) and would
form the foundation of any action against a regular spammer.
A word on anonymity
The pull system does not allow for anonymous e-mails, nor should it.
For anonymity people should use forums and news groups. (for political
dissent etc..)
E-mail is for 1 to 1 or 1 to many contact. in this scenario anonymity is not
desirable (nor acceptable).
If I get an abusive/threatening/spam e-mail I would like to know who sent
it. I don't think the sender has any valid reason for hiding apart from
cowardice.
If the e-mail contains sensitive information that the sender does not want
intercepted and then traced back to them, they should either not use an open
system like e-mail or they should encrypt the message by means readily
available.
Regards
Chris
P.S. please respond with targeted criticisms or suggestions, do not make
blanket statements.
then individual problems can be ironed out or explained.
P.S.S. Also please remember that the current system is seriously broken. If
you don't firmly believe that please give me your e-mail address and I will
forward my daily spam to you.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg