[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EXPN return codes still broken
On Thu, Nov 04, 1999 at 10:04:45PM +0300, Eugene Crosser wrote:
> On 04-Nov-99 at 21:13, Matti Aarnio (mea@nic.funet.fi) wrote:
> > You don't recall recent talk that 'make install' does not
> > overwrite router .cf script files ?
> >
> > Manually: cp -p proto/cf/*.cf $MAILSHARE/cf/
>
> Oops.
> Now the results are consistent but still incorrect:
Ok, not nice. Have a look at quadprint() funtion at server.cf.
> 250 chronos.sovam.com Hello ariel
> expn crosser@chronos.sovam.com
> 250 Eugene Crosser <crosser>
> expn xxxx@chronos.sovam.com
> 550 no such user: <xxxx>
> expn test-list@chronos.sovam.com
> 550 no such user: <"|exec /usr/local/list/.bin/flist test-list">
> ^^^^^^^^^^^
A pseudo-diff of the part:
....
user="$(user $quad)"
case $(channel $quad) in
- local) ssift "$user" in
+ local) ssift "$(dequote "$user")" in
[|/].* text="250 local delivery for"
break
;;
.*
....
> expn test-list-dist@chronos.sovam.com
> 550 no such user: <":include:/usr/local/list/test-list/dist">
> ^^^^^^^^^^^
Hmm... as if aliases.cf doesn't properly proceed over that
':include:'-tag to actual recipient addresses..
> vrfy crosser@chronos.sovam.com
> 250 Eugene Crosser <crosser>
> vrfy xxxx@chronos.sovam.com
> 550 no such user: <xxxx>
> vrfy test-list@chronos.sovam.com
> 550 no such user: <test-list>
> ^^^^^^^^^^^
> vrfy test-list-dist@chronos.sovam.com
> 550 no such user: <test-list-dist>
> ^^^^^^^^^^^
At aliases.cf there is a test about 'type' variable having value
'expandsender' which stops 'EXPN' processing at some point.
VRFY stops way more earlier in the local part (also in aliases.cf).
> I am using VRFY when creating a new customer ID to check if the new name
> matches some exisiting alias ot mailing list. In that case, the user
> should not be created. With the current behavior, there is no way to
> check if a specific mailing address exists. (Other question is that
> VRFY may be used to obtain list of valid users on a system; it would
> be good if access to the command could be restricted by IP address or
> whatever...)
Err... I would much rather use the backend databases directly at
the customer id generation -- router does interrogate the same
place (at least in my environment - in sort of LDAP wrapper), so
why to use VRFY ?
Our current way to controlling who can do EXPN or VRFY is by what they
give to EHLO (or HELO) as a parameter. The 'e' and 'v' letters at
the lines at the end of the smtpserver.conf file.
So it is a sort of 'give magic word, and you get EXPN and VRFY' type
of access control. Not so great, but better than nothing..
> RFC821 is not very restrictive about when 550 should be returned
> (and 550 is explicitly valid for VRFY on a mailing list) but EXPN is
> implicitly assumed to return positive result on a mailing list:
>
> "For the EXPN command, the string identifies a mailing
> list, and the multiline response may include the full name of the
> users and must give the mailboxes on the mailing list."
>
> "list of mailboxes" needs to be omitted these days for obvious reason
> but common sense tells (at least to me:) that respnse to EXPN should be
> positive if the address expands to anything presumably deliverable -
> pipe, mailing list, etc.
>
> Eugene
--
/Matti Aarnio <mea@nic.funet.fi>