Jared Johnson wrote:
>> _Every_ filter reject _must_ result in a real reject back to the sender
>> (by inline 5xx error). In this way we can ensure that someone is shown
>> that it didn't get through, and we provide them with instructions on
>> what to do to remediate a FP. By 250'ing the email,
_Every_ filter reject _must_ result in a real reject back to the sender
(by inline 5xx error). In this way we can ensure that someone is shown
that it didn't get through, and we provide them with instructions on
what to do to remediate a FP. By 250'ing the email, and eliding a
recipient, you're
"remove the connection / transaction id feature for 0.42 release
- add back in after 0.42 is out? if yes: start implementing in
-prefork" (commit message for rev 809)
I'd seen that note, I was hoping that it was going to be back in by now.
Anyone know what these problems with prefork were?
David Nicol wrote:
> 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 b
Jared Johnson wrote:
> 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'.
If we were going to go down
Hanno Hecker wrote:
> On Mon, 5 Jan 2009 15:11:06 -0600
> Jared Johnson wrote:
>
>> Chris Lewis wrote:
>>> # I synthesize my own sessionid. Whatever happened to this in core?
>>> my $session = $transaction->notes('sessionid');
>> Another opportunity to improve core ;)
> It was removed, becau
On Tue Jan 06, 2009 at 11:14:32 -0600, David Nicol wrote:
> 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.
How well does that work in practise? I've consid
On Mon, Jan 5, 2009 at 3:11 PM, Jared Johnson 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
>>
On Mon, 5 Jan 2009 15:11:06 -0600
Jared Johnson wrote:
> Chris Lewis wrote:
> > # I synthesize my own sessionid. Whatever happened to this in core?
> > my $session = $transaction->notes('sessionid');
>
> Another opportunity to improve core ;)
It was removed, because it had troubles on -pref
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
conf
Jared Johnson wrote:
> I don't imagine that this idea
> of having everything wait for DATA will be adopted: it limits the
> usefulness of plugins that could have rejected earlier, and in my mind
> it doesn't really simplify the problem much.
I'm not really suggesting that it be "adopted" in tha
11 matches
Mail list logo
