Linux

In many implementations, if properly configured, and the local security model allows, a .forward file in your home dir can contain '|command_string', in which case every email coming in gets processed by that command, potentially parallel instances for multiple messages, so be careful what you script.

If this is not acceptable, you have to poll the email file or mail commands, unless you shut down the normal mail server, and your web server also listens on port 25 as smtp/esmtp email server. It could send any unrecognized email to another email server/host to deliver, or file it. SMTP/ESMTP is a pretty easy protocol; just Google for RFC SMTP or RFC ESMTP and find the nice wikis and such. You can also look at raw email messages to see examples of how messages are formatted, in case you want to forward them via email (by tcp connection to port 25 on a different host, as you are now the entire local email service).

Most systems permit the .forward file by default. You should not need "polling" or anything more complex than a single entry in the .forward file.

Just test it and see if it works! It should, if you have it configured properly.

If you do a Google search on SMTP mail and the .forward file, you will see that this is normally enabled, by default.

Just watch out for the security audit! My last Solaris system had it turned off. The .forward wiht pipe is one "non-polled" solution, but to scale up with lower overhead, taking over port 25 saves all the fork and exec overhead. Of course, in the end, the port socket fd will be "polled" by poll or select unless it gets its own thread! It turns out there is often a layer of polling even in interrupt-related mechanisms, sometimes in the kernel! After all, what we call UNIX is mostly what UNIX calls Time-Sharing!

Well, it is a bit premature to discuss 'security audits' when:

One the things that is very important here at The UNIX and Linux Forums is to not make a bunch of assumptions that may or may not apply to others.

In fact, upon review, the OP said:

So all he needs to do it try it by editing the .forward file and trying to forward to another email address.

Technically unacceptable is somehow worse than Politically unacceptable? Many milieu are very security concsious, and more are getting more so every day; many nice features are being turned off, so the wise user includes the local security culture in their tool choice process. Everyone should have at least a virtual seat at the design table: Security, Testing, Admin, Production Support, Configuration Management, Legal, all levels of Users as well as Management and Development.

Of course, if we had better requirements . . . . They say even a very dumb engineer can design and implement from good requirements, but writing good requirements takes a very good engineer.

I have no idea what you are talking about, DGPickett (Sorry). This does not need to turn into a political discussion. The poster asked a very simple question.

Using .forward in a users own directory on a shared server (where they are not a privileged user) is not a giant security hole that is such a high risk.

Let's keep this conversation on track and don't create a bunch of "security requirements" and "risk" that don't exist.



The question has been answered. Time to move on.

I do not set the security requirements, I just design in harmony with them.

Someone hates that .forward pipe, and once it is maligned, managers will start turning it off as part of a comprehensive security audit remediation.

I guess you are in "last word I fixed it" mode, not "ask the user if they are fixed yet" mode. Customer focus is not at political discussion. It is good design.