Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 76814 - sendmail.mc could use some attention
Summary: sendmail.mc could use some attention
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sendmail
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Florian La Roche
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-27 11:09 UTC by Andrew E. Mileski
Modified: 2007-03-27 03:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2002-10-27 11:09:26 UTC

Attachments (Terms of Use)

Description Andrew E. Mileski 2002-10-27 11:09:19 UTC
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 07:47:23 UTC
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 13:03:57 UTC
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 06:13:21 UTC
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 14:58:28 UTC
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.