-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2008-06-12, at 1631, Robert - elists wrote:
>
> Since I have been playing with Xen virtualization per JMS1's web
> directions
> at
>
> http://www.jms1.net/xen/
>
> I have found it to be quite excellent and interesting.

virtualization doesn't really have any bearing on your question, but
thanks for the plug just the same.


> If we have an example domain like with DNS mx records
>
> example.com IN MX fake1.example.com
> example.com IN MX real1.example.com
> example.com IN MX backup1.example.com
> example.com IN MX fake2.example.com

these "records" are all missing priority numbers. are they all equal
priority, or ordered in some manner?


> to start - What would be the best way to setup a fake or real port 25
> mailserver that all it does is reject the smtp session with the
> appropriate
> error

don't. it's a waste of your resources. it won't make any difference to
a spammer, he dumps a million messages into his queue and goes out for
drinks with the neighbors.


> It is my understanding that an unpatched qmail will not retry other
> MX under
> certain circumstances.

as kyle explained already, if you have non-equal priorities, qmail
will start with the lowest priority and stick with that, unless all of
the hosts with that priority value fail to answer- in that case it
will "step up" and try a hostname which has a higher priority number.

if any hosts with the lower numbered priority do answer but fail to
accept the message, it will not "step up" to the higher priority
records.


> Now, what I am getting at is that I do not want any sending qmail
> server or
> any other smtp server software to get stuck and only try that ip
> address
> forever

then make sure that whatever SMTP service they end up talking to,
accepts the messages.


> Im thinking if using centos5 in Xen subdomains to have backup mail
> servers
> and some fake smtp servers too as a spam fighting tool and for data
> collection towards spam fighting

i don't see how a "fake SMTP server" is supposed to be a spam fighting
tool, unless you want to set up a honeypot and try to gather data on
what spammers are doing- and if you're going to do that, you need to
be willing to dedicate some bandwidth to it, have enough know-how to
analyze the data properly, and take the time to do it. otherwise,
what's the point?

===

the only possible thing i can think of might be this: create a
service, not connected to qmail, but listening on tcp port 25 of an IP
address which is NOT listed as an MX target for any domain name... the
idea being that if not A or MX records point to it, then the only
people who would ever try to connect to it are people conducting port
scans... which means those IPs are some of the ones from which you
don't want to accept email.

it might look like this:

#!/bin/sh
PATH="/usr/bin:/bin:/usr/local/bin"
exec tcpserver -vR -x /etc/tcp/deny.cdb \
x.x.x.x 25 /bin/true 2>&1

where /etc/tcp/deny.cdb is built from the one line ":deny". then watch
the log file for that service, gather the IPs which try to connect,
and add them to a private blacklist. (come to think of it, that's not
a bad idea... maybe i'll do that on my own server.)

as you can see, the only software requirements are daemontools and
ucspi-tcp. it doesn't need qmail, and it certainly doesn't need xen.
you can do this on any normal machine by adding a second IP address to
the existing interface- you don't need a separate box (or a separate
xen session, same thing.)


- --------------------------------------------------------
| John M. Simpson -- KG4ZOW -- Programmer At Large |
| http://www.jms1.net/ <jms1@jms1.net> |
- --------------------------------------------------------
| Hope for America -- http://www.ronpaul2008.com/ |
- --------------------------------------------------------





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhR+1oACgkQEB9RczMG/Pt39ACg/gxjBQLIALn0xAukBorPQTRz
Q68AoN+lIgPYniHVlwvzcLLOSNl0dfCl
=FiJa
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

>
> i don't see how a "fake SMTP server" is supposed to be a spam fighting
> tool, unless you want to set up a honeypot and try to gather data on
> what spammers are doing- and if you're going to do that, you need to
> be willing to dedicate some bandwidth to it, have enough know-how to
> analyze the data properly, and take the time to do it. otherwise,
> what's the point?
>
> ===
>
> the only possible thing i can think of might be this: create a
> service, not connected to qmail, but listening on tcp port 25 of an IP
> address which is NOT listed as an MX target for any domain name... the
> idea being that if not A or MX records point to it, then the only
> people who would ever try to connect to it are people conducting port
> scans... which means those IPs are some of the ones from which you
> don't want to accept email.
>
> it might look like this:
>
> #!/bin/sh
> PATH="/usr/bin:/bin:/usr/local/bin"
> exec tcpserver -vR -x /etc/tcp/deny.cdb \
> x.x.x.x 25 /bin/true 2>&1
>
> where /etc/tcp/deny.cdb is built from the one line ":deny". then watch
> the log file for that service, gather the IPs which try to connect,
> and add them to a private blacklist. (come to think of it, that's not
> a bad idea... maybe i'll do that on my own server.)
>
> as you can see, the only software requirements are daemontools and
> ucspi-tcp. it doesn't need qmail, and it certainly doesn't need xen.
> you can do this on any normal machine by adding a second IP address to
> the existing interface- you don't need a separate box (or a separate
> xen session, same thing.)
>
>
> - --------------------------------------------------------
> | John M. Simpson -- KG4ZOW -- Programmer At Large |

John, Kyle, etc...

Thank you for the replies and thoughtful info.

I am reading and digesting the info you put forth.

Ummmm sorry, I knew I forgot to put in the priority numbers

For this scenario they should not be equal and should be increasing like

example.com IN MX 1 fake1.example.com
example.com IN MX 10 real1.example.com
example.com IN MX 100 backup1.example.com
example.com IN MX 1000 fake2.example.com

my fault.

Now, the primary reason to do this is to gather some data for research and
possible implementation plus send idiot SMTP sessions that go straight for
the lowest priority MX to the floor.

One otjer reason for the question is that I know unpatched qmail has an
issue I don't fully understand (yet will soon thanks to all your replies)
that I want to make sure I address in the high priority fake MX programming.

Plus, there are other broken mail server software and I want to learn more
about their behavior as well if possible.

Being able to have data about who knocks from where. How often. Is the
location currently in RBL or other spammy / virus / spambot / whatever
category among several other things.

I figured doing it with some virtualized machines would be more money
efficient than with the hot and cold rackmount server spares we have laying
around

One person is already doing this yet I don't have admin access to his stuff.
Very early on in his deployment, when we started using his lists and
advertising him on our website, some dns and other list stuff changed and we
had to drop using him for now.

He is a bright thinker and has developed some different color lists based
upon domain and IP address and other behaviors.

Again, I don't have admin access to check all the data he gathers in a human
digestable form for research and thinking.

I know this has been somewhat beat to death in some lists and dropped to the
floor, yet unless I generate and see the data myself, I cannot let it go
quite yet.

Our spam rate to mailbox is very low.

I want it lower if at all possible. There are too many machines out there
knocking on the door that shouldn't be allowed on the property

;-)

- rh


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

The purpose of the
> different MX priorities is to list how far from the final destination any
> give mail host for the domain is located. Since it "costs" more to send a
> message to a server that's "farther" from the final destination (because
> it requires more server and network resources and takes longer),

I think you should think this over. MTA's aren't too concerned with
propagation costs. Having 3 mx's, one in NYC, one on Las Vegas, and
another in Japan, does not alter MX selection. If the first MX is Las
Vegas, and you are in NYC, then your MTA will be shipping the e-mail to
Las Vegas - Even though the MX in NYC is ( 2700 miles ) closer.

It might be nice to have MX's publish their geo-spatial location so an
MTA can make a judicious ( shortest distance ) determination, but I dont
see that happening any time soon.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de