Charlie Brady wrote: > > On Sat, 8 Nov 2008, Bj�rn Metzdorf wrote: > >>> Why does smtp-forward not adopt to the 550 from the internal >>> mailserver? >> >> I made a patch to address this problem in the "rcpt to" stage. >> Multi-recipient mails with one failing recipient will be a problem >> here I suppose.
> smtp-forward should hook into each phase of the smtp conversation, and > should contact the backend and relay status for each phase. Doing it all > at the end is simple, but wrong. If your internals are well behaved, and fail/reject only on exceptional conditions, it suffices to "hook in" (in some fashion) only at hook_rcpt. Hook in at each phase can (a) cause extreme difficulties (broken connections, timeouts etc) or loading on the internals (we'd need more internals), and (b) make retries a real PITA. Qpsmtpd is supposed to shield your internals from the outside and do all your filtering. Having them make the internals mimic the qpsmtpd sessions is, er, sub-optimal. Perhaps a bit less "correct" to do it all in the forwarder, but with care it's close enough. Lyris Mailshield (which is what our qpsmtpd installation is replacing) issued "recipient verification probes" (much like SAV) at the internal mail server at RCPT TO time, and returned that. It then replayed the entire conversation (if at least one recipient existed and the email passed the filters) to the internal mailserver after DATA. It then returns the internal's code to the sender. The probes caused significant loading on the internals. Our qpsmtpd does recipient RCPT verifies against a flat file that's rsync'd to them (eventually will go to LDAP), and smtp-forwarder does the rest. Our version of smtp-forwarder does retries and failover. I'm going to have to recheck what it does on internal MTA fails. Net::SMTP is a bit of the PITA in getting back return codes IIRC.
