Bug 76814

Summary: sendmail.mc could use some attention
Product: [Retired] Red Hat Linux Reporter: Andrew E. Mileski <andrewm>
Component: sendmailAssignee: Florian La Roche <laroche>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: low    
Version: 8.0Keywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-10-27 11:09:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.

Examples:

The last line of /etc/mail/sendmail.mc is
  Cwlocalhost.localdomain
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
  LOCAL_DOMAIN(`localhost.localdomain')dnl

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
  undefine(`UUCP_RELAY')dnl
  undefine(`BITNET_RELAY')dnl
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.com instead of user?"
  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
ops.me...

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

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
FEATURE(`dnsbl',`relays.ordb.org')dnl
FEATURE(`dnsbl',`bl.spamcop.net')dnl
FEATURE(`dnsbl',`sbl.spamhaus.org')dnl
FEATURE(`dnsbl',`spews.relays.osirusoft.com')dnl

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.

greetings,

Florian La Roche