OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: POP mail failures
From: Daniel Worin Meredith (dmereditcs.hmc.edu)
Date: Mon Jun 05 2000 - 22:13:05 CDT

I have added some more details to make the issue more clear...

On Mon, 5 Jun 2000, Bennett Todd wrote:

> POP is not a mail sending protocol.
>
> Your email clients are attempting to use SMTP to send email through
> your server to other users who are not on your server; the example
> you provided was a user trying to relay through your user for a
> hotmail.com address.
>
The message was sent via Netscape to the same server that POP is running
on. I wish to configure that server to act as the SMTP server for
my domains.

> There are a few solutions available.
>
> The best one is to have your users configure their email clients to
> use the SMTP server that services their network access. So your user
> was dialing in on 208.235.172.118, which whois claims is a UUNET
> address; presumably UUNET offers SMTP servers for their dialup
> customers.

We bought our IPs from them, so we are not dial-up ;-)

>
> If you want to allow your users to relay through your SMTP server,
> you have a little problem: how do you tell that a given request
> coming in really is from one of your users? Spammers habitually find
> "open relays" --- mail servers that allow relaying from anyone ---
> to send their junkmail. This very quickly gets the offending open
> relay blocked, in databases like MAPS and ORBS, that people use for
> blacklisting sites that aid and abet spammers. You don't want to do
> that.

I want to open the relay to any machine with an IP in my subnets or a
hostname in the domain, but still avoid the spam issue.

>
> So if you want to allow your users to relay through you, when they
> are dialed in via remote sites, you've got a few choices. The
> least repulsive would be to use SMTP AUTH or SASL to authenticate
> the user. Unfortunately, these aren't supported by all email
> clients. So if you have users who can't use those protocols and
> who must be permitted to freely relay through your server while
> they are travelling, your only remaining choice is to install
> something for doing pop-before-smtp authentication. This is a
> repulsive hack wherein you somehow tell the SMTP daemon which users
> (more precisely, which IP addresses) have recently successfully
> logged in via POP or IMAP, to allow relaying from those addresses
> for some grace period (30 minutes seems to work well). There
> are several solutions to that. One of the better-regarded is
> DRAC <URL:http://mail.cc.umanitoba.ca/drac/>. It's a good
> fit if you have a server farm, with multiple machines doing
> pop/imap and/or smtp serving. If you just have one box I've got
> a much lighter-weight solution, which I find works quite well,
> I'll be happy to email it to you or you can download it from
> <URL:http://people.oven.com/bet/pop-before-smtp/>.
>
> -Bennett
>
Thanks for the scripted solution, but ther server will see some heavier
traffic.

Basically I want users with local accounts (all virtual domain accounts
have local machine accounts) to be able to use the server for both POP and
SMTP while at there desk, or at home. I installed the DRAC, the patches
and changed main.cf to include the binary tree of valid ips
(/etc/mail/dracd.db) and the other parameters specified by the DRAC, but
no dice.

It seems the qpopper server is adding authenticated IPs to the dracd.db
file, but even after manually adding a valid IP the authentication fails.

Your patience is appreciated,
~Dan