On 06/27/2014 10:11 AM, [email protected] wrote: > > Zitat von Martijn Brinkers <[email protected]>: > >> On 06/26/2014 04:51 PM, [email protected] wrote: >>> >>> Hello, >>> >>> as of today i started with the new Ciphermail release. We got bitten by >>> a missing custom processor we use for integrating AV scan on the same >>> maschine. Until now we simply have a xml with the following content: >>> >>> <!-- >>> This file will be included by config.xml. You can add all your >>> custom config >>> settings here >>> --> >>> >>> <!-- >>> Example internal transport. Can be used when you want to treat mail >>> for internal >>> and external users differently. >>> --> >>> <processor name="custom-remote-delivery-internal"> >>> <mailet match="All" class="Log"> >>> <comment> transport </comment> >>> <logDetail> middle </logDetail> >>> </mailet> >>> >>> <mailet match="All" class="RemoteDelivery"> >>> <outgoing> file://var/mail/outgoing-internal/ </outgoing> >>> >>> <delayTime> 10 secs </delayTime> >>> <delayTime> 20 secs </delayTime> >>> <delayTime> 1 minute </delayTime> >>> <delayTime> 2 minutes </delayTime> >>> <delayTime> 5 minutes </delayTime> >>> <delayTime> 10 minutes </delayTime> >>> <maxRetries> 725 </maxRetries> >>> >>> <deliveryThreads> 2 </deliveryThreads> >>> <sendpartial> true </sendpartial> >>> <bounceProcessor> bounces </bounceProcessor> >>> <xForward> true </xForward> >>> >>> <gateway> 127.0.0.1 </gateway> >>> <gatewayPort> 10027 </gatewayPort> >>> </mailet> >>> </processor> >>> >>> which was loaded in config.xml and referenced in >>> internal_remote_delivery_processor.xml like this: >>> >>> <!-- >>> The processor to use for remote delivery of internal email. By >>> default the >>> remote delivery transport of internal email will be the same as for >>> external email. >>> --> >>> <!-- >>> <processor> transport </processor> >>> --> >>> >>> <!-- Example: Use custom-remote-delivery-internal specified in >>> custom_processor_config.xml --> >>> <processor> custom-remote-delivery-internal </processor> >>> >>> From my understandig it should be enough to move our custom_processor >>> xml file to custom-processors.d to get it included automatically, no? >>> >>> This does not work, the processor was still missing and >>> custom_processors.xml stayed empty. Our workaround was to alter >>> config.xml to reference our file instead custom_processors.xml :-( >> >> Hi Andreas, >> >> My apologies. This part was changed. I should have documented it but >> there is so much to document that I forgot. > > My fault, i suspected problems because of this: > > "Three custom properties and templates added. These properties and > templates can be used if the mail flow (config.xml) is modified by the > admin and the changes require some user configurable options." > > but it was listed under the previous release so i tried anyway :-) > > Furthermore my test environment lacks the AV component and therefore > this problem was not detected. > >> >> I have changed the way customer processors and custom mailet/matchers >> can be added. You can now drop an xml file in a .d directory. For >> example to add a custom processor drop an xml in the dir >> custom-processors.d/. When the back-end is started, the file >> custom_processors.xml will be generated from the xml files from the >> processors.d/ dir. >> >> What is important is that the xml file should look like: >> >> <processors> >> <processor name="custom-encryption"> >> PROCESSOR 1 >> </processor> >> >> <processor name="custom-encryption"> >> PROCESSOR 2 >> </processor> >> >> etc. >> </processors> >> >> To make it possible to add more then one processor to the xml file, the >> processors should be embedded within a <processors></processors> tag. >> >> I guess you have set the processor in the file >> internal_remote_delivery_processor.xml to >> custom-remote-delivery-internal? This has not changed. > > Yep, the only real problem was that my old custom processor has no > <processors> tags around and was therefore ignored :-(
Good to hear it works. The main reason of the new approach (i.e., using the .d directories) is that it allows you to add or override the mail flow just by dropping files in the .d directories. This makes it easier to add and remove new functionality without having to manually change any files. Kind regards, Martijn -- CipherMail email encryption Open source email encryption gateway with support for S/MIME, OpenPGP and PDF encryption. www.ciphermail.com _______________________________________________ Users mailing list [email protected] https://lists.djigzo.com/lists/listinfo/users
