Subject: RE: [Asrg] 6. Proposals - Pull System (revisited)

From: "Dag Kihlman" <[email-masked]>
Date: Wed, 26 Nov 2003 18:45:16 +0100

Yakov has a couple of times asked for a document containing pros and cons
concerning pull mail. I started a similar debate about pull a month ago and
I am willing to participate in creating such a document.

Of course there are a number of ways to implement pull mail and each of them
ought to be discussed with pros and cons. Some sort of conclusion ought to
be reached. Cons are best written by push advocates when pull advocates have
reached a certain point of agreement.

Anyone interested?

*** My proposal is in short: ***

Mail from: [email-masked]
Mail to: [email-masked]
Subject: RE: [Asrg] 6. Proposals - Pull System (revisited)
Body: ABC --- XYZ

** Step 1 From sender to sender.server
--- Sent as today

** Step 2 From sender.server to receiver.server
---sender.server: "Mailfrom [email-masked] Send Sendman; Mailto:
[email-masked]; Subject RE: [Asrg] 6. Proposals - Pull System
(revisited); MailId:MAIL-NUMBER;AvailableAt:IP-ADDRESS;PassWord:SECRET-PWD"
---receiver.server: "OK;EncryptWith:SECRET-KEY"
or,
---receiver.server: "NotOK;Receiver unknown"

** Step 3 Storage at IP-ADDRESS
Sender server stores it at IP-ADDRESS encrypted with SECRET-KEY and throws
SECRET-KEY away. (If receiver is unknown a mailer-daemon message is sent)

** Step 4 Receiver connects to receiver.server
Receiver.server sends: "Mailfrom [email-masked]  Send Sendman; Mailto:
[email-masked]; Subject RE: [Asrg] 6. Proposals - Pull System
(revisited); MailId:wqpprt;AvailableAt:IP-ADDRESS;EncryptedWith:SECRETKEY"

Receiver can:
- filter on IP address
- filter on subject
- filter on sender
- allow only certain IP addresses
- disallow certain IP-addresses
- filter on public black- or greylists

** Step 5 Fetch mail
receiver to IP-ADDRESS: "Send:MAIL-NUMBER;PassWord:SECRET-PWD"
IP-ADDRESS: "Body: ABC --- XYZ"
receiver to IP-ADDRESS: "OK"  or "Please Save" If the latter is send
IP-ADDRESS will mark the mail as read but the number of days the mail will
remain is up to [email-masked]. "Please Save" is used by a receiver
who reads mail in multiple places.

The mail program uses SECRET-KEY to decrypt the mail and presents it to the
reader.

Of course IP-ADDRESS can send "No Such Mail" or "Mail Deleted"

** Mail software:
The sender's mail software displays mails in the ouput box. Read mails are
moved to a "Read mails" mail box.

PROS:
1) Sender sees if someone is spamming or sending viruses through his or her
e-mail account and can remove the mails.
2) Filtering is done mainly on IP addresses which must be true and therefore
are excellent to store in black or greylist forums.
3) Sender.server will limit number of outgoing mails and limit the storage
size and thus limit the damages done by viruses or hackers.
4) If you want to spam you will need a server of your own or pay someone for
it
5) IP addresses will be blacklisted or greylisted which will put preassure
on administrators to avoid being cut off

CONS:
1) More space is needed since every mail will be stored separately (I think
it is a PRO)
2) A mailserver cannot easily change IP address (I think it is a PRO too)
3) Pull mail is less reliable and slower since an avarage mail will be
further away from the receiver.

VULNERABILITY:
1) A spammer will probably try to hack computers and install a mail storage
on them. However the operating systems ought to close certain ports and
virus scans ought to check if such ports are opened.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 15:49:07 -0500

If sufficient interest exists in this, than we will consider making a 
subgroup for this effort.

Yakov

> virus scans ought to check if such ports are opened.

-------
Yakov Shafranovich / PGP Key: 0x10D051E6 / www.shaftek.org
SolidMatrix Technologies, Inc. / www.solidmatrix.com
"And this too shall come to pass"
-------

---

From: Brett Watson <[email-masked]>
Date: Thu, 27 Nov 2003 14:38:20 +1100

> subgroup for this effort.

If such a sub-group were created, I would participate in it (or at least 
actively monitor it). I believe it makes sense for such a group to exist, 
just as it makes sense for the RMX-proposals subgroup to exist. Where the RMX 
proposals attack the problem of validating the sender's fact-claims, a 
"transport" subgroup can attack the problem of ensuring an appropriate level 
of recipient control over the mail transfer process.

Regards,
TFBW