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

Fri Sep 23 15:32:19 CEST 2011

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.
+
+
+