> Did you specify FLAG_MASK_EXTERNAL as argument to queue/postfix-queue ?
I believe this will only affect the further processing of the mail, e.g. use of virtual domain/alias tables. As it does not work properly without that flag anyway, yes, it was set. In the meanwhile I did some further investigation. It appears that quite a good part of the delay is happening internally in qpsmtpd. As I said, with my alternative queuing plugin a big mail now only took about 16 seconds. I then increased logging to see which plugin runs when and the queue plugin is only called after 14 of these 16 seconds. In the steps before queuing qpsmtpd does some copying/processing and it processes the mail line by line. I suspect this to be the reason of the delay. I'm not sure if this can be changed easily. I would guess that other MTAs do this processing already while receiving the mail (data-phase before data post), therefore not having to do the processing in full afterwards. Oh, and the queing plugin will again process the mail line by line, adding further delay. This is true for all queue plugins. This can surely not be changed easily without deep modifications inside qpsmtpd and the way we process a mail. With my alternative queing plugin the delay is now more or less acceptable but I'm still not satisfied. I think more research in finding the source of the long delay is warranted as even processing 10 MB line by line shall not be that slow on a modern machine (this is a quadcore Opteron). Regards, Michael -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
