On 26 May 2001, Ed Robitaille wrote:
> Any and all help appreciated. Or a any suggestiions about something
> easier than sendmail. (2 cans & string !?)

  I recommend the use of a fully independent mail client, such as Netscape
Mail, KMail, or any other similar program.  Such programs do not rely on the
local system at all.  Instead, they communicate directly with your ISP's mail
servers.  This is the model your ISP expects, and the one most suited for
someone with a transient, attended, dynamic dial-up account.

  The reason this is better is that it offloads the work to your ISP.  If you
persist in using system integrated mail programs, you need to configure your
system as a fully-working mail host.  *This is hard to do.*  You will have to
spend a lot of effort, and likely experience some pain.  I (and likely others
here) am perfectly willing to help you out, but I suspect it is really not
what you want to do, and just give you the impression that "Linux is hard to
use".  That is not a belief I wish to perpetuate.

  If, on the other hand, you *do* want to go through with it all, whether
because you want to learn, you're a stubborn bastard like me, or your own
reasons entirely, than read on.  :-)

> I would like then use mutt as my mua ( correct buzzword ??)

  mutt is a Mail User Agent, yes.  :-)

  MUA = Mail User Agent, a program to read and originate messages.  Most
things people consider to be "mail programs" are MUAs.

  MTA = Mail Transport Agent, a program which moves messages from one location
to another.  Sendmail and Fetchmail are popular examples.  A great many "mail
programs" are also MTAs -- Microsoft Outlook, Netscape Communicator, and
Eudora Mail, for example, all include POP clients, which are a form of (very
limited) MTA.

  These distinctions are important, because the tricky part is getting the
mail from one place to another (MTA).  Reading it is easy.  Sometimes the
choice of "mail program" is important, and sometimes it is irrelevant.  It
depends on what MTA features said program might include, and what the
situation requires.

> I used send mail as my mta.

  I've said it before and I'll say it again: Sendmail is not well-suited for
the home user with a dynamic IP dialup account.  The M4 configuration
mechanism Sendmail uses assumes you have a well-connected system, present in
the DNS.  You can make it work, but it will be painful.

  I notice the normally vocal crowd of people advocating other MTAs is silent
on this issue.  Is there no such thing as a Unix compatible MTA which works
well for this scenario?

> I am using ximaian evolution for for writing this e-mail I DO NOT
> recommend it .

  Evolution is still a work in progress.  As such, it is not guaranteed to
be useful, or even run.  :-)

> I have 2 problems 
>     1. I cannot get sendmail to run. I am using config.mc:
>         FEATURE(`nullclient',`mail.eagle1sr.com')

  The nullclient feature is *NOT* what you want to use.  A Sendmail null
client is designed to basically be a "remote extension" of a central site mail
host.  All mail is delivered through that central host.  A bare minimum of
local processing is done.  No local delivery is possible.  The local machine's
identity is obliterated.  Most other Sendmail features are disabled.

  Remove any "nullclient" references completely.

>         FEATURE(`nocanonify')

  Turn this off, too.  nocanonify is designed for situations where any host
or domain names are guaranteed to be cannonified already (not the case), and
where canonicalization is not possible or would produce incorrect results.

>         MASQUERADE_AS(`eagle1st.com')
>         FEATURE(`masquerade_envelope')
>         define(`SMART_HOST',`mail.eagle1st.com')
>         FEATURE(`accept_unresolvable_domains')

  Note that all four of the above are fundamentally incompatible with the
"nullclient" feature, so even if you *were* a valid null client (which you are
not), your config is broken.  Nix the nocanonify and nullclient features, and
these make more sense.  However, you need to understand what they are doing.

  When you masquerade as a domain, you tell Sendmail to pretend to *be* that
mail domain.  Any mail coming from your system will claim to have come from
<[EMAIL PROTECTED]>, where <somebody> is whatever local account sent the
message.  If your login name is the same as your ISP account at
<eagle1st.com>, this makes sense.  But if, e.g., you send mail as root to a
non-local address, it will look like it came from <[EMAIL PROTECTED]>.  If
anyone replies to that message, you will not receive it.  You also run the
risk of incurring the wrath of any admin at <eagle1st.com> if you accidentally
impersonate someone else.

  So why would you, personally, want to masquerade as <eagle1st.com>?  
Because it is required if your MUA uses the Unix /usr/sbin/sendmail interface
to send mail.  Mail sent via that method is processed by your system MTA,
which is currently Sendmail.  Sendmail will send that message on to where ever
it is going, and you want your From: address to be valid.  I believe Mutt uses
/usr/sbin/sendmail, so you need to do this.  (I do not use Mutt myself; anyone
here who does and can say better, please speak up.)

  Many mail programs have built-in functionality which can send mail directly
to an SMTP listener.  (This is the usual method in the MS-Windows world,
where the OS has no standard mail API, like Unix does.)  In that case, you
simply configure your mail program to send mail via your ISP's SMTP relay, and
all is well.  See above about a fully independent mail program.

  The other three configuration lines are easier to explain.  Masquerading the
envelope just means the SMTP "FROM" command also uses your masquerade entry.  
For a case like yours, where your system host name is doubtless not in the
DNS, you need this.  The "SMART_HOST" definition tells Sendmail to forward all
non-local mail to the specified host.  Your ISP's mail server can do a better
job of sending mail than your system can, so this is also good.  Lastly, you
tell Sendmail to accept unresolvable domains, because on a dial-up system such
as yours, DNS will not always be available to resolve domains.

>  2. When I run fetchmail, my mail is parsed into the different folder s of
> my spool directory '/var/spool/mail/*folder'.

  This is also broken.  /var/spool/mail/ is where the *system* delivers mail
to user accounts.  Users *SHOULD NOT* keep their own mail boxes in that
directory.  Use a directory in your home directory (I believe mutt uses
$HOME/Mail/) for this purpose instead.

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |


**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************

Reply via email to