Re: [exim] when are exim vars first available? and ...

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Dave Lugo
Ημερομηνία:  
Προς: exim-users
Αντικείμενο: Re: [exim] when are exim vars first available? and ...
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.