Aidas Kasparas wrote: > > Gordon Messmer wrote: >> Sam Varshavchik wrote: >>> You can't. Alias lookup happens immediately upon the receipt of the >>> recipient's address. Since the alias address is no longer needed, it >>> does not get stored anywhere. >> >> It does get stored in the control file, doesn't it? Courierfilters have >> access to that information and can log it, AFAIK. It should be trivial >> to write a pythonfilter that logs that information if users want it. > > Count me to the "users want it" part.
Gordon used to maintain a "pretty-received" patch to do exactly that. Alas, it never made it to an official version. However, the fact that he himself did not implement a pythonfilter as he said is meaningful! > Why? Because at the moment I don't know how to grep from the logs info > about all the messages to some particular alias. And, if problem with > some alias is reported, the only way to check it is sending test messages. Yup, aliases don't work that way. In facts, it is only safe to log the recipient in the message's header when there is a single recipient. Otherwise it betrays possible Bcc's. The general solution to tracing back the original recipient address is to do it upon delivery, I mean .courier or .mailfilter stuff, rather than upon receiving. In that case you get Delivered-To and Received headers for each hop, besides being able to redirect the stuff to different folders. It is ideal for "spam finger" addresses, e.g. [EMAIL PROTECTED], that people may forge at need. I've learned to regard aliases as some kind of hard link, and use them sparingly. CC-on-delivery addresses, much like soft links, are easy to trace. > Therefore, I would prefer if courier would log RCPT TO: address before > alias explosion at least in "courierd: started" line out of the box. I > think that would be better than extra line in logs from some filter. The control file gets split in case of huge number of recipient. I recall discussions on this list about Courier not being able to accommodate some 5000 recipients because of header size limits... > And, since we already talk about logs, how do you find from the logs IP > address from which messages was submitted? By time is not accurate > enough. Looking at headers on the server is not possible if the message > was forwarded to different server or received by pop3 client and removed > from server. You still need some means to identify which message the user is talking about. Even if the subject were logged, an "August 70% off" might be not enough to identify a message. You really want the ID. I don't use Courier's "Big Brother" feature, but for some problematic mailboxes (mostly "info@" and multiple access ones) I have corresponding backup mailboxes that keep one weekful of messages, duplicated upon delivery. > E-mail clients which implement forward with headers are not > popular amongst my clients :( Yeah, those companies had a proprietary messaging framework in the '80s and badly adapted it to the Internet. It is incredible that they still have the largest market shares. (But then it is also incredible that Bush had been elected and re-elected; perhaps people love being cheated...) ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
