Notification scheme for reducing spam

On Aug 22, 2006, at 8:24 AM, osolin-l wrote:

> * Sending client composes and delivers message to his ISP's mail
> server.
>
> * Originating mail server stores his client's message and sends out
> an email which notifies the intended recipient that there is a
> message waiting for pickup.
>
> * Recipient's mail server receives notification message and holds
> it in the normal manner until recipient signs on with their client
> to download notification messages.

This was being discussed semi-seriously at least four years ago.

> [3] Even after downloading the actual message from the originating
> server the recipient may initiate a spam report to his ISP for
> action/processing.(This allows for automated blacklists based on
> actual human responses. Blocking notification messages not yet
> delivered, which can then be returned to the originating server.
> This also allows tracking of malicious reporting.)

User spam reports are notoriously untrustworthy. AOL users regularly
"unsubscribe" from no-longer-wanted mailing lists by reporting them
as Spam to AOL. I know of one case in which a family member of the
sender of a message about possible dinner together over the weekend
reported that message as Spam to AOL. And then wondered why s/he was
no longer receiving messages from that family member. The problem in
the above paragraph is the "automated" part.

(AOL, at least in the past, made this extra easy to do by having the
Report Spam button near the Delete button, so some Spam reports were
simple mechanical errors.)

So, my reactions:
1. I think it's a good idea (and did when I first heard of it).
2. It's not going to happen, even though the spammers have killed
email as it once worked well

Remember that Microsoft Outlook Express still uses encryption
protocols which were never officially standardized and were
deprecated a decade ago--and are supported by servers ONLY because of
OE and Outlook. And, further, by default does that on a port which
has now been officially assigned to Cisco for a new protocol and was
never standardized for the email usage. (Outlook 2007 beta has been
updated...there's a decent chance that Microsoft Mail (the Vista
replacement for OE) has as well, but I haven't seen it.)

     --John

On Tuesday, August 22, 2006, at 01:22PM, osolin-l <osolin-lshaw.ca> wrote:

>Alter the standards slightly on how email clients and servers interact:
>
>* Sending client composes and delivers message to his ISP's mail server.
>
>* Originating mail server stores his client's message and sends out an email which notifies the intended recipient that there is a message waiting for pickup.
>
>* Recipient's mail server receives notification message and holds it in the normal manner until recipient signs on with their client to download notification messages.

This sounds like a good idea to me. Might we do a test drive someplace?

On 8/22/06 at 8:24 AM, osolin-l <osolin-lshaw.ca> wrote:

> Do you think it could work?

Not in all cases, and thus not practically. This concept relies on
stable, reliable connectivity to all mail server sources, which is just
not the case currently. I'm thinking in particular of mobile and remote
scenarios, such as ships at sea, research field stations, 3rd world
areas, and the like. These locations typically only have windows of
connectivity through which to send and receive mail, and those windows
are kept as small as possible to keep costs down. As described,
recipients need full-time interactive access to the internet at large to
retrieve their mail, and their local server needs 24x7 accessibility
from the world for their outgoing mail to be received. Not gonna fly
when satellite connectivity is your only option and it's measured in
dollars/euros/etc per minute.

- Todd

On Aug 23, 2006, at 3:46 PM, Todd Ruston wrote:
> On 8/22/06 at 8:24 AM, osolin-l <osolin-lshaw.ca> wrote:
>
>> Do you think it could work?
>
> Not in all cases, and thus not practically. This concept relies on
> stable, reliable connectivity to all mail server sources, which is
> just
> not the case currently. I'm thinking in particular of mobile and
> remote
> scenarios, such as ships at sea, research field stations, 3rd world
> areas, and the like. These locations typically only have windows of
> connectivity through which to send and receive mail, and those windows
> are kept as small as possible to keep costs down. As described,
> recipients need full-time interactive access to the internet at
> large to
> retrieve their mail, and their local server needs 24x7 accessibility
> from the world for their outgoing mail to be received. Not gonna fly
> when satellite connectivity is your only option and it's measured in
> dollars/euros/etc per minute.

This is true. It would be possible to have these users send their
mail to a server on land which is wired to the normal networks where
it would be held until retrieved, but the real solution is that
everyone should have a certificate identifying themselves, so you can
verify who you are getting email from. Then you could have
reasonable whitelisting and blacklisting, and even a decent
graylisting system. The problem is that there is no easy and
affordable way for the average citizen to acquire a certificate. The
chain of trust approach is too expensive for the average user, and
the web of trust is 1) not known by enough people, 2) not understood
by enough people, 3) a pain to implement for someone who isn't gung-
ho about it (and often even for someone who is, depending on location).

If we had an infrastructure that supported average users acquiring
certificates, and using them for applications where they should
apply, then getting my primary certificate would be something like
getting my first driving learners permit. Then I would have tools to
readily create a certificate for my email account, and another for
logging into my bank account. Email could routinely be encrypted.

Geoff

As described,recipients need full-time interactive access to the internet at large to retrieve their mail, and their local server needs 24x7 accessibility from the world for their outgoing mail to be received.

In the concept, clients only need access while downloading. The writer is correct for delivery; the server used to send out must have a permenant connection or be able to relay (bad word re:email but accurate) to another server which will do the hosting on its behalf.

The premise is if your server is not able to stick around to deliver the message or receive the bad news that something you sent out was perceived as spam, then you need to negociate with a mail service to represent you. They in turn suffer the consequences if the deliveries are not honourable.

Correct me if I am wrong, but my understanding is that the handling of multiple recipients in a message is currently done by the receiving server. This new concept would put that onus upon the sender's server to provide the bandwidth and processing for the quantity of messages sent out.

The whole concept of stealing an IP address temporarily, blinking into the internet, sending out millions of spam email with your private server and then dissappearing is really no different than a client being able to relay off servers. We no longer tolerate relaying. Why is it reasonable that rogue/roving server's software is allowed to do nearly the same thing?

Please note my observations and opinions are in no way intended to be construed as a reply directed at specific individuals, unless I have specifically named them in my communication.

Sincerely, Larry

Very interesting, Larry, and especially so for me because I have had
grief sending to two recipients using shaw, apparently your ISP, too.

Murray