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...
Haven't done NDRs at DATA time since the very early days of Mailshield
in 1997 ;-)
If you have the oomph for it, rejecting spam after DATA (and NDRs after
RCPT) is probably about the optimal solution. You can quarantine
everything (except NDRs that you reject on) if you wish, and you still
don't blowback.
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. We also don't
accept anything for a user we know doesn't exist, although methods for
verifying that a user exists are configurable. We allow users to
configure whether or not to allow the null sender, although there is
some concern that we'll end up on rfc-ignorant for this. Also, I've
done a bit of testing under heavy load and it's been impressive how much
of a performance hit we take for accepting at MAIL FROM, getting a
recipient, finding them, looking up their null sender pref, and
rejecting the null sender -- as opposed to just rejecting null sender at
MAIL FROM regardless. This probably has more to do with our own
efficiency problems elsewhere, of course :) But at any rate it's worth
doing for the extra configurability.
At present, at rcpt-to time, we have a plugin that consults a config
table (indexed by domain, but it could also do per-user) that decides a
number of things, such as:
- do we verify recipients?
- is filtering on for this domain?
- do we forward email destined to this domain or not?
- do we save copies?
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...
# common string pattern file reading function - handles regexp and
# non-regexp interspersed, All string/pattern matching plugins
# use this. config/<name> is read, and compiled pattern is stuffed
# in $self->{f_<name>}
&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.
# I synthesize my own sessionid. Whatever happened to this in core?
my $session = $transaction->notes('sessionid');
Another opportunity to improve core ;)
-Jared
