Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: SECURITY HOLE: FormMailJukka Ukkonen (ukkonencsc.fi)
Mon, 7 Aug 1995 09:06:21 -0100
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: VaX#n8: "PERL (was: Re: SECURITY HOLE: FormMail)"
- Previous message: Tom: "My email handler, ~ escapes, etc."
- In reply to: Andrew Macpherson: "Re: SECURITY HOLE: FormMail"
- Next in thread: VaX#n8: "PERL (was: Re: SECURITY HOLE: FormMail)"
Quoting Andrew Macpherson: > > Christian Wettergren wrote: > > | I don't know about smail and pp though. The key here is however that > | it is _legitimate_ requests for _features_ that is the problem, not > | any bugs. (I usually phrase this as thought-of "pure" data that is > | actually containing meta-data syntax escapes.) > > I'm not 100% sure about smail. PP will only deliver to programs > which the administrator has configured in 2 different tables --- > > The program *must* be accessed via a label (join key) in both the users' > table, and the shell table, or from the user's mailfilter file. The > user-of-execution is specified in the shell table, or is the owner of the > mailfilter, and altogether one feels fairly happy about pp and program > delivery, because the programs are all under local control. It is impossible > for the submitter to specify a program. .. which is also the case with the modern versions of sendmail. At least 8.6.11 and more recent are clean. Pipes and filenames can be specified only in systems' alias files or in the users' ~/.forward files and naturally only when final delivery is attempted. As far as I know no, such address will work when specified in in-transit messages. > As for sendmail: well we have had bug-of-the-week from that for so long now... > the least one expects is the administrator has installed the checking program > on the program channel. Personally I will not touch it anywhere where > delivery can be effected. Maybe it is wise not to tamper with anything unless one really knows what should and what should not be done. Any MTA that can offer relatively flexible connectivity will necessarily be so darn complicated beast that it is easy to make awful mistakes with the configuration. Cheers, // jau ------ / Jukka A. Ukkonen, FUNET / Centre for Scientific Computing /__ M.Sc. (sw-eng & cs) Tel: (Home) +358-0-578628 / Internet: ukkonencsc.fi (Work) +358-0-4573208 / Internet: jaufunet.fi (Mobile) +358-400-606671 v X.400: c=fi, admd=fumail, no prmd, org=csc, pn=jukka.ukkonen