-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anton Aylward wrote:
Carlos E. R. said the following on 10/24/2008 08:59 AM:
You have a point in that postfix or sendmail could be replaced with a smaller, local delivery only, smtp agent. However, ¿can you actually sugest such a package? Unless there is one, ready made, available and reliable, or you can convince some developper to develop it, I'm afraid the suggestion is useless.
A quick google shows up
http://msmtp.sourceforge.net/ Which is still too heavy for what we're talking about!
http://aspn.activestate.com/ASPN/CodeDoc/SMTP-Server/Server.html
This is one of those occasions where google can mislead, software hunting with google is probably not the most effective of strategies, and digging into these results does raise a few questions... http://search.cpan.org/~macgyver/SMTP-Server-1.1/Server.pm is one way to find the above reference on CPAN.. However that was last updated in 1999 and is looking unmaintained with a fairly critical bug outstanding and is therefore probably not a good option... BTW Activestate Perl I believe is the windoze Perl interpreter and stuff which works on Windows cannot be guaranteed to run on Linux and vice versa which is why I initially looked at this a little closer. There are some significant differences between running Perl on doze and *nix, while the core language is OK on both, some useful functionality is missing on doze. Suggesting running a script designed to run on Windows seems a little odd....(BTW this module should be cross-platform). http://search.cpan.org/~guimard/Net-Server-Mail-0.17/lib/Net/Server/Mail/SMT... Is probably a better place to start looking..... For Perl CPAN is usually the best first port of call... (and there is rather a lot of SMTP related stuff on the site )... Python probably has a bundle of stuff somewhere (I am not a Python enthusiast, but I would be surprised there was not a similar repository for the language.. )... Of the system script languages Perl and Python are probably the most mature for this kind of work, (with Bash scripting for system glue one has a very powerful toolkit with either or both of these languages). I would tend to view this scripting capability in this context as more of a testing or training tool than a production server or client tool...
This seems to be really intended as a replacement for part of qmail and does not seem to be (completely) standalone or simple..... but there again I know very little about qmail....
I realise perl is not a small footprint but if you are running perl anyway ...
Perl can be quite economic in its footprint (it is really up to the programmer how big this is).... The main issue here would be performance in comparison to compiled code....
The simple loop that is illustrated could be implemented in any number of scripting languages, PHP, Ruby, and isn't mindboggling for C.
PHP hmmm.... stretching a point somewhat... Ruby... not really up to it yet... (these are strongly orientated to web usage and in many ways probably not ideally suited for some system scripting activities). C... why reinvent the wheel?... It is not as if Postfix has a massive footprint, and is particularly difficult to configure or lock down to do this job, (exim and sendmail are a very different story, but exim really addresses a different audience and I get the impression that some people think in terms of exim-like levels of complexity when faced with configuring a SMTP server).... Once you have set up SMTP relay, you have to make certain that the relay is suitably secured so that only those accounts you want to use it can use from the places you say they can use it etc, etc... To gives this capability to a script or other code adds a bit of complexity in any such SMTP server design at the start and some additional processing (and programming and testing work to get right). Postfix is probably as light as you can get without getting something more than a little brain damaged in this context using C (and with utilities such as procmail and spamassassin can be still be very useful even in the local relay only role)....Why make oneself (or others) extra work with little real benefit? Writing a brain damaged script or code for this purpose seems to be just daft! The thing to remember is although the script example is simple as given in the Perl reference, a lot of stuff the module is doing is quite probably not and if you do not really understand what it is doing, one can give oneself (and others) an awful lot of grief.... IMHO this whole issue is a storm in a thimble, and the security issues probably more than a bit overstated (I am a bit of a security freak but I do occasionally find some security related responses as damaging as some of the security issues they are attempting to address and this seems to be one of those occasions).... having a secured local relay on the client is not quite the same thing as having an unsecured or illicit relay which is a frequent issue on M$ workstations that have been botnetted, this is not AFAIK a major linux desktop issue yet. This concern is really a paper tiger.... The Netcat approach in this context is probably safe enough behind a suitable network security configuration used by someone who knows what they are doing, but the thought of letting such a tool loose on some the less knowledgeable elements of userspace for this purpose makes me wince...(and I hope I am correct in believing you are not advocating this...) ... - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkC8VcACgkQasN0sSnLmgKulwCeIX5ZYYWzioCKLt9ogVzMMW8O W0kAoJCQpqgeeGNW5Qe4iYbP7gKEkFPz =eICK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org