Re: Hello from a new subscriber was Re: Just Wondering...

Shae Matijs Erisson wrote:

> A: You send your email to your ISP via SMTP, just as always.
> As for receiving email, your client will need to pick up from many different
> POP3 servers, rather than just picking up from one as now.

Would POP3 really be appropriate for this?  I think the mailserver 
should handle picking up the mail, by no means your client - this would 
make server-side mail storage impossible (or stupidly difficult, at 
least)!  And while SMTP could exist for compatibility, I'd like to see 
it die off.

I don't know much about IM2000 yet, but as you I have some thoughts on 
how to better manage mail delivery, and ended up finding IM2000.

Let's consider the situation of my average client, who uses an IMAP 
server.  Ideally, they'd just keep using the IMAP (or similar protocol) 
server, and for compatibility I could even keep an SMTP server on the 
internal interface until all of their clients supported QMTPS or 
something.  Using POP3 is not an option, and receiving any mail not 
delivered to the mail server itself (i.e. fetchmail) is not an option. 
Every message is stored on the mail server, such that it is included in 
a nightly backup, versus their workstation which they probably never 
back up.

Anyways, user logs in, composes a mail, dispatching it to the server for 
delivery by whatever method, and there it remains until the recipient 
picks it up.  Notifications could be sent as you suggested, but these 
should not be visible to the user, rather the mailserver should simply 
recieve them, and decide whether to pick up the mail or tell the remote 
mailserver to delete it without downloading based on any rules you define.

When approved, this mail would be transported from the sending server to 
the recieving, and delivered to his mail folders as qmail does now.

It would be great if there were a maildir folder for the outbox, then 
the user could simply look in his Outbox to see any messages that had 
not yet been delivered.  Instead of Sent, there could be Delivered.

For the power user, I suppose notification decisions could be deferred 
to the user, and await their response before making a decision whether 
or not to pick up the mail.  This would just be too much time and hassle 
for me I think, as I receive a lot of mail.  On the other hand, a single 
approval per mailing list would be all that would be required for 
receiving mailing list posts.

The biggest annoyance now is that E-mail is transferred across the 
internet in plaintext, even if I'm a good responsible admin and make all 
my users use IMAPS and SMTPS+AUTH.  There is no way I can receive mail 
via SSL, nor send to remote servers via SSL unless I'm really clever and 
look up their MX and check for a secure service and deliver directly to 
them.  Ideally the transport method in IM2000 would be flexible, such 
that it could be expanded upon or replaced over time.  It could 
advertise what it supports, and I could choose priority in what I support.

In today's world, this would be equivalent to me send a mail to my qmail 
server, and qmail asking the destination server what it supports.  When 
it replied with SMTPS;QMTP;SMTP, and my qmail supported all of these, 
the mail wolud be retrieved with SMTPS, or by following whatever order 
of priority I have set.  If I set the priority to QMTP;SMTPS;SMTP 
instead, QMTP would be used if the server supported it.  I could even 
disallow insecure communication entirely by removing QMTP and SMTP from 
the priority list.

> Result: the server is listed in the public blacklists, and is not accepted by
> clients that check blacklists.

Public blacklists are taken for granted, but you can not rely on them. 
In some scenarios, communication with them may be impossible, they will 
of course change over time, and it consumes extra bandwidth.

As you accepted or rejected messages, if you did it manually, you could 
form your own blacklists and whitelists.  If this were left up to an 
automated process, you could drop a message that turned out to be spam 
in a spam folder, and the mail server would learn that it should reject 
messages from that account.

But I'm not really sure that's the best way either, and frankly I'm not 
sure what the best way to keep spam from being delivered without relying 
on public servers would be.

I'd be very interested in seeing any design documents or discussion on 
these matters, or IM2000 in general.  How far away is it from being a 
prime time protocol?

-- 
   Casey Allen Shobe  |  http://casey.allen.shobe.info
     [email protected]  |  ICQ: 1494523  |  AIM: SomeLinuxGuy
       Open Source Software Solutions  |  http://osss.net