2009. 10. 4, vasárnap keltezéssel 11.27-kor Sahil Tandon ezt írta: > On Sun, 04 Oct 2009, Laszlo Kupor wrote: > > > 2009. 10. 3, 12.39 Victor Duchovni wrote: > > > On Sat, Oct 03, 2009 at 12:16:26PM +0200, Laszlo Kupor wrote: > > > > > > > This situation in Postfix environment different. > > > > Postfix after accept mail query all domains (domain1,2,3) MX and sends > > > > email in separate SMTP session per domain name also if same MX of all > > > > domain. The example above sends 3 mail with 2,1,1 recipients in 3 SMTP > > > > session, 3 mail on network,3 processes and resources. > > > > I search documentation, and internet but not found solution to emulate > > > > Sendmail behavior in Postfix. > > > > > > > > The question i can emulate this in Postfix? > > > > > > No. Postfix never sends recipients for different transport:nexthop > > > combinations (the nexthop is typically the recipient domain) in the > > > same envelope. > > > > > > There are good reasons for this, it is difficult to do this and still > > > have a reasonable queue scheduling algorithm (Sendmail has no global > > > scheduling at all, which is far worse than occasionally splitting > > > envelopes). > > > > Thanks for your reply, Sendmail stay here. > > I can't go with you in this situation. The administrators view: this is > > big performance loss in some situation(maybe rare), and can occurs > > duplicate mail delivery (i tested, for a day and overhead above 150% > > here). I can't see clearly why good this, but i accept this is good. > > Just not for me and not for now. If you have a written documentation > > about queue mechanism please give me a reference. > > You've already been linked to one document, but here it is again with > one more. Please read carefully. > > http://www.postfix.org/CONNECTION_CACHE_README.html > http://www.postfix.org/SCHEDULER_README.html >
Hello, Thanks again, but one part of this documents absolutely other view of my problem, other part is a documentation. The first one (linked before), only give effect in very specialized environment, and not for TLS connections. And not give solution for duplicate delivery. SCHEDULER_README: Concurrency scheduler make steps against pressure of negative SMTP connections. Absolute useless in my problem Preemptive scheduler well, this is a good document to introduce queuing mechanism, and this very interesting not contains restriction domain=destination, and now much confused, why and how limit postfix destination/transport nexthop = domain. Quote: "Whenever nqmgr moves a queue file into the active queue, the following happens: It reads all necessary information from the queue file as oqmgr does, and also reads as many recipients as possible - more on that later, for now let's just pretend it always reads all recipients. Then it resolves the recipients as oqmgr does, which means obtaining (address, nexthop, transport) triple for each recipient. For each triple, it finds the transport; if it does not exist yet, it instantiates it (unless it's dead). Within the transport, it finds the destination queue for given nexthop; if it does not exist yet, it instantiates it (unless it's dead). The triple is then bound to given destination queue. This happens in qmgr_resolve() and is basically the same as in oqmgr. Then for each triple which was bound to some queue (and thus transport), the program finds the job which represents the message within that transport's context; if it does not exist yet, it instantiates it. Within the job, it finds the peer which represents the bound destination queue within this jobs context; if it does not exist yet, it instantiates it. Finally, it stores the address from the resolved triple to the recipient entry which is appended to both the queue entry list and the peer entry list. The addresses for same nexthop are batched in the entries up to recipient_concurrency limit for that transport. This happens in qmgr_assign() and apart from that it operates with job and peer structures it is basically the same as in oqmgr. When the job is instantiated, it is enqueued on the transport's job list based on the time its message was picked up by nqmgr. For first batch of recipients this means it is appended to the end of the job list, but the ordering of the job list by the enqueue time is important as we will see shortly. " Think, a (may rare) example: in a popular mail handler (or mail handlers) with many (1000+) domains catch the mails from the internet, and deliver to mailbox backend server(s). If i send email to all hosted domain i...@domain.tld email address if SMTP client Postfix and connect with TLS do 1000 connection to deliver this only one mail. If this SMTP client is a Sendmail connect and sends (1000/max concurrent recipient). In other view. If you have corporal alias pl postmas...@domain.com witch deliver many postmaster in organization, if one of them send mail to postmaster@ and other postmaster (because this is a policy) send a reply to all the original poster receive 2 absolute same mails with postfix and 1 mail with Sendmail. Again, i understand Victor email, and accept. But not understand why limit nexthop/destination for one domain. -- Udv.: Willy PGP GNUPG/1.0 ID = 44E7F3A4 Kupor Laszlo Attila <wi...@dunanet.hu> Key fingerprint = 1294 00C9 F7ED AE32 1D2D B80A D5C9 98D6 44E7 F3A4
