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

[Florian Hubold]

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.