Alexander Dalloz alexander.dalloz@uni-bielefeld.de writes:
[...]
Is newsguy.com your domain? I ask because of the central and important comment on masquerading from the cf/README:
No, as is explained further along, my `domain' is a home made one: local.net0
"The masquerade name is not normally canonified, so it is important that it be your One True Name, that is, fully qualified and not a CNAME. However, if you use a CNAME, the receiving side may canonify it for you, so don't think you can cheat CNAME mapping this way." (http://www.sendmail.org/m4/masquerading_relaying.html)
This confuses me to no end: First the README shows: `MASQUERADE_AS(`host.domain')' (It shows `host' where first part of domain name should be). As I understand it the naming convention is: host.domain.designator = reader.local.net0 Using my FQDN that would be `reader.net0' rather than `reader.local.com' So I've assumed it really wants `network.domain'.
If one uses ones `One True Name', in this case `1ocal.net0' (I guess it means the last part of my fqdn?) then it is not masquerading as something else. But the paragraph just proceeding the one you quoted says in part:
You can have your host masquerade as another using
MASQUERADE_AS(`host.domain')
This causes mail being sent to be labeled as coming from the indicated host.domain, rather than $j.
But `$j' is my fqdn (reader.local.net0). Clearly the intent is to parade as something you are not. So inserting `local.net0' there would not accomplish that goal it seems.
My assumption was that the `Smart_host' at the other end of my sendmails outgoing activity required a resolvable host as source IP to avoid bouncing. I thought by setting some genericstable vars I could make it appear to be a resolvable host name.
It makes not much sense to offer a smart host which requires a resolvable FQDN. How should people at home with DSL, modem or ISDN connection mail throught their ISP's smart host? It is the task of the ISP's smart host to jump into this gap and offer such linked users the ability to use their own MTA without the risk that many if not most of the recipient MTAs reject mail coming from them, just because they have no resolvable FQDN.
What you say does make sense, and shows a major flaw in my picture of what is happening and how it all works.
Whether the contacting host announces himself with a resolvable FQDN at HELO/EHLO depends from settings of the real hostname, the domain name (if set in sendmail.mc) and from masquerading settings (if are defined). Genericstable does only rewrite the sender envelope address.
Ok, that is more I didn't understand (about genericstable).
It is not an internet FQDN, just my own made up domain for my local lan. Therefore will never be resovable by dns lookups.
Important is that your bogus (internal) FQDN is internally resolvable. Using a
My attempt at using generics tables consisted of adding: (see sendmail2.mc below for the full settings)
FEATURE(`genericstable')dnl FEATURE(`generics_entire_domain')dnl
And to /etc/mail/genericstable: reader reader@newsguy.com
--> GENERICS_DOMAIN(`local.net0')dnl
belongs to the set, else the genericstable feature would not know for which domains to look for rewriting.
OK, I can see how that might help and have even tried it as I recall. You may notice it appears in the posted sendmail1.mc. IE the one that causes bounces.
Building the hash and restarting sendmail.
Maybe my misunderstanding at this point and just to clear out: if you only change map files (the text files from which hashes/.db files are generated) you do not need to restart Sendmail. That is one sense of using these hash files.
If you reread that you'll see I'm describing a chain of events: 1) edit *.mc and generate sendmail.cf 2) build genericstable 3) restart sendmail
It was point 1 that required the restart.
[...]
From /var/log/messages
[...]
Please check what following prints out:
echo "$=M" | /usr/lib/sendmail -bt -d0
Version 8.13.1 Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF STARTTLS TCPWRAPPERS USERDB USE_LDAP_INIT
============ SYSTEM IDENTITY (after readcf) ============ (short domain name) $w = reader (canonical domain name) $j = reader.local.net0 (subdomain name) $m = local.net0 (node name) $k = reader.local.net0 ======================================================== ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address>
echo "$=G" | /usr/lib/sendmail -bt
# echo "$=G" | /usr/lib/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address>
local.net0
The hosts file looks perfect.
OK, I got something right...
===== sendmail1.mc
[ ... ]
FEATURE(`genericstable')dnl FEATURE(`generics_entire_domain')dnl GENERICS_DOMAIN(`local.net0')dnl
[ ... ]
=== sendmail2.mc
[ ... ]
FEATURE(`genericstable')dnl GENERICS_DOMAIN(`local.net0')dnl
[ ... ]
LOCAL_DOMAIN(`localhost.localdomain')dnl MASQUERADE_AS(`newsguy.com')dnl FEATURE(masquerade_envelope)dnl
[ ... ]
There is missing:
MASQUERADE_DOMAIN(`localhost')dnl MASQUERADE_DOMAIN(`localhost.localdomain')dnl MASQUERADE_DOMAIN(`reader.local.net0')dnl
Both commands from above for class{M} and class{G} have to show proper settings.
Maybe, but sendmail2.mc which contains only MASQUERADE_AS(`newsguy.com')dnl FEATURE(masquerade_envelope)dnl (concerning masquerading)
Is the one that works. The other (sendmail1.mc) does not.
So that leaves some questions. But first let me input some further information.
I've now noticed that I can put just about anything in that field MASQUERADE_AS(`whizbang.net')dnl is currently in sendmail.cf and it works ok. I'll send this message that way and there will be no bounce.
So I'm re-evaluating what that actually does. Its not doing what I thought at all but is still doing something. So removing all generics language I'll run a test with the following *.mc. Note it contains two masquerade entries: MASQUERADE_AS(`whizbang.net')# [HP 08/12/04 13:38 Not used since]dnl FEATURE(masquerade_envelope)# [HP 08/12/04 13:38 Not used since]dnl If I remove either one of them my mail bounces immediately.
Sorry to include another full *.mc but it seems the only way to avoid any misunderstanding or confusion about what is or is not present in it. So with all generics stuff removed with this *mc in place my mail goes thru, can you tell me what the masquerade stuff is doing that allows my mail to go thru, as you see it is set to `whizbang.net':
divert(-1)dnl include(`/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID(`setup for Red Hat Linux')dnl OSTYPE(`linux')dnl define(`SMART_HOST',`smtp.newsguy.com') define(`confDEF_USER_ID',``8:12'')dnl define(`confTO_CONNECT', `1m')dnl define(`confTRY_NULL_MX_LIST',true)dnl define(`confDONT_PROBE_INTERFACES',true)dnl define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl define(`ALIAS_FILE', `/etc/aliases')dnl define(`STATUS_FILE', `/var/log/mail/statistics')dnl define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl define(`confAUTH_OPTIONS', `A')dnl define(`confTO_IDENT', `0')dnl FEATURE(`no_default_msa',`dnl')dnl FEATURE(`smrsh',`/usr/sbin/smrsh')dnl FEATURE(`virtusertable')dnl FEATURE(redirect)dnl FEATURE(always_add_domain)dnl FEATURE(use_cw_file)dnl FEATURE(use_ct_file)dnl FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl FEATURE(`blacklist_recipients')dnl FEATURE(`accept_unresolvable_domains')dnl LOCAL_DOMAIN(`localhost.localdomain')dnl MASQUERADE_AS(`whizbang.net')# [HP 08/12/04 13:38 Not used since]dnl FEATURE(masquerade_envelope)# [HP 08/12/04 13:38 Not used since]dnl MAILER(smtp)dnl MAILER(procmail)dnl