Re: MTA or SMTP proxy?

Gábor Lénárt a écrit :
> Hei,
> 
> 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
> mails from outside which won't cause bounce on the mail store MTA later. My
> problem: there are some conditions cannot be forecasted easily, I can't be
> sure that mail can be delivered (over quota, user is deleted between the
> moments of mail at MX and the mail storage etc). Some people would say, that
> this issue is minor, and quite rare so I should not care about this. However
> I think even rcpt checking can be eliminated on MX servers if I have some
> kind of SMTP proxy like thing (instead of "real" MTA with queue) at the MX
> servers. Since mail store won't accept the mail for non-existing rcpt
> address, an SMTP proxy like solution does not even need rcpt check itself.
> Also the over quota problem is solved. Also, I hate when there is some rare
> problem with the backend mail servers (mail stores) and we have huge queues
> filled up with waiting mails, I would say, that MX servers shouldn't accept
> anything if they are not 100% sure that they can transfer the mail to the
> backend. Since MTAs should have queue anyway, I am not sure this kind of
> SMTP proxy server can be implemented with postfix (it would be great since I
> would be able to use its policy server and maybe milter too), the key
> feature that it shouldn't use any queue, when sender MTA issues the
> corresponding SMTP commands, it should do that for the backend and giving
> back the result. What do you think, is it a bad idea? I know this is really
> not like a traditional MTA, should I use some kind of SMTP proxy solution
> instead then? Any idea? Thanks a lot.
> 

if you use a "proxy", then you expose the final MTA. you lose the
possibility to "aggregate" connections (connection caching). at one
time, you will need to check why you need a proxy at all. if it is to
protect a robust MTA such as postfix, then this is plain waste. if it is
to protect a "weak" MTA, then you don't want to expose the MTA at all.

queuing has a benefit: "channel attacks" don't succeed in real time. the
attacker needs to guess when the message is delivered. the old smap (TIS
fwtk) initially had no other benefit than isolating the client and the
server by adding an intermediary queue (so that attacks that could cause
sendmail to open a hole could no more work, since the sendmail process
is not accessible via the internet).

I am not saying that a "queue-less" proxy doesn't have a place, but you
need to justify its use. In particular, I wouldn't use assp (despite its
good "things").