[Mageia-dev] [RFC] msec (nail) can't send reports to local users accounts - require an MTA?

[Frank Griffin]

On 09/23/2011 06:49 AM, andre999 wrote:
>
> Currently, entering a userid alone does not work.  It has to be an 
> email address.
> Note however that userid at localhost _is_ an email address.
> We could change it to accept only a valid format email address or a 
> valid userid, in the latter case msec adding the @localhost part.  
> IIRC, @localhost must be in a certain config file, which is the case 
> by default.

If you're referring to the Security panel in Summary, you certainly 
*can* enter a userid.  I regularly enter "root", and then give "root" a 
.forward file to redirect from there.

There seems to be some confusion between the functioning of an MUA and 
MTA.  They function identically, except that the MUA uses SMTP on behalf 
of a single user and the MTA uses it on behalf of many users.  Also, an 
MUA receives mail for its single user by polling an MTA, while an MTA 
typically listens for incoming connections from MUAs or other MTAs and 
receives unsolicited mail for its many users.

Both of them use exactly the same SMTP exchange to hand mail off to an 
intermediate or final-destination MTA, and both of them need to be 
configured with the information necessary to open a socket connection to 
that receiving MTA.

You only need an MTA on the sending system if the recipient is a user 
who uses the sending system as its MTA.  Unfortunately, that includes 
the case of the user-to-user mail on the same system.

So, regardless of what the RPMs require, msec really only needs an MUA 
that is properly configured to hand mail off to the desired MTA, which 
can be on another system entirely.  The requirement for a local MTA only 
arises if you want users on your system to be able to receive mail, 
whether it's sent by msec or anything else.

But in either case, you can't get around having to configure the MUA.  
If you don't, the default config is usually to target an MTA on 
localhost.  And the default config for most MTAs when presented with a 
userid as an address is to rewrite the address to user at localhost and 
deliver it locally.  So yes, if you don't configure the MUA to use an 
off-host MTA, you will need an on-host (localhost) MTA.  If you don't 
have one, the MUA's response is unpredictable; it may throw an error, or 
it may (if it has root access) put the mail  in /dead.letter.


>
> The best solution is to ensure that an MTA is always installed.
>

I'd vote for that for simplicity, provided the default configuration 
made it usable only for local delivery to minimize security implications.

However, I think there is a better solution.  MTAs all simulate the 
sendmail API, and since sendmail is usable as an MUA as well, so are the 
various MTAs.  Real MUAs aren't that uniform.  Virtually all mail reader 
apps use their own internal MUAs to send mail, and have their own 
specific configuration mechanisms, e.g. thunderbird, seamonkey-mail, 
evolution.

In fact:
[root at ftgme2 ftg]# rpm -q --whatrequires mail
no package requires mail
[root at ftgme2 ftg]# rpm -q --whatrequires mailx
msec-0.80.10-2.mga1
[root at ftgme2 ftg]# rpm -q --whatrequires nail
lsb-core-noarch-4.1-9.mga2
[root at ftgme2 ftg]# rpm -q --whatrequires sendmail-command
lsb-core-noarch-4.1-9.mga2
[root at ftgme2 ftg]# rpm -q --whatrequires mail-server
no package requires mail-server

So, it might be a lot cleaner if we just changed msec to do its own 
crippled send-only MUA activities,  This is really a trivial programming 
exercise, as indicated by this comment block from a C program I wrote to 
do exactly this:

************************************************************
       The mail file contains SMTP commands with interspersed message
       data, as follows:
            HELO ...
            MAIL FROM:...
            RCPT TO:...
            (repeats for each recipient)
            DATA
             (mail headers and body)
            .
            QUIT

       We open a session to the remote host's port 25, and ship each
       of the SMTP commands, waiting for an acceptable response.  The
       "acceptable response" to each SMTP command begins with three
       digits and ends with a CRLF.  We examine only the three digits,
       although we record the rest of the text.  The acceptable
       response for most commands is a "250"; for DATA, it is a "354",
       and for QUIT it is a 221.  We do not actually verify the
       responses, since mailservers may vary, but simply forge on
       unless we get an I/O error from the socket.  The user should
       be able to diagnose any errors from the transcript.
***********************************************************

That's if you do it from scratch; I have to think that perl already has 
library support for sending mail.  Of course, you'd probably not want to 
hardcode port 25, and msec would need configuration which could be 
handled by having a disabled entry field for host/port that gets enabled 
if you fill in a mail recipient.

If the host is missing, localhost, or the known host name of the local 
machine, you'd want additional checks that something providing 
mail-server is installed, and prompts to choose one if none is installed.

Same support in msecgui, of course.