Re: MTA or SMTP proxy?

On Fri, Jul 03, 2009 at 09:55:40PM +1000, Barney Desmond wrote:
> > Recently I am thinking of reimplementing our MX servers. Of course rcpt
> > check is a must, also I should not generate NDRs later, I should only accept
> <snip>
> 
> This is all very standard behaviour for an MTA. Recipient checking is
> a very common task for most Postfix users. Regardless of what you
> expect or want, SMTP is a store-and-forward protocol - queues are a
> strong component for an MTA.

I don't think so, SMTP itself is just a protocol, you can use it without
having and storage too. It's another question that how useful it is then ...

And rcpt check was just a question. I just say it's quite useless to do a
separated rcpt check on the MX servers, I mean not with some database lookup
with SMTP which is used to transfer the mail further too, so no other
infrastructure needed then (and that connection will be kept open to do the
transfer as well not just the mail "acceptance" check)

> 
> You say you don't want to accept mail unless you're certain that the
> backend can accept it, but the only way to know is to try. If it
> succeeds then you might as well take it, you've already succeeded. In
> any case, this amounts to simply collapsing all the layers of your   
> mail system, from receipt to storage. This of course depends on how
> you expect to implement the systems, which you've not described.

Yes I would try, at the same time as SMTP commands arriving to the MX
servers. That's why I said, it's more like an SMTP proxy function and not an
MTA - maybe. So, for example, I can do, after receiving the MAIL FROM and
RCPT TO commands, but before giving answer for DATA from the sender, I would
open an SMTP connection towards the backand and "play back" the SMTP
transaction, if it accepts, it's ok. Surely, if OK I will continue to
transfer the mail itself (after DATA). It's a proxy like functionality,
that's why I think it's not so postfix oriented question, but I asked that
here, because otherwise I would like to do extra checkings with very complex
rules implemented by a postfix policy server for example, because we have
already experience to do that. Just if I try to think about this more, it
turns out that postfix secure and multi daemon design does not allow this
kind of processing, what I described here. So in nutshell: this solution
would work like (for example) the squid http cache (but without caching), so
the HTTP request itself is got, then the server does not close the
connection with the client of course, and same time it tries to serve the
request to send a request to a server, and (if everything is OK) answering
to the client then. Also maybe it's a stupid example, but as with this
squid, you can implement extra ACLs, and complex rules as well to controll
the stuff, of course it's not a simple 1:1 repeater, it wouldn't make too
much sense then to have it.

--

-- 
- Gábor