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 the route of individual user configurability
(we won't), this approach would be considered absolutely unacceptable by
our operational rules.
_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 blackholing the email. Not acceptable in our environment.
I've seen some people trying 4xx errors (if the rcpt to settings differ)
to try to force the sender to resend each of the recipients
individually. I have my doubts as to how universally that'd work.
> 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?
It seems to be extremely uncommon to the point of virtual non-existence.
[modulo the comment about tipjar.]
>> &NTMqplib::configpattern($self, 'badhelo');
>
> This seems like a nice candidate for submission to QP trunk as
> enhancements or an alternative to $self->qp->config(), if the
> pointy-hairs at your particular place of employment are game.
It was intended to be open source, but I'd have to ask. But not just
for that ;-)
>> # I synthesize my own sessionid. Whatever happened to this in core?
>> my $session = $transaction->notes('sessionid');
>
> Another opportunity to improve core ;)
It's supposed to already be in core ;-) I'm not even absolutely
convinced that ours doesn't generate collisions (we're running -async
;-), but it doesn't seem to - at least not often.
