Bug 76814 - sendmail.mc could use some attention
sendmail.mc could use some attention
Product: Red Hat Linux
Classification: Retired
Component: sendmail (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Florian La Roche
David Lawrence
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2002-10-27 06:09 EST by Andrew E. Mileski
Modified: 2007-03-26 23:58 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-10-27 06:09:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew E. Mileski 2002-10-27 06:09:19 EST
sendmail.mc could use a few more comments, and some organization to make it less
cryptic.  Simply saying RTFM doesn't help when you are specifying something
undocumented (like specific parameters).  Also, there are redundancies and
useless statments that should(?) be removed.


The last line of /etc/mail/sendmail.mc is
which is all fine and dandy, but isn't explained.

The "proper" way to add to the w class is with the more descriptive macro
  dnl Mail sent to the loopback interface's FQDN should be delivered to this machine

Of course this is completely unnecessary since localhost.localdomain is ALSO
defined by default in /etc/mail/local-host-names.  Pick one or the other. You
don't need both.

The there is
again, fine and dandy, but superfluous since they aren't defined by default
anyways.  Perhaps what was meant is
  dnl Remove the "dnl " at the beginning of the respective line if you need these
  dnl define(`UUCP_RELAY')dnl
  dnl define(`BITNET_RELAY')dnl
Though anyone setting up UUCP and BITNET relay (whoa, that brings back memories)
should be able to RTFM.

And since the #1 question asked is, "Why does my mail show up as comming from
user@host.mydomain.com instead of user@mydomain.com?"
  dnl All mail from this host should appear to be sent from mydomain.com
  dnl MASQUERADE_AS(`mydomain.com')dnl
Of course the Mozilla users won't have noticed this.

The first thing I always do is:
  cd /etc/mail
  ln -s ../../usr/share/doc/sendmail/doc/ops/ops.ps .
  ln -s ../../usr/share/doc/sendmail/doc/ops/ops.me .
Though how many people know how to read the *.me?
  nroff -me ../../usr/share/doc/sendmail/doc/ops/ops.me op.man
Even stuffing the *.man in the docs directory whould be enough.

Well, you get the idea by now I hope.  Something to consider for 9.0 :)
Comment 1 Florian La Roche 2002-11-19 02:47:23 EST
local-host-names does not contain "localhost.localdomain", but I have made
all other changes you have proposed above. I'll still have to think about

http://people.redhat.com/laroche/sendmail-8.12.6-3 contains the current rpm...

Hope to hear more feedback from you..., thanks a lot,

Florian La Roche

Comment 2 Andrew E. Mileski 2002-11-19 08:03:57 EST
Thanks for the attention :)

My original note had a few errors, which you've found one.  Specifically, you
are correct about local-host-names; I was thinking of the entries in the access

The manual is actually op.me not ops.me

And as long as you are listening, a pretty good spam fighter is:

dnl DNS based IP address blocking lists

Though Red Hat probably would want to comment (dnl) these out ... just like the
existing feature about allowing mail from unresolvable domains (eliminates at
least 50% of all spam).
Comment 3 Need Real Name 2002-11-20 01:13:21 EST
I really wouldn't recommended putting those block lists in. And FYI, Spamcop bl 
says it shouldn't be used in production and is experimental. Infact I wouldn't 
recommend ANY of those blocklists.
Comment 4 Florian La Roche 2002-11-25 09:58:28 EST
I'll not add this list of spam filters, as they are changing
too fast. This should better be placed on www.sendmail.org or
similar sites, that can adapt to newer recommended sites faster.


Florian La Roche

Note You need to log in before you can comment on or make changes to this bug.