> Sorry about the late reply...
> > > This isn't how Sendmail works. The entire message is cached to the queue
> > > before milter is told anything about the headers or body. There's no "a
> > > few
> > > seconds ahead", it's all the way ahead. Milter has no opportunity to say
> > > REJECT in the middle of the SMTP DATA phase because the filter doesn't
> > > even
> > > know that's where the MTA is.
> >
> > Interesting... Our milter implementation actually sends the message to the
> > client as it is received. Of course any REJECTs or ACCEPTs or whatever that
> > occur along the way are noted and further output to the milter is blocked.
> > The status is then considered after the message is complete.
> >
> > Implementing it the way we did was something of a PITA; I certainly can
> > understand why sendmail opted for the collect then send approach.
> The sendmail way has the advantage of being more efficient if you have
> slow clients and/or heavy milter processes.
How does that follow? The only difference is that in one case you're feeding it
the data as it comes in while in the other you're buffering up the data and
sending it as soon as the end of the message is received. Either way the milter
is running throughout the message transfer, unless you're willing to hold off
on even starting the milter until after the message transfer, in which
case it can't do things like refuse specific recipients.
Maybe I'm wrong, but I thought sendmail starts milters at session startup.
> Because it runs milters as
> fast as they will go, it doesn't require as much milter concurrency to
> deal with a given volume of mail.
Again, that would only be true if milter only starts after message transfer,
which severely limits it's ability to interact with the SMTP dialogue. I mean,
what's the point of saying you don't like the IP address or EHLO parameter
after the message has been transferred/
Ned
