Re: [9fans] upas aliases

Re: [9fans] upas aliases

[erik quanstrom]

> I don't think there's a software bug here.
> The system is behaving exactly as you configured it to:
> it can expand the alias but not deliver the mail.

i don't think there's a bug either.  i had intended the original
email to be an illustration of what not to do and why.

it is a little bit problematic, however, when smtp ping
believes that successful alias expantion is the same thing
as deliverability.  send does take the edge off by checking
that /mail/box/$boxname exists.

the orginal problem i was looking at was the fact that
smtp ping was succeeding for unwritable mail boxes.
i had thought that removing the write bits would disable
a mail box.

it seems like it would be better if send -x would finish the
job and verifiy deliverability or just expand aliases and
leave the question of deliverability to someone else.

- erik

Re: [9fans] upas aliases

[Russ Cox]

send -x's job is to expand aliases.
it existed long before there was a
deliverability check during smtp.
if you want to expand the deliverability
check during smtp, go ahead.
but don't change what smtp -x means.

russ

Re: [9fans] upas aliases

[erik quanstrom]

> a1: local!a2
> a3: local!a1

the alias were in this form
a1:	local!a2
a2:	local!a3

where a3 was a "real user."  the rewrite rules were standard,
except that the appropriate domain name was subsituted in.
someone had created /mail/box/a2.  this was the confusing bit.

> Local is *not* analogous to builtin in rc.
> Rc's builtin has special meaning to rc.
> Local has no special meaning at all to upas;
> the rules apply to local!a1 the same as they
> do to any other string; there's just a rule that
> handles local!(.*).

isn't that that like saying /fd or /dev have no special
meaning in plan 9? the kernel may not care, but
convention is important.

> Because you switched names halfway through
> you didn't say what was working and what was not.
> In terms of the above two lines, what is it that
> is behaving a different way than you expect?

mail -x a1 -> local!a2
mail a1 -> dead.letter (no /mail/box/a2/mbox)

so it's confusing that mailing a2 works but the a1
does not.  the problem is with my misuse of local in
the aliases, not with upas or the default rules.

although send could check mailboxes a bit more
carefully for deliverability.

- erik

Re: [9fans] upas aliases

[Russ Cox]

> the alias were in this form
> a1:     local!a2
> a2:     local!a3

Okay, let's run with this.

> where a3 was a "real user."  the rewrite rules were standard,
> except that the appropriate domain name was subsituted in.
> someone had created /mail/box/a2.  this was the confusing bit.

> mail -x a1 -> local!a2
> mail a1 -> dead.letter (no /mail/box/a2/mbox)
>
> so it's confusing that mailing a2 works but the a1
> does not.  the problem is with my misuse of local in
> the aliases, not with upas or the default rules.
>
> although send could check mailboxes a bit more
> carefully for deliverability.

I don't think there's a software bug here.
The system is behaving exactly as you configured it to:
it can expand the alias but not deliver the mail.

Russ

[9fans] upas aliases

[erik quanstrom]

i don't know if anyone else has fallen into this
trap, but i don't see it on the archives.  i had
been following along and mindlessly using aliases
like

red.forman:	local!red

this is fine until you slip up and have

oldguy:		local!red.forman

which doesn't work if you're using a somewhat
standard rewrite rule set.  this is because local!
is analogous to "builtin" in rc.  it disables further
alias expansion.  the wierd bit is that mail
somealias will work while a smtp ping, which
uses upas/send -x will not.  that is unless you
create the directory /mail/box/somealias.  it's
all quite peculiar.  and i believe sending to
that alias should always fail.

does anyone think differently?

- erik

Re: [9fans] upas aliases

[Russ Cox]

You switched examples in your mail.
Given an aliases file like

a1: local!a2
a3: local!a1

and a rewrite file like

[^!@.]+			translate	"/bin/upas/aliasmail '&'"
local!(.*)		>>		/mail/box/\1/mbox

I expect an attempt to mail a1 to deliver to /mail/box/a2/mbox
or else fail if that file does not exist.  Similarly,
I expect an attempt to mail a3 to deliver to /mail/box/a1/mbox
or else fail if that file does not exist.
"Attempt to mail" means any attempt at mail.

Local is *not* analogous to builtin in rc.
Rc's builtin has special meaning to rc.
Local has no special meaning at all to upas;
the rules apply to local!a1 the same as they
do to any other string; there's just a rule that
handles local!(.*).

Because you switched names halfway through
you didn't say what was working and what was not.
In terms of the above two lines, what is it that
is behaving a different way than you expect?

Are you sure that your own $mail/aliases
file is not also in play when your run plain "mail"
as opposed to "upas/send -x"?

Russ