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

[William]

I have taken your recommendations into consideration.  I need some clarification before I can act,
and I have provided some clarification for you.  I will not claim to be perfect, so I would like
to explore this further.

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

> (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 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.

There are two popular ways to approach information dissimination:
1) Short and sweet/brief.
2) Long-winded/verbose.

In releasing a product to an open-source readership, it was my goal to answer a perceived majority
of questions before I opened myself up to the need for an FAQ in reaction to a bombardment of
questions.  There is so much information on this project site that any questions I get should be
for situations I simply haven't encountered -- worthwhile questions.  I have a technical writing
background, so the style I used seemed natural for me; something akin to writing a software
manual.

I also had to impress on seasoned administrators and my peers that this project is worth
considering, if not implementing.  I converse with these people frequently, so I know the
information they will seek on such a page (not to mention my own preference).  Therein lay the
reason for including so much, if not sometimes redundant, information.  Trust me when I say that
it would be passed over if I didn't specifically state that records in the local RBL Cache
automatically expire based on user preference (for example).

> 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...)

Did you see my reply to someone else on this topic where I briefly specified sample scenarios that
popauth3 is designed to handle?  Would that information be useful on the website, above the
overbearing details?

> 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.

The challenge of presenting this project to others as being much more than POP before SMTP is
proving to be more than I expected.
 
> 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.

I did consider this, actually.  That is a good catch on your part.  This idea was rejected when I
was discussing the idea for popauth3 with one of its original authors -- I sought permission to
assume the code for a complete rewrite because it was not yet under the GPL.  His reasoning was
persuasive enough for me to avoid this approach:  (summarized response) "Your version of popauth
is going to have to respond to a potentially very high load of events in the maillog.  It also
handles potentially critical objectives and may be installed on large production servers.  It
needs to be easy to implement and maintain, and have the smallest overhead possible, considering
that it is written in Perl."

> 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 fact is that IMAP is more overhead than POP in many ways.  The specifics are too many to list
in this reply, but just know that IMAP requires much more than just instructing users on its use;
server requirements are much higher than for POP.  It is this offset that bumps IMAP into the
"enterprise" realm.

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

Amongst my peers, it is both common and accurate.  On the other hand, I admit that I represent a
minority even among them, in that I simply haven't decided to support IMAP.  The fact is, many do
and for various reasons.  The most popular reason:  to support web-based e-mail, where IMAP is
required.  If a service supports IMAP, it is very likely that it also has web access to mail, even
if it isn't available outside the local network.

> 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.

Yes, I am saying that you can check POP accounts with Yahoo web mail (and others like Comcast,
MSN, etc.).  However, you need to know that you can *not* POP into your Yahoo mail unless you pay
for Premium service.  Because I provide service to clubs, non-profits, and college students, I can
assure you that my users are most attracted to free and mindlessly easy.  In that respect, I'm
most interested in low TCO, including time spent on user support.  Adding IMAP is more work and
cost all around.

> HTH.  Seriously, consider reorganizing your web page.

I don't understand the recommendation to reorganize.  The logical flow of topics from top to
bottom  would become nonsensical if I shuffled it.  Are you suggesting that I break the page up
into several to offset the wordiness, or something else?

Thank you for your time.  I believe in this project and the approach to spam control that it
represents.  With your feedback, I will be better able to help others in this escalating fight. 
It is important that popauth3 be considered much more than a simple POP before SMTP service when,
in fact, it can be fitted onto IMAP systems quite easily (some versions of popauth2 already
support both POP and IMAP -- a feature I overlook because I have no immediate plans to support
IMAP).


=====
William Kimball, Jr.
"Programming is an art form that fights back!"  =)


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/