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

Fri Sep 23 17:12:59 CEST 2011

Am 23.09.2011 15:32, schrieb 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.
+>
+>
+>
+So, when it comes down to the 4 choices, can i sign you up for number 3?
+dma is a really small MTA, requires no configuration so far and if the
+user installs a full-blown MTA that one is used instead of dma.
+
+Or did you volunteer for the programming work on msec? ;)
+
+
+BTW: The discussion goes on and on, so far i have only 2 conflicting votes.
+We need to at least find a concensus.
+