[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNS error after: RCPT TO

Enrique Vadillo <vadillo@rcp.net.pe> wrote:
: I'm using ZMailer Server 2.99.50-s18 and i have found that it has a different
: behaviour regarding RCPT TO analisis, when it receives a RCPT TO line
: with a nonvalid target domain, it issues the message:

: 250 2.1.0 Sender syntax Ok
: rcpt to: <john@sdfdsgr4325432ddddewrgewrgtrew.com>
: 553 5.4.3 Policy analysis found DNS error on the target domain.

: This is not something that we would like to happen, since we all know
: that DNS outages are very likely to take place temporarily and complains
: to this immediate error message are being received ever since we upgraded
: from 2.99.50-s5 to 2.99.50-s18

The current implementation does understand the difference between
temporary DNS failure (no answer, loss of caching nameserver to ask,
etc...) and permanent DNS failure (AA returning no answer part).

It does correctly respond 4xx or 5xx according to a temporary or
permanent DNS failure.  Since we sometimes have a problem with a well
known ISPs mail system which does an immediate retry of the email after
receiving a 4xx response.  It gets a 4xx response because MAIL From:<>
domain had a single character typo in it, this incorrectly spelt domain
is registered and delegated to a set of lame DNS servers.

The only problem with accepting the email is it creates the potential for
a backlog to occur, where a mail server would become saturated with held
incoming email (potentially maliciously) before the temporary DNS failure
was cleared.  Since it would be easy for an attacker to setup this scenario
and DoS your mailserver (register a new domain, delegate it into thin air).

This is sort of where you want backlog/quota checking all the way from
the mailfile, through the queues/router to finally emit a:

4xx User mailbox is full

from a followup SMTP transaction attempt.

I wouldn't have thought its a big problem, since all domains have multiple
delegated DNS servers and that most SMTP email travels from origin to
destination domain in a single SMTP transaction (or rather most of the DNS
failure errors don't occur on any intranet hops, but over the long haul
Internet hop).  One of the DNS servers is usually within the origin network,
or that networks upstream provider network and of course connectivity works
there because you would have received the incoming SMTP connection.

: Is there any way i can decide to accept ANY recipient and analyze it
: afterwards? not giving up the (presumably) invalid target domain 
: right away?

My current thoughts on this as basically being able to insert a mail
processing task between SMTP reception and router submission.  Add
things into smtpserver to log extra information into the file (which you may
need that it doesn't already store), run the task to inspect each mail
and then submit it to the router.

Darryl Miles

Webtraffik Netbauds Ltd