On Thu, 2004-04-22 at 09:28, Alain Knaff wrote:
That being said, I see a different issue with these per-user
whitelists:
In some MTAs, such as sendmail, it is surprisingly difficult to find
out the final recipient at the early stage of mail submission at which
the milter is invoked. The rcpt_to callback passes the user name as
submitted by the previous MTA, without any alias or virtusertable
expansion.
Argh! I had completely forgotten about that.
(But I think/hope it's still a solvable problem.)
So, either the milter would need to do this itself (with the risk of
accidentally getting the alias/virtuser expansion algorithm slightly
different than sendmail itself), or we would need to instruct the
users to only forward to his login(_at_)mydomain(_dot_)com address, and never
to
FirstName(_dot_)Lastname(_at_)mydomain(_dot_)com or
FirstName(_at_)myvanitydomain(_dot_)com
Perhaps something like the former method is doable, but instead having
the milter lookup incoming RCPT TO:'s in an existing table made just for
this purpose. Would something like the following work?
Given the virtusertable.db table and the aliases.db table, we could
construct a tool that could make a table, say "virtuseragents.db". of:
(incoming recipients) versus (corresponding responsible users)
for
all incoming recipient names listed in aliases or virtusertable
in which
there exists a single responsible username.
Any tool which could create the virtuseragents.db table as above would
naturally be able to recognize the cases in which there was no
identifiable single responsible user for an incoming recipient name.
Given that admins should know the responsible parties for any particular
virtual user or alias, they could edit a "virtuseragents.txt" table to
account for the remaining cases.
So there could be a makefile allowing a "make virtuseragents" that:
1. Creates a virtuseragents.db
1. First including recipients from virtusertable.db and
aliases.db
o for recipients in which the recipient's agents that
can be automatically determined
o while creating a temp file "unknown_agents", consisting
of recipients whose agents can't be automatically
determined
2. Then adding recipients vs. users from every line in
virtuseragents.txt where the recipients are listed
in temp file unknown_agents
3. Then adding recipients vs. NULL for every line in
unknown_agents that doesn't have a corresponding
entry in virtuseragents.txt.
2. Generates a virtuseragents.err file mentioning
1. Every line in (an over-specified) virtuseragents.txt,
where the recipient isn't in unknown_agents.
2. Every line in unknown_agents where there is no recipient
in (under-specified) virtuseragents.txt.
When an admin runs "make virtuseragents", they'll see what lines in
virtuseragents.txt they'd need to edit. (I'm not so worried about the
case of them not knowing who the responsible party for any alias
is--they had better know that if they're an email admin!)
From the point of view of a tool determining the trusted-forwarder list
to go to for any particular recipient, the tool could search the
virtuseragents.db and:
o If a non-NULL entry is found specifying a responsible agent,
use that agent's ~/.trusted_forwarders file.
o If a NULL entry is found, either:
o Use a settable-default value for the responsible agent,
going to his ~/.trusted_forwarders file, or
o Don't accept any forwards if there is no default agent
set.
o If there is no entry at all, go to that users
~/.trusted_forwarders file
o If there is no user of that name, well, I think at this
point you could pass things through and sendmail will
eventually reject things. (I don't know if you'd want
to go ahead and reject at this point or not.)
Could something like this be a solution to that concern, do you think?
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com