On 9/16/07, Bill McGonigle <[EMAIL PROTECTED]> wrote:
>> So that may not be doing what you want, because it leaves $w
>> set to whatever it used to be set to, and you seem to be implying your
>> system's hostname is somehow bogus for purposes of Sendmail.
>
> Right, in this case Sendmail needs to HELO with a valid hostname to
> get past my spamtrap ...
I figured it might have been something like that. Here's the
potential problem I see: You were setting $j explicitly, and didn't
seem to be setting $w. So any time Sendmail wants the bare hostname
it will still be using whatever your internal hostname was. That's
not likely to expose in RFC-822 headers (which always use FQDNs), but
it still might matter somewhere. So I think you're likely better off
explicitly setting $w.
I believe there is no M4 macro to set the bare hostname itself. You
have to use the Sendmail config file "Dwfoo" syntax. You can, at
least, embed that right in the M4 file. For example:
include(`/usr/share/sendmail-cf/m4/cf.m4')
OSTYPE(`linux')
dnl $w (first word of hostname) is "mail"
Dwmail
dnl $m (parent domain) is "example.net"
Dmexample.net
dnl $j (FQDN) will become (per defaults) "mail.example.net"
MASQUERADE_AS(`example.net')
I do think it would be nice to have M4 macros for this, but they
didn't ask me. :)
More information:
The three Sendmail macros which define Sendmail's identity are:
$w = bare hostname (first Word), e.g., "blackfire" for my PC
$m = parent doMain name, e.g., "bscott.local" for my PC
$j = FQDN of host, e.g., "blackfire.bscott.local" for my PC
They default to:
$w = `hostname -s`
$m = `hostname d`
$j = $w.$m
> ... to make the specific HELO/EHLO case available without overriding the
> FQDN for other cases ... It's a common enough problem with NAT, so
> maybe sendmail has such an option I just didn't find.
I'm not aware of any. Sendmail tends to assume your OS hostname is
the one it should use. If, for whatever reason, that is not the case,
Sendmail assumes you will define the proper hostname inside Sendmail's
configuration, and it will use that for everything. Given that
invalid names tend to cause problems, that's not entirely
unreasonable. However, I could see having specific control over which
names get used for what (HELO, MAIL FROM, "Received", etc.) being
something somebody might want. But Sendmail does not really seem to
support that. Odd, given how it tends to give you options for
everything else. :)
(Well, I suppose you could modify the rules which generate
"Received:" headers, use $j to control HELO, and masquerading to
control MAIL FROM, but that's a kludge at best.)
> Ideally, the masquerading stuff would do this at a certain level
> (masquerade_envelope, perhaps?) ...
Well, masquerading isn't necessarily the same as one's hostname.
For example, say an organization ("example.org") has two mail servers,
"fred.example.org", and "barney.example.org". Those names exist in
public DNS, and people want to be able to tell them apart for
diagnostic purposes (in "Received:" headers, for example). But since
they're mail servers for the whole org, one would still want them to
masquerade as "example.org".
> (aside: not revealing your internal hostnames is probably a worthy goal,
> spam not considered).
I've never been convinced that there's any security exposure in
that. My PC is "blackfire". When my home server was working, it was
"wildfire". My Tivo is called "tivo". My LinkSys router is
"bscott-gw". All with a parent domain of "bscott.local". Now that
you know that, what can you do that you couldn't before? :-)
-- Ben
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
