From: Tomas K. <to...@us...> - 2008-01-07 05:34:34
|
Cor Bosman wrote: > > Hi, > >> administrators, it is a good solution. If Cor has suggestions about >> things it is lacking, I am glad to hear them. For basic SM setup, > > Wow, never heard of squirrel_logger. > > ... > > So, people outside our organisation generally come to us with message ids > accompanying their complaint. Often they also give us headers, but as I > said, not always. > Message ID can be forged. In order to detect forgery you need all Received: headers. Third party won't detect forgery, because their own Received: header is the first thing that they can trust, message id was already there when they added Received header and they don't know your relay hosts. Without Received headers you can't trace message in your network and can't locate first hop that is no longer trusted. You can trust message id header only when first Received: line is trusted. > In stock SM, if we would look in our smtp server logs > for that message id, it would give us an IP number (and to be honest, I > dont like using the ip# in the message id, as it shouldnt be necessary > so why expose a customer's ip# for something that is not meant to contain > such information). But an IP# is also not enough. It can be a proxy, an > open wifi, a company with dozens or even hundreds of PCs behind NAT, and > so on. Since in our case a lot of webmail logins are from outside our > network, we have absolutely no idea who the sender would be. We'd have > to forward the email to a remote organisation asking them to give us the > info. Very timeconsuming. > SquirrelMail will never know, if address is NAT or Open Wifi. Scripts can barely detect proxies, because normal proxies add own headers to http requests. -- Tomas -- View this message in context: http://www.nabble.com/Re%3A--SM-CVS--SF.net-SVN%3A-squirrelmail%3A--12840--branches-SM-1_4-STABLE-squirrelmail-class--deliver-Deliver.class.php-tp14620259p14659248.html Sent from the squirrelmail-devel mailing list archive at Nabble.com. |