On Thu, 12 Oct 2000, Steve Platt wrote:
> We have (historically always had) aliases for each of our users a bit like
> this :-
>
> full.name: username
> username: username@mailhost
<snip>
> Now, I only just noticed that this has the effect of leaving the first alias
> as valid for the verification in our system_aliases director, so that SPAM
> sent to the second (:fail:) address does get refused but stuff sent to the
> first address (that we didn't change) gets accepted and generates a
> mailer-daemon error reply.
This is a problem area. I decided that verifying at SMTP time should
just verify the first level, because if, say, this was the name of a
mailing list with 1000 members, you don't want to verify the lot of them
before accepting the incoming address.
The problem (and this is not the only place when this arises) is that
there is, at present, no means of distinguishing between an alias (or
forward file) which is just a re-addressing, from one that is in effect
a mailing list.
You *could*, I suppose, argue that if there's only one new address it's
special, and the generated address should be verified. This would help
in your case and similar ones.
> Also, I notice that "exim -bv full.name" verifies but "exim -v -bv full.name"
> does not verify - as per the words in TFM - just like "exim -bt full.name"
> fails.
Yes, the -v forces it to verify generated addresses too.
> I guess I could just remove the first alias (turn it into a comment perhaps)
> or replace it with another :fail: - or is there some option to the director
> that would make verifying more like an attempted delivery?
Having an option on the director that said "if verifying, continue with
the generated addresses" would be possible, I think.
I'll look into this some more. Doing something automatically for single
addresses is attractive because then it happens without the admin having
to remember to set anything.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
