On Fri, 30 Sep 2005, OpenMacNews wrote:
> >
> > Where I may go, is post-bounce the rejection(s) instead, but only in
> > limited cases (blowback is something I'd like to try to avoid).
>
> heh. ok, since this was MY thread, i'm invoking the clarification-clause of ...
> er ... something ;-)
>
> could you perhaps share an _exmaple_ of what you're considering?
>
Well, not really, 'cause I haven't gotten that far, at least
not to the point of multiple-recip per-user checks actually
working at end-of-DATA :)
> i'm (re-re-)reading your response in light of the Q i'd had abt DNSBL checks --
> early/global vs late/user-specific -- and haven't a clue!
>
What I meant was, when an item is attempted to multiple
recipients, and all the recipients allow it pre-DATA per
their preferences, how do you handle per-user checks at
end-of-DATA when there are multiple recipients?
Wakko mentioned a moment ago:
> That's why I mentioned fake reject. It's basically an accept with a 5xx
> return code. The server still delivers, but the sender still sees a hard
> failure. the sending server is responcible for the bounce, not you.
...and it's not a bad idea. It's either that, or quarantine
the item for each of the rejected recipients and not send a
fakereject, or do both.
One problem with the fakereject approach, which I realize should
be easy to get around, is how do you tell the sender what rcpts
were rejected? With the old mish-mosh setup I had (pre-exim),
this was really difficult, but in exim, you could save the rejected
rcpts and include them in the rejection text.
--
--------------------------------------------------------
Dave Lugo dlugo@??? LC Unit #260 TINLC
Have you hugged your firewall today? No spam, thanks.
--------------------------------------------------------
Are you the police? . . . . No ma'am, we're sysadmins.
