Hi,
On Mon, Feb 11, 2002 at 03:25:17PM +0000, Philip Hazel wrote:
> > - command = adfdfasf "${if eq {...}{...} {-q ...}{}}"
> > will call 'adfdfasf "-q ..."', not 'adfdfasf -q ...'
> As MBM says, that's exactly as per spec. A quoted string cannot expand
> into more than one argument.
Yes, okay, I just thought it might be bad that there is no other
possibility except for
command = adfdfasf "${if eq {...}{...} {-q}{}}" "${if eq {...}{...} {arg}{}}"
Yet I don't know a solution either :-)
> One reason that you couldn't do this is that a message may have more
> than one recipient. If several of them fail, only ONE bounce message is
> sent. So a single $return_value isn't good enough. If you want to send
> text back in a bounce message, you can try using return_fail_output.
Okay, well, this seems to be reasonable.
I know about return_fail_output and I'm using it now, after modifying
the program I called.
You're right, it is the cleaner way...
> > - Why can't I use ${if ... } for a return_size_limit?
> Because I never thought anybody would want anything other than a hard
> cutoff, since it's supposed just to be a safety catch. Note that that
> option is documented as "integer", and it is not flagged as expanded.
> > I tried these:
> Don't you believe my documentation? :-)
Hehe, no, I just thought I know the error message because some minutes
before I got :
failed to expand message_size_limit in pdeliver transport: invalid
integer "20 k"
^(a space too much)
Okay, "invalid integer" is different from "integer expected" but since I
saw the one after the other I thought that the return_size_limit value
might be expandable to.
But do you get my point about a configurable return_size_limit option?
> > Furthermore it would be nice if return_size_limit could also be set in a
> > transport as message_size_limit does.
> Same problem as above. More than one address may be bounced.
Yes, seems reasonable, too. Well, one could say that the maximum of all
set return_size_limit options is returned if multiple addresses bounce
but it's really a question if the effort is worth it.
> > localpartlist foolist = pgsql; select ... from tblfoo where $local_part = ...;
> WHICH local part? A message may have many recipients. If you use foolist
> in the acl_smtp_rcpt ACL with a local_parts statement, then $local_part
> should be set to the local part of the incoming RCPT address. But
> otherwise it won't be set.
I was talking about the local_parts option in a router. Why shouldn't it
be set when the address is tried to be delivered by that router?
> Which ACL was this? If it was acl_smtp_rcpt, then $domain should be set.
> My test suite includes examples of this. So if you are referring to
> acl_smtp_rcpt, there is some problem that is caused by your precise
> usage, and we need to investigate this further.
I am indeed talking about acl_smtp_rcpt, sorry for that. I'll try again
and give you debug output off the list.
Thanks for all your answers,
Joachim
--
*****PGP key available - send e-mail request***** - ICQ: 37225940
You may be gone tomorrow, but that doesn't mean that you weren't here today.
