On Thu, Jan 13, 2005 at 09:55:38AM +0000, Philip Hazel wrote:
> On Wed, 12 Jan 2005, Jamin W. Collins wrote:
>
> > To work around this required an additional router and modification to
> > what section 42.7 suggested. The end result is something like the
> > following:
> >
> > checkforward:
> > debug_print = "R: checkforward for $local_part@$domain"
> > driver = accept
> > check_local_user
> > require_files = $home/.forward$local_part_suffix
> > local_part_suffix = -*
> > local_part_suffix_optional
> > verify_only
> >
> > userforward:
> > debug_print = "R: userforward for $local_part@$domain"
> > driver = redirect
> > check_local_user
> > file = $home/.forward$local_part_suffix
> > local_part_suffix = -*
> > local_part_suffix_optional
> > allow_filter
> > check_ancestor
> > no_verify
> >
> > The first is used solely to check the validity of the address based on
> > the availability of the appropriate .forward file. The second handles
> > only the delivery of the address.
> >
> > I'd be interested to know of anyone getting this to work with address
> > validation without needing the second router.
>
> Let me be sure I have this right: If mail arrives for user-foo, you want
> to accept only if the user has .forward-foo and otherwise reject. Is
> that right?
Yes. I wanted to make sure that the user had a .forward-foo file
available to handle the user-foo@domain address before accepting the
message. Thus allowing them to create their own addresses but also
verify the address should be handlable.
--
Jamin W. Collins
To be nobody but yourself when the whole world is trying it's best night
and day to make you everybody else is to fight the hardest battle any
human being will fight. -- E.E. Cummings
