mail to deleted domain

I have an homegrown tool to produce a daily statistic of ham and spam on
our mail servers (main antispam protection are spamassassin with amavis
and greet pause) by "reason". I occasionally see peaks (1-2 days) of
messages flagged "reason= rejected AND lost input channel" ... for
instance 664 last night.

Looking back at the awk script I wrote long ago and to /var/log/mail, I
see that those messages are triggering an error check_rcpt, followed by
a lost input channel like in this example

ruleset=check_rcpt, arg1=,
relay=ABTS-AP-dynamic-055.165.169.122.airtelbroadband.in
[122.169.165.55] (may be forged), reject=550 5.7.1
... Relaying denied. IP name possibly forged
[122.169.165.55]

lost input channel
from ABTS-AP-dynamic-055.165.169.122.airtelbroadband.in [122.169.165.55]
(may be forged) to MTA after data


Now the curious thing in all this is that domain mi.iasf.cnr.it is our
old, no longer existing domain. We junked it last June (after some 2
years we've been on newer inaf.it domains it was receiving almost only
spam ... in fact the daily spam rate fell from 2200 to 1000).

There are no MX records nor NS records for it, so where do spammers get
the association between the old domain and our present MX's (which are
of course the same as of old) ?

I guess there is nothing more we can do at sendmail level than
generating the Relaying denied error (as for any other external domain),
nor at DNS level (since everything was deleted for the old domain).


--
------------------------------------------------------------ ----------
nospam@mi.iasf.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.

Re: mail to deleted domain

Hi,

I have seen similar things when I moved a domain to a different
server. Spam arrived at the old server long after changing MX for the
domain.

I came to the conclusion that in the spam business not only mail
adresses are sold but also the matching MX to avoid costly DNS lookups
and increase throughput.

--
Stefan

Re: mail to deleted domain

On 04/17/08 11:20, Stefan Moeding wrote:
> I have seen similar things when I moved a domain to a different
> server. Spam arrived at the old server long after changing MX for
> the domain.
>
> I came to the conclusion that in the spam business not only mail
> adresses are sold but also the matching MX to avoid costly DNS
> lookups and increase throughput.

This makes me wonder if it would not be advantageous to routinely (you
pick how frequently) change the IP address of your MX servers. I.e.
have a block of 4 (not necessarily a subnet) for each MX and just rotate
through them. I.e.

..08 MX 10 Period 1
..09 Period 2
..10 Period 3
..11 Period 4
..12 MX 20 Period 1
..13 Period 2
..14 Period 3
..15 Period 4
..16 MX 30 Period 1
..17 Period 2
..18 Period 3
..19 Period 4
..20 MX 40 Period 1
..21 Period 2
..22 Period 3
..23 Period 4

(Or if you are a larger install that hosts multiple domains, move
through the entire list making an MX be active, but for different domains.)

Rotate through the periods and wrap back to the beginning when you reach
the end. Have an address configured with a 550 mailer while it is not
an MX.



Grant. . . .

Re: mail to deleted domain

On Thu, 17 Apr 2008, Grant Taylor wrote:
> On 04/17/08 11:20, Stefan Moeding wrote:

>> I came to the conclusion that in the spam business not only mail adresses
>> are sold but also the matching MX to avoid costly DNS lookups and increase
>> throughput.

So this matches my conclusion :-(

> This makes me wonder if it would not be advantageous to routinely (you
> pick how frequently) change the IP address of your MX servers.

Interesting suggestion ...

> Rotate through the periods and wrap back to the beginning when you
> reach the end. Have an address configured with a 550 mailer while it
> is not an MX.

Our MX already generate a 550 5.7.1 Relaying denied when spammer attempt
to use them for the old no longer existing domain.

Your rotation suggestion has a drawback in our situation, which could
also be an advantage though ...

Our MX are all on the same class C subnet, which belongs to our
institute. The class C is part of a class B which belongs to the
research organization we originally belonged. In our building we were
originally all institutes of such research organization. Now two
institutes are instead part of two other organizations, but we still
share the boundary router. There are access lists on the router, and
port 25 is open only for a few hosts per institute (the MXs).

If anybody from the outside tries to connect by mail to a machine not in
the access list, it hangs. Which should be a deterrent for spammers.

So if we change IP to our MX we should coordinate this with the
(external) manager of the router (which is the drawback).

On the other hand, since we have a further gateway between the building
router and our subnet, we could perhaps have an entire "potential MX
pool" open on the building router, rotate 2 MX in the pool in our DNS,
and at the same time block the unused ones on our gateway.

I'll talk with the boys ...



--
------------------------------------------------------------ ----------
nospam@mi.iasf.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.

Re: mail to deleted domain

On 04/18/08 03:46, LC's No-Spam Newsreading account wrote:
> Our MX already generate a 550 5.7.1 Relaying denied when spammer
> attempt to use them for the old no longer existing domain.

As I would expect.

> Your rotation suggestion has a drawback in our situation, which could
> also be an advantage though ...

???

> Our MX are all on the same class C subnet, which belongs to our
> institute. The class C is part of a class B which belongs to the
> research organization we originally belonged. In our building we were
> originally all institutes of such research organization. Now two
> institutes are instead part of two other organizations, but we still
> share the boundary router. There are access lists on the router, and
> port 25 is open only for a few hosts per institute (the MXs).

Ok. What if you open up port 25 for the pool of IPs? That way you
would not have to have the border router managed for you ever time you
""rotate your MXs.

> If anybody from the outside tries to connect by mail to a machine not
> in the access list, it hangs. Which should be a deterrent for
> spammers.

I personally would like to see a TCP Reset rather than a packet drop,
but "What ever floats your boat.".

> So if we change IP to our MX we should coordinate this with the
> (external) manager of the router (which is the drawback).

Or have the pool of IPs open already. You would only need to change
what the internal systems bind to.

> On the other hand, since we have a further gateway between the
> building router and our subnet, we could perhaps have an entire
> "potential MX pool" open on the building router, rotate 2 MX in the
> pool in our DNS, and at the same time block the unused ones on our
> gateway.

Don't ""block old addresses at the same time that you institute new
ones. Make sure that both the old and new addresses are operable for at
least your DNS TTL, if not longer.

When you are ready to take an IP out of active service, unbind it from
your (main) server and then bind it to a lowly box that has a 550 mailer
that will reject connections to it.

> I'll talk with the boys ...

*nod*

With the IPs pre-allowed in the border router you don't need to involve
external management and you can rotate IPs as you see fit.

Using the internal 550 mailer will allow you to make sure that something
will accept the traffic. Heck if you wanted to you could monitor /
sniff the IP / TCP header to see who is still trying to connect to
something other than what they should be. You never know, this list may
come in handy for building firewalls and / or black lists.



Grant. . . .