[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Hi Martijn That sounds interesting - however in the case of a backup MX - the reason it's been called is because the customers mail server is not available at that time. In respect to the external MX regularly checking if an address is deliverable - that is an interesting concept. How would you do this as I thought (correct me if I'm wrong) that VRFY is disabled by default or in some cases not even supported these days? I'm particularly interested because at present we have a number of mail server who run from ldap database servers. So at the edge it's possible to confirm if a message will be delivered and where. Then on the mailbox servers themselves again to confirm to whom the messages are to be delivered to. The issue is that under "big load" it would be nice for the external MX's to be able to operate autonomously. Is this what you are suggesting ? Best regards Mick On 25/06/2009 14:41, "Martijn Grooten" <sweetwatergeek@xxxxxxxxxxxxxx> wrote: > On Thu, Jun 25, 2009 at 2:16 PM, Mick Vaites wrote: >> If it's an internal MX then there is no reason why this box shouldn't have >> knowledge of whether an email will eventually be delivered or not. >> >> However as we're talking ISP backup MX or Smarthost - they cannot drop >> bounces on behalf of their customer as it might be needed genuinely. >> >> The only place that messages can be blackholed is by the person who's domain >> is being attacked. > > If the two MXs work well together, the external one can be configured > to regularly check with the internal one to see if certain addresses > exist. It can do so during an SMTP transaction and, if the address > doesn't exist, drop the connection. It's fairly common for MXs to work > this way. > > Martijn. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html