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

Sun Sep 25 21:36:07 CEST 2011

Frank Griffin a écrit :
+> 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.
+
+You're right.  I just tested it and it works now.
+When I first installed postfix (on mdv2010.0 or earlier), it didn't work 
+until I added @localhost to my userid.  It was probably a config 
+problem, which was solved with subsequent updates.
+
+> 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.
+
+So in sum, you seem to be saying that an MUA needs an MTA, which may be 
+on a remote machine.  Except if it is to be delivered locally without 
+accessing a remote machine, the MTA (of course) has to be on the local 
+machine.
+
+>> 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.
+
+That makes sense.
+
+> 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.
+
+I like that approach.
+There are a lot of mail-related perl packages.  Hopefully one is 
+appropriate (or readily modified to be so).
+
+We should also have code that gracefully deals with cases where it is 
+requested to send security messages to a remote host.  (For example, if 
+a remote-capable MTA is not installed or accessible.)
+
+-- 
+André
+
+