[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>