Ok Henry, let me start a new path through all the confusion (I think I
did some mis-expressing meanwhile in both threads about this topic).
Both, masquerade and genericstable, have the same purpose: to rewrite
the sender envelope mail address. Whether masquerading is preferable or
genericstable depends on the specific situation. It is possible to mix
both, from my own testing I see that a genericstable rewriting overrides
masquerade settings.
1) masquerading
You define the @FQDN rewrite address with MASQUERADE_AS(`FQDN') which
will rewrite the mail from the host itself and all in class {M} to have
a header address coming from there. To make sure the envelope address is
properly set too, there is the FEATURE(masquerade_envelope) instruction.
To not only masquerade the single mail host itself but all hosts inside
the net, you can use FEATURE(masquerade_entire_domain).
MASQUERADE_DOMAIN(foo) fill the class{M}.
The masquerading (mail header and envelope) sender address rewriting
takes place as long the sender address (@domain-part) previous to
rewriting is something inside the class {M}. If the sender chooses an
address in his mail client which is different from anything in class {M}
no rewriting is done by masquerading. On the other hand, mail sending
using mail or sendmail (without parameter -f) from the masq host itself
or any masqueraded other will lead to address rewriting.
2) genericstable
The FEATURE(genericstable) is a (hashed) map file with on the LHS (left
hand side) has the user or address which shall be rewritten and on the
RHS (right hand side) the address to which the LHS shall be converted.
class {G} is empty by default and is filled by entries placed into the
plain test file generics-domains. FEATURE(generics_entire_domain) is the
parallel to FEATURE(masquerade_entire_domain).
How it works: if mail is processed and the FEATURE(genericstable) is
active, then the @domain-part is looked up in class {G} whether it is to
be rewritten. If the @domain-part is part of class {G} then the
genericstable map file is taken and searched for a matching LHS part. If
none found nothing happens, if an entry found the address is rewritten
with the content of the RHS.
3) When address rewriting is needed
When you run your own Sendmail and you have no public resolvable FQDN
for that mail host, assigned the FQDN to your IP address using an DNS
record, you need address rewriting for those cases where the origin mail
address will be the private, non resolvable domain address. Examples for
this are notification mails sent out by cronjobs or "hand made" mail
using the "mail" command. Mail clients setting the envelope sender
address correctly, you do not need masquerading or genericstable
rewriting.
Using the smart host of your ISP or from any other service does not heal
this situation. Though it is recommended to use such a smart host from
dial-in homed connections because otherwise your Sendmail (fits for
other MTAs as well) will directly deliver to the recipient's MTA, and
meanwhile many of those do not accept incoming connections by dial-up
IPs (because of need for anti SPAM fighting).
The smart host does not rewrite the sender address, but it should reject
attempts to relay, when he (the smart host) acknowledges a public
non-existent domain part in the sender's mail address.
4) example setup
Given your Sendmail host name is satyr.local.net0 and you send mail
through it, either locally or from a host in the same private net (IP,
name does not need to be the same) using your Sendmail for sending, and
you do not use a mail client which sets a proper (proper because public
existing and deliverable) mail address, then you need address rewriting
either with masquerading or genericstable.
Let us take the masquerading setup.
MASQUERADE_AS(`newsguy.com')dnl
FEATURE(masquerade_envelope)dnl
This is what you did use. If newsguy.com is your controlled domain, it
is not big problem, because you can create valid email addresses for
that domain for each sender you use through your Sendmail. It is then a
problem, if you for example have only 1 email address like
hputnam@xxxxxxxxxxx but no other. Why? Well, imagine the case mail is
sent out by a root's cronjob. You know how it is rewritten? Yes, to
root@xxxxxxxxxxxx Where does a reply could go? Right, not to the sender.
Same is valid for all other cases where the mail is not initiated by
your local user with name hputnam.
In your last mail you wrote you used (at least tested with)
MASQUERADE_AS(`whizbang.net')
address rewriting and that it succeeded when sending through your ISP's
smart host. It of course worked, rather than sending with an address of
@satyr.local.net0, because whizbang.net is a public resolvable thus
valid domain name (does not matter whether a mail server runs for it).
So the smart host verifies it is existing and accepts it for relaying.
Of course your mail sent out has now the sender address
hputnam@xxxxxxxxxxxx what you hardly want. If you would use for the
MASQUERADE_AS name `whozbang.net' your ISP's smart host would reject the
relay attempt.
Address rewriting using genericstable would work similar in your case,
you only have to respect the differences. Especially the differences may
lead to the decision to give genericstable the preference over
masquerading, because when using masquerading you won't get an error
when sending with a non existing email address while rewriting to
`newsguy.com' (not your domain as you said before) for example. With
genericstable you have to define positive cases, where a rewriting has
to take place. And in each case not rewrite target is found you or a
script sending out with a non rewritten mail address will cause an error
immediately.
I really hope my explanations do not cause a lot more confusion and
questions :) But feel free to ask.
Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 18:58:51 up 12 days, 12:26, load average: 0.35, 0.47, 0.45
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
