Am 04.11.2012 19:05, schrieb Christian Rößner: > Hi, > >>> Would it technically possible to have a smtpd_to_lmtp_proxy option (or >>> however it could be called), that would receive on smtpd and open a >>> connection to its LMTP server, doing cleanup and Co. in memory and wait for >>> the result of the LMTP server? If the LMTP process gets 250 OK, postfix >>> would give that back to the client. Else closing the session with error >>> status code received from the LMTP server. >> >> quota and such things can be done with a policyd, below a example for dbmail >> ___________________________ >> >> generally wait for a 250 OK from LMTP would be dumb > > But you have to wait for that with smtpd_proxy_filter as well ;-) > >> >> * think about performance > > Improvmnet. No queuing on MTA side
this is NOT a improvement this degrades performance DRAMATICALLY don't get me wrong but the queuing was developed by smarter people you understand mail-flow and to think "No queuing" is a improvement shows only a lot of missing knowledge usually people not undertsand how e-mail works coming up with such solutions not realizinh that they only make a huge damage to their mail-system and weeks later they come back here and whine for help >> * think about temporary LMTP problems > > 450 Service currently not available. Same behavior than with Milter problems. oh so you do NOT want always wait for 250 OK >> * consider how make a difference hard/soft > Can you give mor details on that? hard: do not try again do deliver this message soft: temporary error i have seen way to often people trying what you like resulting in hard-bounces by the first delivery where you can see the origin "450 Service currently not available" of the last hop or the opposite where a poor configured mailsystem anserws with 450 where you can see their last hop's reply is a "user does not exist" >> * you do NOT want a hard-bounce obly because LMTP hangs > Why? If I can not hand over mail to the LMTP server, the remote MTA would > still queue the mail and retry later because if i know the RCPT is valid there is NO reason to reject in cause of temprary internal errors, if this happens longer the remote MTA would have a large delay while the postfix queue would deliver immeditially after the problem is fixed >> some months ago i did as example a major-upgrade on dbmail >> i stopped imap/pop3 and closed submission port >> but we received new messages due the whole migration >> after that "postqueue -f" delivered all of them to the inboxes > > See above NO, not "see above" it is the wanted behavior not to reject messages if i know their RCPT is valid and i have a queue which is EXACTLY for such situations
signature.asc
Description: OpenPGP digital signature
