----- Original Message -----
From: "Ken Hohhof" <[EMAIL PROTECTED]>
To: "Subscribers of Qpopper" <[EMAIL PROTECTED]>
Sent: Thursday, February 06, 2003 9:49 AM
Subject: Re: Relaying Denied
> I think you guys are too hard on pop-before-smtp. Granted it is a kludge
> and should be avoided it you can. But we have used it for several years
> with no problems except that a couple times the daemon stopped for no
> apparent reason and had to be manually restarted.
Ignoring the fact that SMTP AUTH is a fairly all-in-one solution that
doesn't require interaction between two completely unrelated daemons. As
was said earlier, the POP-before-SMTP approach is largely confusing to many
customers. SMTP AUTH is, with more recent MUAs, extremely easy to configure
and use. (Even my Amiga's mail client does SMTP AUTH ;)
> If you primarily provide Internet connectivity as we do, the best policy
is
> to only relay for clients on your network. If a few customers connect
> through another ISP, tell them to use their ISP's outgoing mailserver,
this
> is the standard solution. If they have a T1 or a premium DSL with static
> IP, then we will enter their IP in our relaying database. If they're too
> cheap to spring for a static IP on their DSL, or they are using another
> ISP's dialup and are too inept to enter that ISP's outgoing mailserver,
> tough luck. Or they can use our WebMail server, that's another solution.
I can see how this would normally play out, but the problem exists that many
clients who are savvy enough to get some kind of Static DSL or T1 service
haven't a clue of how to do anything else. It saves administrative time and
customer confusion to tell them to use your SMTP AUTH servers, especially if
you're hosting the client's domains.
One solution we tried was to alias smtp.clientdomain.com to the client's
SMTP servers. But that just increased the frustration level when the
customer ISP's mailserver was down or unreachable, and we suddenly became at
fault. What it boiled down to for us was "if you want it done right, you
have to do it yourself."
> If you are a private company, and you have remote/mobile/SOHO clients,
> things are less clear. My preference would still be to use the ISP's
> outgoing mailserver. But you may have a policy that all sent mail goes
> through your server, maybe so you can log it or screen it for viruses
and/or
> content. Also you probably have more control over the email clients that
> your employees use and you probably set it up for them. In this case you
> may want to use SMTP AUTH or even non-standard mail like Exchange mail.
Not always a matter of policy. With the dwindling number of national ISPs
available these days the support all of the features a business needs (last
year we had issues with AOL disconnecting dialup users immediate after
initiating a VPN session,) it's difficult to be able to move from one area
to the next without haveing to update settings. With SMTP AUTH, anyone
travelling for a corporation can use any ISP's connection, including those
at hotels, to send their email.
> We don't like SMTP AUTH because it is not practical to make all our
> customers use it just to accomodate the few who need it. And if we enable
> it on our server, we have problems with our many Mac users with Netscape
4.x
> clients which seem to choke if the server offers AUTH but the client is
not
> set up for it.
Then don't make them all use it; it's not an all-or-nothing option. We have
SMTP AUTH enabled on our servers, and it happily relays mail for anyone on
our network without authenticate, and requires anyone outside to use
authentication. I was pleasantly surprised at how 100% of the people who
are using SMTP AUTH only needed a brief explanation of how to configure it,
which we provided on a website.
Now, the bit about Mac Netscape 4.x clients... does this happen in an
environment which requires SMTP AUTH all around, or only offers it but still
provides local relay? I know from experience that the 4.6 and 4.7 clients
were awfully flakey about SMTP AUTH, but v4.8 seems to have fixed this
issue, and most people have migrated to 6.x or 7.x. I did some checking,
and it seems that the minimum indicated requirements for Netsccape 6 is OSX,
but Netscape 7 will go back to PowerPC-based units running OS8 or better.
> Again, WebMail is an alternative. We use EmuMail which is basically a
> web-based POP3 client, we actually run it on the same server as qpopper
but
> it can just as easily (and probably better) be on a separate server.
Web-based email is always a great alternative if you have a good package to
run. I've spent the last year or so trying out various PHP-based POP3 and
IMAP clients. Initially I opted for clients that didn't require the IMAP
library and MySQL or LDAP for user prefs, but finally have settled on using
the Horde framework with IMP.
--
Alan W. Rateliff, II : RATELIFF.NET
Independent Technology Consultant : [EMAIL PROTECTED]
(Office) 850/350-0260 : (Mobile) 850/559-0100
-------------------------------------------------------------
[System Administration][IT Consulting][Computer Sales/Repair]
