OT - Re: Wildcard certs - why only one level deep?
On Fri, 07 Aug 2009 21:28:58 -0400 Jorey Bump l...@joreybump.com wrote: I understand that wildcard certs can be considered a security risk, but is the risk really much greater if it includes a longer hostname? *.com Here's a better example. I might be willing to have my server say, Yes, that's me to this name: southamericadip.asciiking.com But not this one: guns.southamericadip.asciiking.com If I make a delegation in DNS to the person running South America Diplomacy, however, I don't have any further control over downstream consumers of the subdomain. Someone who behaves perfectly well on my server might be an exceedingly poor judge of character. Without limiting the depth of the certificate, I would have no way to accept a TLS connection as the first without being open to the second. I love waking up to a sub peona, don't you? :-) Chris Babcock signature.asc Description: PGP signature
report to consolidate allowed messages
Hello, I have been toying with the best way to produce a report of 'allowed' messages that have made it all the way through my Postfix. I love the Postfix logs, they give such detail on failures and refusals and parsing this is quite straightforward. The entertainment commences when I try to figure out how to produce a report of 'allowed' messages. This needs to contain just a few pieces of key information; date/time fromto subject client IP At first, I thought 'this will be easy' but upon closer examination this is not as simple as it looks. Where Postfix is multi-process, the bits of information are in different places and consolidating this has some challenges. In particular matching up (by script) the interaction for a transaction between; postfix/smtpd postfix/cleanup postfix/virtual postfix/qmgr Perhaps there is an easy way to get the five metrics I would like in a report? I am starting to think I may need to plug something in to 'scan' the headers of a message after Postfix is done with it or pipe the messages through a script? To keep things lean and for learning, I am interested to achieve this with a some Perl- so my interest is really in finding the 'key' to link the information together from what is already produced - or - to work out how to get messages to pipe through a script as 'virtual' delivers them. Unless Virtual can give me all the information I need (logging options) Perhaps some of the very clever guru's here have some useful suggestion? -- --- C Werclick .Lot Technical incompetent Loyal Order Of The Teapot. This e-mail and its attachments is intended only to be used as an e-mail and an attachment. Any use of it for other purposes other than as an e-mail and an attachment will not be covered by any warranty that may or may not form part of this e-mail and attachment.
Re: report to consolidate allowed messages
Clunk Werclick schrieb: Hello, I have been toying with the best way to produce a report of 'allowed' messages that have made it all the way through my Postfix. I love the Postfix logs, they give such detail on failures and refusals and parsing this is quite straightforward. The entertainment commences when I try to figure out how to produce a report of 'allowed' messages. This needs to contain just a few pieces of key information; date/time fromto subject client IP At first, I thought 'this will be easy' but upon closer examination this is not as simple as it looks. Where Postfix is multi-process, the bits of information are in different places and consolidating this has some challenges. In particular matching up (by script) the interaction for a transaction between; postfix/smtpd postfix/cleanup postfix/virtual postfix/qmgr Perhaps there is an easy way to get the five metrics I would like in a report? I am starting to think I may need to plug something in to 'scan' the headers of a message after Postfix is done with it or pipe the messages through a script? To keep things lean and for learning, I am interested to achieve this with a some Perl- so my interest is really in finding the 'key' to link the information together from what is already produced - or - to work out how to get messages to pipe through a script as 'virtual' delivers them. Unless Virtual can give me all the information I need (logging options) Perhaps some of the very clever guru's here have some useful suggestion? Hi, take a look to pflogsum, this may give you a good start info for your own perl script http://jimsun.linxnet.com/postfix_contrib.html http://postfix.state-of-mind.de/patrick.koetter/pflogsumm/ -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
is there any way of distinguishing the bcc copy from the original?
I'd like to treat the original and the bcc copy slightly different based on their content. Basically: a) original: if headerX matches condition1, override transport to divert email. b) bcc-copy: if headerX matches condition2, override transport to discard email. Anything that matches condition2 will also match condition1, but not vice versa. I was hoping there was e.g. a way of making an if-style header_check to apply different conditions to each copy. (I've already looked at running multiple cleanup daemons etc., but that gets very ugly very quickly). /Per Jessen, Zürich
Re: is there any way of distinguishing the bcc copy from the original?
On Sat, 08 Aug 2009 11:24:55 +0200 Per Jessen p...@computer.org wrote: I'd like to treat the original and the bcc copy slightly different based on their content. Basically: a) original: if headerX matches condition1, override transport to divert email. b) bcc-copy: if headerX matches condition2, override transport to discard email. The only way to know that a message was sent BCC is if the envelope recipient isn't listed in the headers. Do that and you discard all the mail that comes from properly configured mailing lists and undisclosed recipient headers. Filter after address rewriting and you lose a whole lot more mail than that. How about the root issue? You either got an always BCC configured that you don't want or a specific class of Spam that can probably be handled in a better way. Which is it? Chris signature.asc Description: PGP signature
Re: is there any way of distinguishing the bcc copy from the original?
Chris Babcock wrote: On Sat, 08 Aug 2009 11:24:55 +0200 Per Jessen p...@computer.org wrote: I'd like to treat the original and the bcc copy slightly different based on their content. Basically: a) original: if headerX matches condition1, override transport to divert email. b) bcc-copy: if headerX matches condition2, override transport to discard email. [snip] How about the root issue? You either got an always BCC configured that you don't want or a specific class of Spam that can probably be handled in a better way. Which is it? I want to use recipient_bcc_maps to create an archive copy of inbound email after it has been filtered. My filtering just marks (with a header) the email as yes/no, which is what my condition1 from above works on. The problem is that my bcc copy needs to go somewhere else, so I would essentially need a different set of header_checks. I thought I might have been able to work some magic with the if-endif construct in header_checks, but I realise I didn't quite understand how it worked. /Per Jessen, Zürich
