On Sun, 20 Mar 2005 21:02:02 +0000, Stefek Zaba
wrote:

:::Jerry:::: wrote:

Right, so the sending mail server will look up DNS of the sub-domain
and not just the 'parent' domain ? That is making sense now, why
couldn't you have said that in the first place ?!..

It doesn't work that way round, as it happens: the sending mail machine
(which need not be a "server" - some people run their personal desktop
system as a fully-capable mail-sending machine, though most just point
at a "smart" next-hop mailhost) asks, through the DNS, for the list of
MX servers for that particular, fully-qualified, machine - if the
request is for the MX handlers for a.tiny.subdomain.of.something.big.net
the response relates to a.tiny etc - the mail handling program isn't
expected to recurse up/down the domain hierarchy. The MX entries each
come with a "priority", lowest number being "best", i.e. most
appropriate; the sender tries to establish contact with an SMTP handler
on each entry on the list, in priority order, unless that priority is
"worse" than its own for that domain (this is how we avoid mail routing
loops).

Well we try, anyway. However, it does require sobriety when writing
sendmail rules.......



While the DNS does support "wildcard" entries, so an MX server can be
listed as handling a whole chunk-o-domain, the response "looks as if"
it's specific to the particular domain (a.tiny.subdomain etc in the
example above), so the sending mailer doesn't need any special smarts to
handle a 'wildcard' MX entry - that's the DNS server's (well, servers'
;-) job.


I suspect that there are a number of additional places where various
forms of caching go on which make a confusion of some of this and
where the spammers certainly don't follow the rules.

For example, a week ago, I needed to do some network readdressing that
involved the public address of my mail server being changed. This
meant that the MX records in the public domain servers needed to be
changed to reflect that so that mail transaction connections would be
made to the new address.

This was duly done during a quiet period last weekend when there is
little legitimate incoming mail - obviously outgoing is not affected.

Normally I would expect the address change to have propagated through
the Internet and for DNS servers at mail sending hosts to have updated
to the new address. I left the old configuration in place for about
a day to allow incoming mail to the old address to be delivered, and
then switched address configurations for the new IP address to be
used.

I logged all SMTP connection attempts (passed and failed), and most
were to the new address or if attempted to the old address would
shortly be made again on the new one. All of the legitimate and
common sources from which I receive mail picked up the address change
very quickly and nobody complained of undelivered email.

However, a week later, I am still getting quite a number of connection
attempts to the old address. This is way past normal DNS server and
other network software timeouts as far as I know. I did some address
checking and almost all are from known spam server sources.
It seems that they cache IP addresses for a long time or deliberately
store them, which rather surprised me.....
Perhaps it's to save doing as many DNS lookups?








--

..andy

To email, substitute .nospam with .gl