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@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@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@ftgme2 ftg]# rpm -q --whatrequires mail
no package requires mail
[root@ftgme2 ftg]# rpm -q --whatrequires mailx
msec-0.80.10-2.mga1
[root@ftgme2 ftg]# rpm -q --whatrequires nail
lsb-core-noarch-4.1-9.mga2
[root@ftgme2 ftg]# rpm -q --whatrequires sendmail-command
lsb-core-noarch-4.1-9.mga2
[root@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é
