Re: IM2000 Won't Be Worth It

Jon Ribbens <[email protected]> writes:

> Ian Lance Taylor <[email protected]> wrote:
> > I think the main argument is eliminating bounce messages and
> > simplifying mailing lists.
> 
> The no-subscription model of mailing lists is certainly interesting.
> But what does it achieve that cannot be achieved via NNTP today?

Not much, I suppose.  NNTP today is a pain because it's hard to unify
NNTP and SMTP.  An e-mail sent to me and also to the gcc mailing list
should arrive in my inbox once, and be read in the same way.  Also
when I see a message on the gcc list I also need to see the complete
To and Cc lines, which NNTP currently drops.  However, I agree that
the significant problems can in principle be solved entirely at the
client level.  GNUS accomplishes it to some extent.

> Also, how do "subscribers" know when there is new mail to be fetched?
> Currently, if I am on a mailing list I know about new messages
> essentially immediately. It's not very efficient to have every
> "subscriber" contacting the message store every 5 seconds to see if
> there is new mail!

I agree.  Fortunately most subscribers are more patient.  I run a POP
server for a number of people, and most people seem satisfied to check
for new e-mail--from anyone, not just a particular list--at most every
five minutes, rather than every five seconds.  In particular, most
people would not feel the need to check the message store when they
are not online.  Naturally checking the message store could be very
light-weight--UDP rather than TCP (although I don't think NNTP
supports that today).  And IP based rate limiting is easy to implement
on the server side anyhow, and good enough to address this issue.

> > Bounce messages are bad because they are widely mishandled today, and
> > there is no realistic prospect for improvement.  Today there is no
> > good way to know whether somebody received an e-mail message, short of
> > telephoning them.  IM2000 raises the possibility of solving that
> > problem (you still won't know whether the message was read, but you
> > will know that it was received).
> 
> What does it achieve that Return-Receipt-To does not already achieve,
> or that could not be achieved by a simple protocol to allow MUAs to
> inspect their SMTP smarthost's outgoing mail queue? 

Return-Receipt-To is heavy weight, not widely implemented, and doesn't
do what you want.  You don't want to know when the SMTP server
received the e-mail.  You want to know when the message was downloaded
via POP or IMAP.

> Is it actually
> useful to know that a message has been received but not necessarily
> read?

Yes.  You know that the recipient is online and reading e-mail.

> > Large mailing lists are bad because they have a lot of churn in
> > recipients, and thanks to the problems with bounce messages you wind
> > up sending many messages to recipients who no longer exist.
> 
> What does IM2000 achieve here that VERP together with good mailing
> list management software does not already achieve? What does it
> achieve that minor improvements to MUAs and mailing list managers
> could not achieve?

There is no realistic hope that MUAs will improve to the point that
bounce messages work correctly.  Not to mention the various different
programs which live in between the MTA and the MUA, like virus
scanners.  Yes, in principle, they can all implement bounce messages
correctly and usefully.  But they don't.  IM2000 has the advantage
that everybody has to implement it correctly, because there is nothing
to implement.

> > I'm one of the group who manages sources.redhat.com, which hosts the
> > gcc and cygwin development mailing lists, and IM2000 would eliminate
> > a number of the things we have to deal with regularly.
> 
> Can you give examples of the sorts of things you have to deal with
> regularly? I administrate a few (small) mailing lists and the main
> problem I have to deal with is spam. I use postfix and mailman
> personally, I see you use qmail and ezmlm.

One example is badly configured MUA/MTA/virus checkers which send
bounce messages back to the person who sent the e-mail message to the
list, rather than sending it to the list bounce address.  We then have
to work out which e-mail address generated the bogus bounce--not
necessarily a trivial exercise--and remove that e-mail address from
the lists.

Another example is systems which impose rate limitations on incoming
SMTP as a spam-avoidance measure.  The gcc and cygwin mailing lists in
particular generate enough legitimate e-mail to trip those rate
limits.  There are gcc and cygwin developers who work for large
companies or academic institutions and have no control over overall
e-mail policy.  As a project which depends upon volunteers, we can't
reasonably cut those people off because of admin problems.  This
usually leads to complex negotations in which we try to prove to some
sysadmin who has never heard of us that we aren't spam generators, and
convince them to cut a hole in the rate limitor for us.  In some cases
I have wound up giving people a POP account on my personal server so
that they can avoid the problems with their usual e-mail system.

This is not to say that these are our main problems--spam blocking
does consume more time, although through a number of very aggressive
efforts the system is ticking over pretty well at the moment (actually
our main spam problem these days is legitimate people landing on the
blacklist, because somebody forged spam from their e-mail address).
But these problems generally arise a few times per month, and IM2000
could help.

Ian