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@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@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@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.
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.