[CLUE-Tech] If you administer a mail server, you might find this useful.

[David Anselmi]

I would prefer that you trim quotes and reply in line, rather than top 
posting.  But that's me...

William wrote:
> popauth3 does much more than simple POP before SMTP relay
> authentication.  Based on the feedback I am receiving, I should have
> put the details into my original post.

No, your link to your web site was fine.  But your web site wasn't 
terribly clear to me.

> The full detail of what my project offers is very near the top of the
> page:  "What is popauth3?" and immediately follows "Welcome".  Are
> you recommending that I move it even higher?  That flow doesn't seem
> natural to me, but I'd like to hear more of what you recommend.

(Note that because you top posted my suggestion is now lost to this 
reply.)  No, I'm saying that the full detail is not useful.  I read it, 
briefly, I didn't get a clear idea of what your program does. 
Summarize.  Be clear but brief.  E.g.:

I. POP-before-SMTP: permits only authorized users from sending mail
III. Automated null-routing of spam connections based on user defined 
policy (examples of different policy mechanisms)
V. Other miscellaneous logging (such as...)

I took this from the sections of your full details (and left your 
numbers intact).  I dropped II. (Local RBL Cache) because it looked like 
that was just a mechanism for providing III. and IV.  I dropped IV. 
because it seems the same as III., just using postfix SMTP checks rather 
than an external RBL.

Probably that is too short now, but I don't know your program that well.

It might also be good to explain why I. is part of this.  It is for 
stopping outgoing spam where the rest are for incoming spam.  And that 
is one reason I was confused initially--I was thinking POP before SMTP 
but most of the details have nothing to do with that.

I think you mentioned modular, so you might even consider packaging the 
POP before SMTP part separately from your main code.  Have a "framework 
for extending postfix behavior" piece with a "POP before SMTP" piece, a 
"null routing" piece, whatever.  Heh, then you get to figure out 
handling module dependencies.

> The problem with using IMAP is that this requires you teach your 
> users to use it.  My mail server supports many users on several 
> domains, most of whom already know how to set up their MUAs for POP, 
> but have never seen IMAP before.

Perhaps.  But you have to provide directions for those who don't. 
Providing IMAP directions rather than POP shouldn't be a big deal (or 
maybe it is).  Since IMAP works more like "enterprise" mail systems like 
Exchange maybe that works in your favor.  But I can understand if you 
think IMAP is more overhead for you.

> The common sentiment is that IMAP comes across as an alternative to
> POP that requires additional user instruction and support.

Valid, if true.  "Common" does not necessarily mean "accurate".  But I 
won't argue with you until I've been there.

> Also, how many web-mail clients (like Yahoo, MSN, etc) support IMAP
> to retrive e-mail from your "other" accounts?  Not many, if any at
> all.  So, whether I like it or not, I have to support POP, and I'm
> not alone.

Are you saying I can use my Yahoo web interface to retrieve mail from 
any POP account?  If many of your users do that then I see your point. 
OTOH, if they use e.g. mozilla to get their Yahoo mail via POP, it 
shouldn't be a big deal for them to use IMAP for their account with you 
and POP for others.  If this is really an issue, perhaps they (or you on 
their behalf) should think about how to get a more seamless mail system.

> You're right that IMAP seems like a better alternative to POP.  The
> problem is in appeasing the masses of users in such a way that they
> are already familiar with, else you open yourself to more support
> efforts.

I didn't say it was better, just that it avoided the need for POP before 
SMTP.  Sounds like in your case POP is better despite its limitations.

HTH.  Seriously, consider reorganizing your web page.

Dave