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

[andre999]

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é