On Fri, Jun 17, 2005 at 10:33:02AM -0500, Zachary Kotlarek wrote: > Bruno Negrão wrote: > >Hi Krico, > > > >>A malicious user could send an e-mail to the outter world by setting > >>up an autoreply (mailReplyText+deliveryMode) and then forging an > >>e-mail from someone to himself. > > > >I didn't understand this exploit. Can you explain it better? > > > >But even with this condition, I think it's worth to implement this > >feature. It will be effective for 99,9999999999...% of the cases. > > > >The guys with the knowledge you're suggesting are root of the > >mailservers, not the ordinary users. > > I agree that it would be mostly effective. Administrators could also > simply disable replies, or direct access to the mailReplyText attribute, > if they wanted to close the hole. >
This discussion about a way to exploit a "no you are not allowed to send mail out of out comapany" problem is just stupid. Come on if I want to send a mail out of your comapany and you give me access to the internet I can do it without porblems. Blocking mail service has nothing to do with security. It is more a political thing. > On the other hand, I think it's a bad idea to implement a security-type > feature that doesn't really work. However well documented the behavior > might be, it's still an obscure hole in a system designed to limit access. > There is a reason why TLS & SMTP-AUTH exists. > I'd love to see qmail-queue get an ENV variable with the authenticated > SMTP username. Likewise qmail-reply/qmail-local/etc. could provide the > same variable back to qmail-queue when they send messages. That would > allow qmail-queue to provide this sort of filter without too much work > -- qmail-queue already knows about local vs. remote domains, and if it > knew my username it could look up other attributes. > Wrong. qmail-queue knows nothing. It is a dumb spooler app. -- :wq Claudio