[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rejecting unknown users



On Sun, Nov 09, 2003 at 05:38:02PM -0500, Rik van Riel wrote:
> On Fri, 7 Nov 2003, Damir Horvat wrote:
> > I'm freshmen with zmailer and em annoyed with the fact, that I just
> > can't figure out how to reject mail for unknown users.
> 
> This is a big issue.  I really need to get this up and
> running because with all the forged spam and virusses
> being sent around it is simply irresponsible to accept
> all mail and bounce the nondeliverables...

I see lots of complaints about virus sourcer users in ADSL lines
in my work.  I see also lots of those viruses being sent via
ISP main outgoing email relay defined for the customers.

If/when you bounce things in SMTP protocol, those who send
viruses directly won't see it, nor will the bounce end up in
claimed originator's mailbox.  Those sent via their ISP's
relay will still bounce.   And when you have a backup MX
which has received the message, those will bounce, too.

Besides of system performance demands and router script security
worry, I see no reason not to run interactive router for every
SMTP input.

Over years there have been some thoughts about building more
efficient interactive routing -- as some sort of a server, like
present router master process.    Multiplexing server listening
on a UNIX socket, and running a resource expenditure limited
group of actual routers, like they work now.

To prevent possible local attack into router, the protocol over
the UNIX socket shall be SMTP - or as much alike as usefull, and
not direct access to router shell.

How to manage resource expenditure ?  Somehow limiting the number
of actual processes doing the work.  Also somehow limiting their
lifetimes (they do leak a bit of memory in this operation mode.)

A question I haven't figured out by myself: How contextfull is the 
interactive router ?   Is there any need to use given MAIL FROM
address data, when doing RCPT TO address processing ?
If not, the beast is context free, and resource management is
simple: send job to a free server.  When out of free servers,
start more of them, unless a limit is reached, then just wait.

> Rik

-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi