On Mon, Jan 5, 2009 at 3:11 PM, Jared Johnson <jar...@nmgi.com> wrote:
> Chris Lewis wrote: > >> I'm not really suggesting that it be "adopted" in that sense. But what >> would make sense is to have each plugin operating to a common model for >> whether filtering is on, deciding when to reject, logging, reason >> reporting etc, where "don't reject until after DATA" could be a >> configuration option, as would "reject as soon as you decide you don't >> want it" (plus various marking techniques etc) >> > > That does sound sound more reasonable than what I imagined, e.g. having > everything in QP conform to the 'reject later' model by mandate :) It > doesn't exactly fit the way we've been thinking so far about per-recip > config handling in a multi-recip environment though... > all that is needed IMO is agreement on keys in notes for use with multiple plugins that check recipients. I'm issuing DENYSOFT on recipients after the first when there is going to be data analysis required by either the first or by the new recipient to make an accept/reject decision. If multiple rcpt_hook plugins were to do this collaboratively, there would have to be a convention. > When we get all the way to DATA with ex. 2 recips, scan the message, and > one accepts it while the other wants to reject, we say 250 and then quietly > discard the second recip, effectively turning his 'reject' preference into > an 'ignore'. Actually, we have the beginnings of configurability for this, > allowing recipients to say 'if I wanted to reject a message bug somebody > else wanted to accept it, ignore/quarantine/delivery/bounce it instead'. > But nobody has really bothered using this option, so the default of ignore > has become universally accepted. It certainly can cause problems. I'm saying, DENYSOFT the second one at rcpt time. A simple "one-rcpt-only" plugin to include before the per-recipient config checker to decline on the first and denysoft the rest would do the trick in a kind of broadaxed fashion, if you're lazy and don't mind your end-users experiencing uneven delivery of their mailing lists when more than one are subscribed to one. > What do you do about multiple recipients with multiple domains? What if I > try to send a message to f...@foo.com and b...@bar.com and they each have > different settings? Does this even happen -- that is, do most MTA's even > bother trying to lump recips with the same MX but different domains into the > same transaction? If it's extremely uncommon, then one way to get around > this would be to note the domain of the first accepted recipient and then > defer any recipients to other domains. Of course this means you can only > have per-domain preferences, not per-recip preferences... > You have to treat the whole address as the key to the preference looker-upper, as SMTP allows recipients with multiple domains in the same transaction. The latest release of tipjar::MTA (outbound) for example organizes multiple recipients after an MX lookup instead of by domain. DJB said it was silly to do such a thing in the qmail release notes, explaining why qmail-send resends messages instead of grouping.
