You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by mouss <mo...@netoyen.net> on 2007/08/25 16:51:07 UTC
Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Kai Schaetzl wrote:
> Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200:
>
>
>> I didn't know that a backup MX can lead to more trouble then having just
>> one
>>
>
> Unfortunately, backup MXes attract spammers :-(. You could at least add
> some more backup MXs (that don't exist) on top of that, that may help to
> reduce the influx on the real one.
Using bogus MX records is a very bad idea. Google for bogusmx and for
check_sender_mx_access.
Using a valid MX that always tempfails (either using a 4xx or
blocking/droping packets at IP level or using a non existing IP) is not
yet considered harsh, but if this becomes widely used, we'll find ways
to detect such "poisoned MX" sites. Using a poisoned MX during a spam
strike is ok, but using it all the time and for all client connections
is bad for our resources. Spammers don't pay for resources, they have
enough clients to send to all your MXes.
If you want to stay on the right side, don't break the rules.
Notes:
- If you only tempfail "suspected" clients (faraway countries,
dynamic-like clients, "new" clients), this may be acceptable.
- if you whitelist clients that already sent you (enough) good mail,
this may be acceptable.
(when I say tempfail here, this includes blocking/droping IP packets).
Re: Posioned MX is a bad idea - Challenge
Posted by Kai Schaetzl <ma...@conactive.com>.
Marc Perkel wrote on Sun, 26 Aug 2007 17:36:55 -0700:
> So - who wan's to prove me wrong?
I'm sorry, but all the measures I take are not as restrictive as yours but
still I reject 90% or so of the spam before SA time. So, I don't see why I
should use wrong MXs, it's simply not necessary.
Anyway, I see if I have some time to check this out just for comparison, I
won't use it for longer.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: Posioned MX is a bad idea - Challenge
Posted by Marc Perkel <ma...@perkel.com>.
Kai Schaetzl wrote:
> Marc Perkel wrote on Sat, 25 Aug 2007 13:51:43 -0700:
>
>
>> I'm using it on 1600 domains and I've eliminated all
>> my spam bot spam.
>>
>
> Yeah, yeah, Marc, we know that, you don't have to repeat it each and every
> week :-)
>
> Kai
>
>
While you guy all talk about it - I've done it. It seems to me that if
you ignore reality with your theories that I'm proving wrong you're not
as likely to succeed as listening to someone who has done it.
For all you out there who don't believe that I can do this I can prove
it. Anyone want to put it to the test and see if what I'm saying isn't
true then contact me and you can see it happen yourself. The condition
is that you have to come back here and report the results.
So - who wan's to prove me wrong?
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Kai Schaetzl <ma...@conactive.com>.
Marc Perkel wrote on Sat, 25 Aug 2007 13:51:43 -0700:
> I'm using it on 1600 domains and I've eliminated all
> my spam bot spam.
Yeah, yeah, Marc, we know that, you don't have to repeat it each and every
week :-)
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Marc Perkel <ma...@perkel.com>.
mouss wrote:
> Kai Schaetzl wrote:
>> Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200:
>>
>>
>>> I didn't know that a backup MX can lead to more trouble then having
>>> just one
>>>
>>
>> Unfortunately, backup MXes attract spammers :-(. You could at least
>> add some more backup MXs (that don't exist) on top of that, that may
>> help to reduce the influx on the real one.
>
>
> Using bogus MX records is a very bad idea. Google for bogusmx and for
> check_sender_mx_access.
>
> Using a valid MX that always tempfails (either using a 4xx or
> blocking/droping packets at IP level or using a non existing IP) is
> not yet considered harsh, but if this becomes widely used, we'll find
> ways to detect such "poisoned MX" sites. Using a poisoned MX during a
> spam strike is ok, but using it all the time and for all client
> connections is bad for our resources. Spammers don't pay for
> resources, they have enough clients to send to all your MXes.
>
> If you want to stay on the right side, don't break the rules.
>
> Notes:
> - If you only tempfail "suspected" clients (faraway countries,
> dynamic-like clients, "new" clients), this may be acceptable.
> - if you whitelist clients that already sent you (enough) good mail,
> this may be acceptable.
>
> (when I say tempfail here, this includes blocking/droping IP packets).
>
>
Works great for me. I'm using it on 1600 domains and I've eliminated all
my spam bot spam.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by mouss <mo...@netoyen.net>.
Kai Schaetzl wrote:
> Mouss wrote on Sat, 25 Aug 2007 16:51:07 +0200:
>
>
>> check_sender_mx_access.
>>
>
> this won't detect MX hostnames resolving to valid but not reachable IP
> no.s.
>
sure, which may lead to the creation of a dedicated blacklist.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Kai Schaetzl <ma...@conactive.com>.
Mouss wrote on Sat, 25 Aug 2007 16:51:07 +0200:
> check_sender_mx_access.
this won't detect MX hostnames resolving to valid but not reachable IP
no.s.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by mouss <mo...@netoyen.net>.
John Rudd wrote:
> mouss wrote:
>> Kai Schaetzl wrote:
>>> Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200:
>>>
>>>
>>>> I didn't know that a backup MX can lead to more trouble then having
>>>> just one
>>>>
>>>
>>> Unfortunately, backup MXes attract spammers :-(. You could at least
>>> add some more backup MXs (that don't exist) on top of that, that may
>>> help to reduce the influx on the real one.
>>
>>
>> Using bogus MX records is a very bad idea. Google for bogusmx and for
>> check_sender_mx_access.
>
> So, how exactly does "using bogus MX records" differ from "nolisting"?
Because if you set the MX to point to 10.1.2.3 and if I don't reject
your mail, then replies may go to a private MTA in my network.
>
>
> Because, the latter does seem to generally be thought of as a rather
> good anti-spam technique (it only catches spammers and a few very odd
> non-RFC compliant MTAs that don't check all MX records).
It causes an additional connection attempts. so it's not completely
"safe". if you can redirect "known good" clients to a real MTA (with a
NAT redirect for example), then it's better.
> If you have a one or more valid MX records, and one or more
> non-responsive MX records, then only non-RFC complaint MTAs will have
> a problem with that. We shouldn't care about the cases which break
> non-RFC compliant MTAs, as they're only used by morons.
By bogus MX, I don't mean a non-responsive MX. I really mean the record
is bogus and can be seen without any SMTP connection. An MX that points
to private IP or unallocated IP space is such one, and I don't ignore
this, because it indicates one of the following
- the site does not want to receive mail (there are better ways,
but...). if the address is used, then it is probably a forgery.
- a miscreant (spammer, cracker, ...) is trying to do something nasty. I
don't need to know what he is trying to achieve.
- a DNS misconfiguration. but this is a big one, so the site may have
other problems. better to block him so that he does little harm.
- a stupid registrar giving silly replies for parked domains.
If you get a message claiming to be from <Be...@bmla.com>, you can
reject it now. no point to check the content.
>
>
> Further, how does check_sender_mx_access differ from Sender Address
> Verification (SAV)? (where SAV is an INCREDIBLY bad idea, and a blight
> upon the internet)
check_sender_mx_access compares the MX with a list of records you put in
a file. for each record, you can decide to reject, tempfail, greylist,
or whatever. This involves no smtp probe.
>
> (meaning: if check_sender_mx_access is just the postfix name for SAV,
> then we not only shouldn't avoid techniques that break
> check_sender_mx_access, we should all openly adopt techniques that
> break check_sender_mx_access as a means to further remove the SAV
> blight from the internet)
under postfix, SAV is reject_unverified_sender. but this is not
recommended as you say.
>
>
>
>
>
>
>
Whitelist for misconfigured mail servers (was: Posioned MX is a bad
idea)
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Wednesday, August 29, 2007 1:58 AM -0400 Aaron Wolfe
<aa...@gmail.com> wrote:
> The first 24 hours seemed promising. However today (tues) we have two
> false positives, including one of their banks (!) and a small business
> that is their long time customer.
>
> It's scary that a bank has such a broken config, but its a reality.
> Unfortunately, there are still too many bad admins/RFC ignorant
> firewalls/whatever out there for bogus MXs to be a practical solution for
> me. Sure, if we all used it then they'd have to clean up their acts.. but
> then the spammers would obviously just implement proper behavior in their
> next bot version. I just don't see this as a solution that can work.
Perhaps we need a whitelist similar to rfc-ignorant that lists legitimate
sites that are misconfigured and broken. Being on the site would be an
indication of cluelessness, not evil, so there'd still be an incentive to
fix the problem. Running popular but broken software (like known-bad
versions of Exchange or Notes) would result in specific error codes or bits
in the result.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Aaron Wolfe <aa...@gmail.com>.
On 8/27/07, Marc Perkel <ma...@perkel.com> wrote:
>
>
>
> Andy Sutton wrote:
>
> On Mon, 2007-08-27 at 12:59 -0700, Marc Perkel wrote:
>
> I've not run into a single instance where a legit server only tried
> the lowest MX. However, if I did there's a simple solution. If the
> fake lowest MX points to an IP on the same server as the working MX
> then you can use iptables to block port 25 on all IP addresses EXCEPT
> for the one broken server. That would fix the problem.
>
> I think the question is how you would identify a FP occurred, short of a
> client screaming?
>
>
> Clients screaming is that way the false positives are usually identified.
> I'm filtering 1600 domains and I've been doing this for almost a year and
> have yet to get a single report of a false positive. And when I screw up I
> usually hear about it.
>
> All I can say is - it works for me. If you want to try something safer
> create some fake higher numbered MX records and return 421 errors on them
> and you'll get rid of about 1/3 of your botnet spam. And you'l be able to
> see in your logs how many hits you get.
>
> The only way to determine if this works or not is to try it.
>
>
I have tried bogus MXes before and had too many false positives to possibly
deal with. However after the repeated claims of zero FP on your large
installation, I decided to give it another try. It's been a couple years
since my last try, and then I only used a fake 1st pref MX, not a fake last
MX as well.
Sunday evening I tried it on a single domain of one very tolerant and
friendly client. I added one bogus lower MX and one higher, both IPs in the
same block as their actual mail server that were unused.
The first 24 hours seemed promising. However today (tues) we have two false
positives, including one of their banks (!) and a small business that is
their long time customer.
It's scary that a bank has such a broken config, but its a reality.
Unfortunately, there are still too many bad admins/RFC ignorant
firewalls/whatever out there for bogus MXs to be a practical solution for
me. Sure, if we all used it then they'd have to clean up their acts.. but
then the spammers would obviously just implement proper behavior in their
next bot version. I just don't see this as a solution that can work.
I don't know what "1600 domains" means. Most people talk in terms of
messages/day, number of mailboxes, or some other meaningful measurement.
Just guessing that maybe a "domain" equals average 50 users... I cannot
imagine how you're not getting flooded with complaints. I tried it with a
single small domain (less than 30 mailboxes) and didn't make it 2 business
days.
We'd all like to find that magic button to stop spam, but this aint it.
-Aaron
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by DAve <da...@pixelhammer.com>.
Marc Perkel wrote:
>
>
> Kai Schaetzl wrote:
>> Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 +0000 (UTC):
>>
>>
>>> What happens if the remote MX is within a private IP range? Should I
>>> accept that message, knowing fully, the recipient would never be able to
>>> respond?
>>>
>>
>> This feature looks fine on first glance, but on second I think this is
>> dangerous if it gets applied to all MX positions. For instance the two MX
>> setup where one machine is behind a firewall and a gateway machine is first
>> MX and forwards to the machine behind the firewall. This is an accepted
>> setup. Couldn't I achieve the same thing without a firewall? The first MX
>> gets another IP from a private range and the second is on private only. So,
>> it's not reachable from outside, but the first MX can forward to it.
>>
>> "backup MXs (that don't exist)" doesn't mean a private range. You simply
>> set it to an IP that doesn't have SMTP or one that points to nirvana, but
>> still a valid public IP address.
>> I don't use that technique and don't think I will need to use it in the
>> near future, but I can't see anything bad in it, sorry. As John says only
>> spammers or broken MTAs should have a problem with that.
>> I also agree on SAV with John, it's almost as worse as challenge-response
>> mechanisms.
>>
>> Kai
>>
>>
>
> If you have one MX and you create a fake low MX and a fake high MX (or
> many fake high MX) about 75% to 95% of your spam goes away. It's that
> simple.
>
I've been following this discussion across all the threads. Mark's ideas
are certainly out of the box, and some have merit, maybe all have merit.
But I can report that depending on the client, some of the ideas would
get me fired within a week, they would certainly get my client's howling
into the phone. This is one such idea.
While this idea sounds good, and it may work for you, it won't work for
us. Unfortunately there are an abundant number of what I like to call
"shrink wrap admins". They convince the PHB they can save money, save
time, do cool things with their Blackberrys, if they manage their own
mail server in house. So they pull a beige PIII out from under a desk,
open the MSE box, insert the CD, and before the shrink wrap stops
un-wadding itself on the floor they are already goofing up mail to my
servers (my clients). Of course, it's my fault when that happens 8^(
Examples, though they may not be relevant to the discussion, they are
examples of why we cannot block mail using some of the more common or
creative techniques.
1) I see thousands of corporate email connections a day from
<bo...@underdesk.local>, bad helo is not always a good indicator
of a bot/spam/zombie.
2) Many of our client's do a lot of email with businesses that have a
mail server running on a static cable IP that still has a dynamic
reverse DNS. RDNS is not a good indicator of the legitimacy of a message.
3) We also have plenty of entries in our whitelist for greylisting,
because the other server can't handle a temp fail.
4) I'll say it again though a lot of people have told me I am crazy, I
see instances often of MS caching DNS for weeks at a time. The stupid
server will only try to send to one IP, over, and over, and over. Some
times that IP is only one of our MX's. We finally call them and insist
they reboot their server. Then wala, it works. I dread taking down a MX
for maint, even when the DNS has been expired for a month in advance.
I hate spammers, hate 'em, hate 'em, hate 'em. They should be run out of
town on a pole. A pole carefully located with a great deal of force.
DAve
--
Three years now I've asked Google why they don't have a
logo change for Memorial Day. Why do they choose to do logos
for other non-international holidays, but nothing for
Veterans?
Maybe they forgot who made that choice possible.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL
trouble]
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Sunday, August 26, 2007 5:31 PM -0700 Marc Perkel <ma...@perkel.com>
wrote:
> If you have one MX and you create a fake low MX and a fake high MX (or
> many fake high MX) about 75% to 95% of your spam goes away. It's that
> simple.
I can do better. If I unplug my network cable, 100% of my spam goes away! :D
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Steven Kurylo <st...@aviawest.com>.
>
>>> If you have one MX and you create a fake low MX and a fake high MX (or
>>> many fake high MX) about 75% to 95% of your spam goes away. It's that
>>> simple.
>>>
>> How do you deal with the false-positives, legit servers that are blocked
>> by this configuration?
>>
> There aren't any false positives. That's what is so great about this
> trick.
How can you prove it?
I keep a copy of every single message I greylist or blackhole. It makes
it trivial to prove I didn't drop a really important message.
If I don't even know that connection attempts are failing, how can I
claim I haven't lost anything?
As other people have mentioned, there are MXs which don't retry properly.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by mouss <mo...@netoyen.net>.
David B Funk wrote:
> I guess I didn't make my question clear enough;
> How do you deal with mail from legit servers that are blocked by this
> configuration?
> (IE servers that for what ever reason will ONLY try the first mx, thus
> failing to get past your fake MX.)
>
well, rfc mandates that they try at least 2 MX's. if they fail to try 2,
they can fail to try 1. Imagine you have a backup MX, and the primary is
down for 6 days...
Please note that I am not suggesting that the use of fake MXes is good.
> I ask this because a few years ago I had a mail setup that produced
> something functionally equivalent (first MX had a ipfilter that returned
> a tcp-reset for a large IP block to force them to fall back to my
> secondary MXs to reduce load on the first).
> Some of our users complained about missing messages from a local city
> government office. Turns out that their server (which was OK) was routing
> thru an 'intelligent' firewall and the brain-damaged firewall was only
> letting the mail send out to the first MX of the destination address.
>
> The mail server people had a legit configuration, it was the hardware
> deployed by their network people which was the cause of the problem
> and they were not willing to turn off their firewall. Their attitude
> was "it works for everybody else, so your system must be broken".
>
if you are forced to accept their mail, whitelist them. if you don't,
they may get trapped somewhere else and you'll have similar issues.
>
> Maybe -you- can tell your customers "Tough, I won't let you get mail from
> senders with broken configurations" but when one of our departmental
> execs calls and says "I'm not getting mail from government office Y"
> my saying "Tough" is -not- an option. ;(
>
If you can show the cost of modifying your config to accept mail from
the gov office, and your mgmt finds this ok, then there is no problem.
don't fight against your users/employers/...
> I could (in my massive amounts of spare time) keep poking more holes
> in the filter to pass message from brain-damaged systems, but just
> finding them in the first place is a head-ache.
>
I always asked users before imposing any check. I generally explain the
consequences of the check (probability of blocking legitimate mail, ...
etc). if they want the "spam lovers" policy, they get it. if "hit the
delete button" is ok for them, I see no problem. I've then got many
people sick of spam asking to get moved to a stronger policy...
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Marc Perkel <ma...@perkel.com>.
Andy Sutton wrote:
> On Mon, 2007-08-27 at 12:59 -0700, Marc Perkel wrote:
>
>> I've not run into a single instance where a legit server only tried
>> the lowest MX. However, if I did there's a simple solution. If the
>> fake lowest MX points to an IP on the same server as the working MX
>> then you can use iptables to block port 25 on all IP addresses EXCEPT
>> for the one broken server. That would fix the problem.
>>
>
> I think the question is how you would identify a FP occurred, short of a
> client screaming?
>
Clients screaming is that way the false positives are usually
identified. I'm filtering 1600 domains and I've been doing this for
almost a year and have yet to get a single report of a false positive.
And when I screw up I usually hear about it.
All I can say is - it works for me. If you want to try something safer
create some fake higher numbered MX records and return 421 errors on
them and you'll get rid of about 1/3 of your botnet spam. And you'l be
able to see in your logs how many hits you get.
The only way to determine if this works or not is to try it.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL
trouble]
Posted by Andy Sutton <ne...@pessimists.net>.
On Mon, 2007-08-27 at 12:59 -0700, Marc Perkel wrote:
> I've not run into a single instance where a legit server only tried
> the lowest MX. However, if I did there's a simple solution. If the
> fake lowest MX points to an IP on the same server as the working MX
> then you can use iptables to block port 25 on all IP addresses EXCEPT
> for the one broken server. That would fix the problem.
I think the question is how you would identify a FP occurred, short of a
client screaming?
--
- Andy
The test of courage comes when we are in the minority. The test of
tolerance comes when we are in the majority.
- Ralph W. Sockman
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Mon, 27 Aug 2007, Marc Perkel wrote:
> David B Funk wrote:
> > On Mon, 27 Aug 2007, Marc Perkel wrote:
> >
> >> There aren't any false positives. That's what is so great about this trick.
> >>
> >
> > I guess I didn't make my question clear enough;
> > How do you deal with mail from legit servers that are blocked by this
> > configuration?
> > (IE servers that for what ever reason will ONLY try the first mx, thus
> > failing to get past your fake MX.)
[snip..]
> >
> > I could (in my massive amounts of spare time) keep poking more holes
> > in the filter to pass message from brain-damaged systems, but just
> > finding them in the first place is a head-ache.
> >
>
> I've not run into a single instance where a legit server only tried the
> lowest MX. However, if I did there's a simple solution. If the fake
> lowest MX points to an IP on the same server as the working MX then you
> can use iptables to block port 25 on all IP addresses EXCEPT for the one
> broken server. That would fix the problem.
So in reality your "There aren't any false positives" is actually
"I've not run into a single instance"
So either you have not yet run into the kind of buzz-saw that I hit
or those that you've blocked have not been able to contact you. ;)
Lucky for you and maybe your customers.
Yes, as I said "I could keep poking more holes ..." -BUT-
it was a pain to figure out exactly what was going on and it is
a time waster (lots of finger-pointing, etc).
So much for your "all you need to do... and you're done" anti-spam
solution.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Marc Perkel <ma...@perkel.com>.
David B Funk wrote:
> On Mon, 27 Aug 2007, Marc Perkel wrote:
>
>
>> David B Funk wrote:
>>
>>> On Sun, 26 Aug 2007, Marc Perkel wrote:
>>>
>>>
>>>> If you have one MX and you create a fake low MX and a fake high MX (or
>>>> many fake high MX) about 75% to 95% of your spam goes away. It's that
>>>> simple.
>>>>
>>> How do you deal with the false-positives, legit servers that are blocked
>>> by this configuration?
>>>
>> There aren't any false positives. That's what is so great about this trick.
>>
>
> I guess I didn't make my question clear enough;
> How do you deal with mail from legit servers that are blocked by this
> configuration?
> (IE servers that for what ever reason will ONLY try the first mx, thus
> failing to get past your fake MX.)
>
> I ask this because a few years ago I had a mail setup that produced
> something functionally equivalent (first MX had a ipfilter that returned
> a tcp-reset for a large IP block to force them to fall back to my
> secondary MXs to reduce load on the first).
> Some of our users complained about missing messages from a local city
> government office. Turns out that their server (which was OK) was routing
> thru an 'intelligent' firewall and the brain-damaged firewall was only
> letting the mail send out to the first MX of the destination address.
>
> The mail server people had a legit configuration, it was the hardware
> deployed by their network people which was the cause of the problem
> and they were not willing to turn off their firewall. Their attitude
> was "it works for everybody else, so your system must be broken".
>
>
> Maybe -you- can tell your customers "Tough, I won't let you get mail from
> senders with broken configurations" but when one of our departmental
> execs calls and says "I'm not getting mail from government office Y"
> my saying "Tough" is -not- an option. ;(
>
> I could (in my massive amounts of spare time) keep poking more holes
> in the filter to pass message from brain-damaged systems, but just
> finding them in the first place is a head-ache.
>
I've not run into a single instance where a legit server only tried the
lowest MX. However, if I did there's a simple solution. If the fake
lowest MX points to an IP on the same server as the working MX then you
can use iptables to block port 25 on all IP addresses EXCEPT for the one
broken server. That would fix the problem.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Mon, 27 Aug 2007, Marc Perkel wrote:
> David B Funk wrote:
> > On Sun, 26 Aug 2007, Marc Perkel wrote:
> >
> >> If you have one MX and you create a fake low MX and a fake high MX (or
> >> many fake high MX) about 75% to 95% of your spam goes away. It's that
> >> simple.
> >
> > How do you deal with the false-positives, legit servers that are blocked
> > by this configuration?
>
> There aren't any false positives. That's what is so great about this trick.
I guess I didn't make my question clear enough;
How do you deal with mail from legit servers that are blocked by this
configuration?
(IE servers that for what ever reason will ONLY try the first mx, thus
failing to get past your fake MX.)
I ask this because a few years ago I had a mail setup that produced
something functionally equivalent (first MX had a ipfilter that returned
a tcp-reset for a large IP block to force them to fall back to my
secondary MXs to reduce load on the first).
Some of our users complained about missing messages from a local city
government office. Turns out that their server (which was OK) was routing
thru an 'intelligent' firewall and the brain-damaged firewall was only
letting the mail send out to the first MX of the destination address.
The mail server people had a legit configuration, it was the hardware
deployed by their network people which was the cause of the problem
and they were not willing to turn off their firewall. Their attitude
was "it works for everybody else, so your system must be broken".
Maybe -you- can tell your customers "Tough, I won't let you get mail from
senders with broken configurations" but when one of our departmental
execs calls and says "I'm not getting mail from government office Y"
my saying "Tough" is -not- an option. ;(
I could (in my massive amounts of spare time) keep poking more holes
in the filter to pass message from brain-damaged systems, but just
finding them in the first place is a head-ache.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Marc Perkel <ma...@perkel.com>.
David B Funk wrote:
> On Sun, 26 Aug 2007, Marc Perkel wrote:
>
>
>> If you have one MX and you create a fake low MX and a fake high MX (or
>> many fake high MX) about 75% to 95% of your spam goes away. It's that
>> simple.
>>
>
> How do you deal with the false-positives, legit servers that are blocked
> by this configuration?
>
>
>
There aren't any false positives. That's what is so great about this trick.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Sun, 26 Aug 2007, Marc Perkel wrote:
> If you have one MX and you create a fake low MX and a fake high MX (or
> many fake high MX) about 75% to 95% of your spam goes away. It's that
> simple.
How do you deal with the false-positives, legit servers that are blocked
by this configuration?
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Marc Perkel <ma...@perkel.com>.
Kai Schaetzl wrote:
> Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 +0000 (UTC):
>
>
>> What happens if the remote MX is within a private IP range? Should I
>> accept that message, knowing fully, the recipient would never be able to
>> respond?
>>
>
> This feature looks fine on first glance, but on second I think this is
> dangerous if it gets applied to all MX positions. For instance the two MX
> setup where one machine is behind a firewall and a gateway machine is first
> MX and forwards to the machine behind the firewall. This is an accepted
> setup. Couldn't I achieve the same thing without a firewall? The first MX
> gets another IP from a private range and the second is on private only. So,
> it's not reachable from outside, but the first MX can forward to it.
>
> "backup MXs (that don't exist)" doesn't mean a private range. You simply
> set it to an IP that doesn't have SMTP or one that points to nirvana, but
> still a valid public IP address.
> I don't use that technique and don't think I will need to use it in the
> near future, but I can't see anything bad in it, sorry. As John says only
> spammers or broken MTAs should have a problem with that.
> I also agree on SAV with John, it's almost as worse as challenge-response
> mechanisms.
>
> Kai
>
>
If you have one MX and you create a fake low MX and a fake high MX (or
many fake high MX) about 75% to 95% of your spam goes away. It's that
simple.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by mouss <mo...@netoyen.net>.
Kai Schaetzl wrote:
> Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 +0000 (UTC):
>
>
>> What happens if the remote MX is within a private IP range? Should I
>> accept that message, knowing fully, the recipient would never be able to
>> respond?
>>
>
> This feature looks fine on first glance, but on second I think this is
> dangerous if it gets applied to all MX positions. For instance the two MX
> setup where one machine is behind a firewall and a gateway machine is first
> MX and forwards to the machine behind the firewall. This is an accepted
> setup. Couldn't I achieve the same thing without a firewall? The first MX
> gets another IP from a private range and the second is on private only. So,
> it's not reachable from outside, but the first MX can forward to it.
>
- There is no need for MX in local networks. most MTAs support explicit
transport/routing configurations.
- you can still use multiple DNS servers (or views)
- you can exclude your own domains from whatever check you want
Allowing an outsider to access one of your private boxes he was not
supposed to access is generally considered a hole. consider this:
- one of your users is running an smtp server on his box, IP=10.1.2.3
- an outsider buys a domain, and sets his MX to 10.1.2.3
- he sends you mail using that domain in the sender address
- for some reason, the mail gets a reply (real reply by luser, out of
quota/disk, system error, vacation, MUA confirmation ... whatever). your
MTA will send the reply to 10.1.2.3
so the outsider has managed to reach the smtp server on 10.1.2.3. That
smtp server may be an unprotected/unpatched/misconfigured
exchange/whatever, a trojan, ...
Yes, you can track all internal smtp servers, all MUAs that send
confirmations/..., all auto-responders, ... all traojans, ... but why
would you accept mail from an unkown domain claiming to have an MX that
is unreachable from the public network?
More generally, except under known circumstances, there is no reason to
accept mail with a sender address that is unreachable. If they don't
wanna be reached, they should use the empty address (<>).
Here is a domain used as sender in a recent spam:
$ host -t mx yheweathernetwork.com
yheweathernetwork.com mail is handled by 0 *.mx.*.
> "backup MXs (that don't exist)" doesn't mean a private range. You simply
> set it to an IP that doesn't have SMTP or one that points to nirvana, but
> still a valid public IP address.
>
This is not what I call a "bogus MX". but this may still be detected
after some time (well, it will be detected that you have an MX that did
not work over a long period of time). not sure whether spammers will
list these and avoid them.
You may want to randomly "ignore" clients (send a TCP RST to be nice to
legitimate MTAs). But if you use a real MTA, you should also "whitelist"
known good clients.
> I don't use that technique and don't think I will need to use it in the
> near future, but I can't see anything bad in it, sorry. As John says only
> spammers or broken MTAs should have a problem with that.
> I also agree on SAV with John, it's almost as worse as challenge-response
> mechanisms.
>
> Kai
>
>
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Kai Schaetzl <ma...@conactive.com>.
Kenneth Porter wrote on Sun, 26 Aug 2007 12:39:44 -0700:
> Publishing a private address in a public MX record can lose mail. If the
> outside sender is using the same private address for his own mail server,
> then that server will either see a routing loop (since it's being told by
> MX that it's responsible for that mail) or it will reject the mail because
> it's not configured to forward or deliver for that domain.
You are right, not advisable. Was just imagining up a case where the
check_sender_mx_access might cause a problem. I see that is not realistic.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL
trouble]
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Sunday, August 26, 2007 11:31 AM +0200 Kai Schaetzl
<ma...@conactive.com> wrote:
> For instance the two MX
> setup where one machine is behind a firewall and a gateway machine is
> first MX and forwards to the machine behind the firewall. This is an
> accepted setup. Couldn't I achieve the same thing without a firewall?
> The first MX gets another IP from a private range and the second is on
> private only. So, it's not reachable from outside, but the first MX can
> forward to it.
Publishing a private address in a public MX record can lose mail. If the
outside sender is using the same private address for his own mail server,
then that server will either see a routing loop (since it's being told by
MX that it's responsible for that mail) or it will reject the mail because
it's not configured to forward or deliver for that domain.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Kai Schaetzl <ma...@conactive.com>.
Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 +0000 (UTC):
> What happens if the remote MX is within a private IP range? Should I
> accept that message, knowing fully, the recipient would never be able to
> respond?
This feature looks fine on first glance, but on second I think this is
dangerous if it gets applied to all MX positions. For instance the two MX
setup where one machine is behind a firewall and a gateway machine is first
MX and forwards to the machine behind the firewall. This is an accepted
setup. Couldn't I achieve the same thing without a firewall? The first MX
gets another IP from a private range and the second is on private only. So,
it's not reachable from outside, but the first MX can forward to it.
"backup MXs (that don't exist)" doesn't mean a private range. You simply
set it to an IP that doesn't have SMTP or one that points to nirvana, but
still a valid public IP address.
I don't use that technique and don't think I will need to use it in the
near future, but I can't see anything bad in it, sorry. As John says only
spammers or broken MTAs should have a problem with that.
I also agree on SAV with John, it's almost as worse as challenge-response
mechanisms.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Duane Hill <d....@yournetplus.com>.
On Sat, 25 Aug 2007 at 13:42 -0700, jrudd@ucsc.edu confabulated:
> Duane Hill wrote:
>> On Sat, 25 Aug 2007 at 13:08 -0700, jrudd@ucsc.edu confabulated:
>>
>>> Further, how does check_sender_mx_access differ from Sender Address
>>> Verification (SAV)? (where SAV is an INCREDIBLY bad idea, and a blight
>>> upon the internet)
>>>
>>> (meaning: if check_sender_mx_access is just the postfix name for SAV, then
>>> we not only shouldn't avoid techniques that break check_sender_mx_access,
>>> we should all openly adopt techniques that break check_sender_mx_access as
>>> a means to further remove the SAV blight from the internet)
>>
>> Unfortunately, John, it's not SAV. It's an access table used against the MX
>> hosts for the MAIL FROM.
>
> So, it's a table stored in the local postfix instance, that says which
> addresses are valid mail-froms?
No. Here's from the docs:
"Search the specified access(5) database for the MX hosts for the MAIL
FROM address, and execute the corresponding action."
> How does that collide with a remote MX being bogus? It seems like the
> problem isn't that the remote MX is bogus, the problem would be that the
> local postfix admin is entering a value into said table.
What happens if the remote MX is within a private IP range? Should I
accept that message, knowing fully, the recipient would never be able to
respond?
-------
_|_
(_| |
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by John Rudd <jr...@ucsc.edu>.
Duane Hill wrote:
> On Sat, 25 Aug 2007 at 13:08 -0700, jrudd@ucsc.edu confabulated:
>
>> Further, how does check_sender_mx_access differ from Sender Address
>> Verification (SAV)? (where SAV is an INCREDIBLY bad idea, and a blight
>> upon the internet)
>>
>> (meaning: if check_sender_mx_access is just the postfix name for SAV,
>> then we not only shouldn't avoid techniques that break
>> check_sender_mx_access, we should all openly adopt techniques that
>> break check_sender_mx_access as a means to further remove the SAV
>> blight from the internet)
>
> Unfortunately, John, it's not SAV. It's an access table used against the
> MX hosts for the MAIL FROM.
So, it's a table stored in the local postfix instance, that says which
addresses are valid mail-froms?
How does that collide with a remote MX being bogus? It seems like the
problem isn't that the remote MX is bogus, the problem would be that the
local postfix admin is entering a value into said table.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Duane Hill <d....@yournetplus.com>.
On Sat, 25 Aug 2007 at 13:08 -0700, jrudd@ucsc.edu confabulated:
> Further, how does check_sender_mx_access differ from Sender Address
> Verification (SAV)? (where SAV is an INCREDIBLY bad idea, and a blight upon
> the internet)
>
> (meaning: if check_sender_mx_access is just the postfix name for SAV, then we
> not only shouldn't avoid techniques that break check_sender_mx_access, we
> should all openly adopt techniques that break check_sender_mx_access as a
> means to further remove the SAV blight from the internet)
Unfortunately, John, it's not SAV. It's an access table used against the
MX hosts for the MAIL FROM.
-------
_|_
(_| |
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Tony Finch <do...@dotat.at>.
On Sun, 26 Aug 2007, Dave Pooser wrote:
>
> Except that I can verify addresses after checking blacklists, RDNS and other
> checks to make dictionary attacks harder on the spammers. It may be possible
> to put ACLs on VRFY in Exim, but I haven't looked into it.
I don't believe dictionary attacks are a problem, except for the extra
load they cause. The validity of normal email addresses is public
information, so a dictionary attack doesn't tell the spammer anything they
can't find out another way. If you want to create secret email addresses
then you'll have to incorporate enough randomness that a dictionary attack
will fail - relying on obscurity or 100% blacklist coverage isn't enough.
Tony.
--
f.a.n.finch <do...@dotat.at> http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL
trouble]
Posted by Dave Pooser <da...@pooserville.com>.
> On Sat, 25 Aug 2007, Dave Pooser wrote:
>>
>> So do you run your servers with VRFY enabled?
>
> Yes. If you are verifying addresses at RCPT time, which you must to avoid
> spam blowback, then there's no point disabling VRFY.
Except that I can verify addresses after checking blacklists, RDNS and other
checks to make dictionary attacks harder on the spammers. It may be possible
to put ACLs on VRFY in Exim, but I haven't looked into it.
My larger point: If another server operator has disabled VRFY on his server,
by what right do I attempt to circumvent his policy decision by using sender
address verification?
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"In our family, happy usually involves gunfire and at least
two patrol cars showing up." --SomethingPositive.net
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Tony Finch <do...@dotat.at>.
On Sat, 25 Aug 2007, Dave Pooser wrote:
>
> So do you run your servers with VRFY enabled?
Yes. If you are verifying addresses at RCPT time, which you must to avoid
spam blowback, then there's no point disabling VRFY.
Tony.
--
f.a.n.finch <do...@dotat.at> http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL
trouble]
Posted by Dave Pooser <da...@pooserville.com>.
> If
> someone is sending email using one of my domains I want people verifying
> the sender addresses.
So do you run your servers with VRFY enabled?
--
Dave Pooser
Cat-Herder-in-Chief
Pooserville.com
"Jon, the CIA's credibility has never been lower. Crazy people no longer
believe the CIA is implanting a chip in their heads to listen to their
dreams. They just don't think they can pull it off. It's a sad day for
America when even our paranoid schizophrenics realize they don't need to
wear the aluminum foil hats anymore." -- Ed Helms, "The Daily Show"
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Kai Schaetzl <ma...@conactive.com>.
Marc Perkel wrote on Sat, 25 Aug 2007 15:33:46 -0700:
> You have to do SAV right. I
It doesn't matter what you do to reduce the load of SAV, this doesn't
eliminate the basic problem with SAV at all.
> And - more importantly - spammers don't use my donains to spam others
> because my servers are SAV friendly and spammer prefer using domains
> that either pass everything.
I doubt this matters at all. I have a client whose domain got so heavily
joe-jobbed years ago that we had to take his domain from dns for years.
Trying after two or three years of non-resolution if it is usable again
still drove in several ten-thousand non-delivery notices within a day. In
other words: spammers don't care.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: Posioned MX is a bad idea
Posted by Nikolay Shopik <sh...@inblock.ru>.
On 8/26/2007 11:36 PM, John D. Hardin wrote:
> On Sun, 26 Aug 2007, Nikolay Shopik wrote:
>
>> Just parse received headers in attached message in backscatter.
>> You can easily see what this message sent not by your server and
>> you can reject such backscatter, because you never sent such
>> messages.
>
> Not true any longer. The joe job I've been suffering from the last
> month has forged Received: headers that makes the spam appear to have
> been sent from my MX to the bot that actually originated it. After
> all, how hard is it to look up the MX for the domain you're forging as
> the sender?
>
> I you want to filter you'd need to keep a history of all the
> Message-ID values your MTA had processed and compare to that.
And what else, you can announce your MTA not as it named in DNS. So you
announce your system as mta.example.com but all DNS records claims what
its mx.example.com.
MX RR = mx.example.com -> 1.2.3.4
CNAME RR = mta.example.com -> mx.example.com (just for safety)
Re: Posioned MX is a bad idea
Posted by Nikolay Shopik <sh...@inblock.ru>.
On 8/26/2007 11:36 PM, John D. Hardin wrote:
> On Sun, 26 Aug 2007, Nikolay Shopik wrote:
>
>> Just parse received headers in attached message in backscatter.
>> You can easily see what this message sent not by your server and
>> you can reject such backscatter, because you never sent such
>> messages.
>
> Not true any longer. The joe job I've been suffering from the last
> month has forged Received: headers that makes the spam appear to have
> been sent from my MX to the bot that actually originated it. After
> all, how hard is it to look up the MX for the domain you're forging as
> the sender?
>
> I you want to filter you'd need to keep a history of all the
> Message-ID values your MTA had processed and compare to that.
>
Yeah Message-ID is works too. Lookup for ip address as well in received
header.
Re: Posioned MX is a bad idea
Posted by "John D. Hardin" <jh...@impsec.org>.
On Sun, 26 Aug 2007, Nikolay Shopik wrote:
> Just parse received headers in attached message in backscatter.
> You can easily see what this message sent not by your server and
> you can reject such backscatter, because you never sent such
> messages.
Not true any longer. The joe job I've been suffering from the last
month has forged Received: headers that makes the spam appear to have
been sent from my MX to the bot that actually originated it. After
all, how hard is it to look up the MX for the domain you're forging as
the sender?
I you want to filter you'd need to keep a history of all the
Message-ID values your MTA had processed and compare to that.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
USMC Rules of Gunfighting #20: The faster you finish the fight,
the less shot you will get.
-----------------------------------------------------------------------
2 days until Exercise Your Rights day
Re: Posioned MX is a bad idea
Posted by Nikolay Shopik <sh...@inblock.ru>.
On 8/26/2007 4:57 AM, Rob McEwen wrote:
> Marc,
>
> Overall good answers... but about six months ago, one of my users was
> joe jobbed in "biblical proportions"... in this case, the spammer chose
> this one "real" address and that spammer must have either sent the bots
> this info, or pre-programmed the bots. When the spam run started, this
> particular user was then the "from" address in many spams sent from many
> different IPs and, as a result, he received hundreds of incoming
> outscatter per day (The vast majority of which were were blocked by my
> spam filter). The outscatter often showed the headers of the original
> spam and from that I was able to determine that this was originating
> from an army of bots... NOT merely one IP. Because the outscatter I saw
> was mail returned from that fraction of a percent of mail servers which
> are misconfigured, the actual spam run must have been in the 10s of
> thousands... or even millions per day.
>
> Combine this with the fact that I highly doubt that anyone else's
> implemenation of SAV would be as surgically targetted as yours, no
> matter how hard they try, and my mail server might have been brought to
> its knees had all the major ISPs used SAV at that time!
>
> It would be interesting if there were a central "clearinghouse" server
> which could do the SAV one time (with each new request not yet in the
> DB) and then cache the results for everyone else to do some kind of DNS
> query to this one server. But this is not feasible because if random
> aliases are used in the FROM address then the database for this server
> could grow unbelievably large to a point where it would be rendered
> useless. Also, this would also be a valuable resource for spammers to
> verify addresses in their own address lists! So... forget that idea!
>
> Rob McEwen
> PowerView Systems
> rob@PowerViewSystems.com
Rob,
Just parse received headers in attached message in backscatter. You can
easily see what this message sent not by your server and you can reject
such backscatter, because you never sent such messages.
Re: Posioned MX is a bad idea
Posted by Rob McEwen <ro...@powerviewsystems.com>.
Marc,
Overall good answers... but about six months ago, one of my users was joe
jobbed in "biblical proportions"... in this case, the spammer chose this
one "real" address and that spammer must have either sent the bots this
info, or pre-programmed the bots. When the spam run started, this particular
user was then the "from" address in many spams sent from many different IPs
and, as a result, he received hundreds of incoming outscatter per day (The
vast majority of which were were blocked by my spam filter). The outscatter
often showed the headers of the original spam and from that I was able to
determine that this was originating from an army of bots... NOT merely one
IP. Because the outscatter I saw was mail returned from that fraction of a
percent of mail servers which are misconfigured, the actual spam run must
have been in the 10s of thousands... or even millions per day.
Combine this with the fact that I highly doubt that anyone else's
implemenation of SAV would be as surgically targetted as yours, no matter
how hard they try, and my mail server might have been brought to its knees
had all the major ISPs used SAV at that time!
It would be interesting if there were a central "clearinghouse" server which
could do the SAV one time (with each new request not yet in the DB) and then
cache the results for everyone else to do some kind of DNS query to this one
server. But this is not feasible because if random aliases are used in the
FROM address then the database for this server could grow unbelievably large
to a point where it would be rendered useless. Also, this would also be a
valuable resource for spammers to verify addresses in their own address
lists! So... forget that idea!
Rob McEwen
PowerView Systems
rob@PowerViewSystems.com
Re: Posioned MX is a bad idea
Posted by "John D. Hardin" <jh...@impsec.org>.
On Sat, 25 Aug 2007, Marc Perkel wrote:
> Rob McEwen wrote:
>
> > (2) On the other hand, consider the scenerio where a single e-mail
> > address is Joe Jobbed in millions of spams... and that address is
> > valid (and this is quite common as worms play musical chair with
> > infected computers address books... using real, not guessed,
> > addresses!). If more ISPs were using SAV... particularly large ones...
> > wouldn't that essentially triigger such a large amount of SAV traffic
> > for that particular innocent domain's mail server that it would then
> > turn into a DDOS attack... just for a single large spam run?
>
> If someone did that their IP address would be quickly blacklisted
> and their server shut down. They wouldn't be able to send millions
> of emails that way. Your senereo is impossible.
Why do you think spammers use botnets?
(FYI, "scenario")
> > Therefore, I suppose that SAV is relatively harmless if fewer and
> > smaller ISPs use it... but it could cause many problems if more widely
> > adopted. It fails the "what if everyone were doing this" test.
>
> You have to do SAV right.
There is no guarantee people will do it "right". If it's a DDoS risk
when improperly implemented, then people are right to be suspicious of
it if not outright hostile to it.
> I eliminate all the spambot spam first. Then I cull out the
> blacklisted spam. Then I fasttrach the whitelisted hosts which
> allows about 65% of all god email through. Then I cull out other
> tricks that only spammers use. I then verify the recipient and
> after all that I verify the sender. So I'm only verifying less
> that 1% of all incoming connections. But the verification cuts out
> a lot of spam before going into SA.
Bravo for you. How many admins when presented with an "Enable SAV"
checkbox in their MTA configuration wizard are going to worry about it
to the degree you have? Or even be aware of the issues surrounding its
use? How many will say "Oooo! Shiny!" and enable it without taking
any steps to mitigate abusive failure modes?
> And - more importantly - spammers don't use my donains to spam
> others because my servers are SAV friendly and spammer prefer
> using domains that either pass everything.
Question: how do you know they aren't using forged addresses from your
domains? I don't doubt the claim, I just wonder how you're determining
that fact.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
I'm seriously considering getting one of those bright-orange prison
overalls and stencilling PASSENGER on the back. Along with the paper
slippers, I ought to be able to walk right through security.
-- Brian Kantor in a.s.r
-----------------------------------------------------------------------
Today: The 1928th anniversary of the destruction of Pompeii
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Marc Perkel <ma...@perkel.com>.
Rob McEwen wrote:
> Marc Perkel said:
>> If someone is sending email using one of my domains I want people
>> verifying the sender addresses. That way spam that is spoofing my
>> domains won't get delivered.
>
> Marc:
>
> (1) Sure, this covers spoofing where the alias is invalid for that
> domain, but it doesn't do anything about Joe Jobs of e-mail addresses
> that really do exist. That is unfortunately because the ones that do
> exist are the least quickly provably innocent. IOW, if the spammer is
> using my domain in the "From:" address, but choosing an address that
> doesn't realy exist, then anyone investigating it further can quickly
> and easily discover that messages sent to the non-existant user will
> receive an "unknown address" SMTP error code. Likewise, outscatter
> will also be a greater problem with real e-mail addresses, but not
> much of a problem at all with non-existant addresses. So while your
> point is valid, it is very limited.
I always verify the recipient exists before verifying the sender.
>
> (2) On the other hand, consider the scenerio where a single e-mail
> address is Joe Jobbed in millions of spams... and that address is
> valid (and this is quite common as worms play musical chair with
> infected computers address books... using real, not guessed,
> addresses!). If more ISPs were using SAV... particularly large ones...
> wouldn't that essentially triigger such a large amount of SAV traffic
> for that particular innocent domain's mail server that it would then
> turn into a DDOS attack... just for a single large spam run?
If someone did that their IP address would be quickly blacklisted and
their server shut down. They wouldn't be able to send millions of emails
that way. Your senereo is impossible.
>
> Therefore, I suppose that SAV is relatively harmless if fewer and
> smaller ISPs use it... but it could cause many problems if more widely
> adopted. It fails the "what if everyone were doing this" test.
>
>
You have to do SAV right. I eliminate all the spambot spam first. Then I
cull out the blacklisted spam. Then I fasttrach the whitelisted hosts
which allows about 65% of all god email through. Then I cull out other
tricks that only spammers use. I then verify the recipient and after
all that I verify the sender. So I'm only verifying less that 1% of all
incoming connections. But the verification cuts out a lot of spam before
going into SA.
And - more importantly - spammers don't use my donains to spam others
because my servers are SAV friendly and spammer prefer using domains
that either pass everything.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Rob McEwen <ro...@powerviewsystems.com>.
Marc Perkel said:
> If someone is sending email using one of my domains I want people
> verifying the sender addresses. That way spam that is spoofing my domains
> won't get delivered.
Marc:
(1) Sure, this covers spoofing where the alias is invalid for that domain,
but it doesn't do anything about Joe Jobs of e-mail addresses that really do
exist. That is unfortunately because the ones that do exist are the least
quickly provably innocent. IOW, if the spammer is using my domain in the
"From:" address, but choosing an address that doesn't realy exist, then
anyone investigating it further can quickly and easily discover that
messages sent to the non-existant user will receive an "unknown address"
SMTP error code. Likewise, outscatter will also be a greater problem with
real e-mail addresses, but not much of a problem at all with non-existant
addresses. So while your point is valid, it is very limited.
(2) On the other hand, consider the scenerio where a single e-mail address
is Joe Jobbed in millions of spams... and that address is valid (and this is
quite common as worms play musical chair with infected computers address
books... using real, not guessed, addresses!). If more ISPs were using
SAV... particularly large ones... wouldn't that essentially triigger such a
large amount of SAV traffic for that particular innocent domain's mail
server that it would then turn into a DDOS attack... just for a single large
spam run?
Therefore, I suppose that SAV is relatively harmless if fewer and smaller
ISPs use it... but it could cause many problems if more widely adopted. It
fails the "what if everyone were doing this" test.
Rob McEwen
PowerView Systems
rob@PowerViewSystems.com
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Marc Perkel <ma...@perkel.com>.
John Rudd wrote:
> mouss wrote:
>> Kai Schaetzl wrote:
>>> Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200:
>>>
>>>
>>>> I didn't know that a backup MX can lead to more trouble then having
>>>> just one
>>>>
>>>
>>> Unfortunately, backup MXes attract spammers :-(. You could at least
>>> add some more backup MXs (that don't exist) on top of that, that may
>>> help to reduce the influx on the real one.
>>
>>
>> Using bogus MX records is a very bad idea. Google for bogusmx and for
>> check_sender_mx_access.
>
> So, how exactly does "using bogus MX records" differ from "nolisting"?
>
>
> Because, the latter does seem to generally be thought of as a rather
> good anti-spam technique (it only catches spammers and a few very odd
> non-RFC compliant MTAs that don't check all MX records). If you have
> a one or more valid MX records, and one or more non-responsive MX
> records, then only non-RFC complaint MTAs will have a problem with
> that. We shouldn't care about the cases which break non-RFC compliant
> MTAs, as they're only used by morons.
>
>
> Further, how does check_sender_mx_access differ from Sender Address
> Verification (SAV)? (where SAV is an INCREDIBLY bad idea, and a blight
> upon the internet)
>
> (meaning: if check_sender_mx_access is just the postfix name for SAV,
> then we not only shouldn't avoid techniques that break
> check_sender_mx_access, we should all openly adopt techniques that
> break check_sender_mx_access as a means to further remove the SAV
> blight from the internet)
>
I have to disagree. Sender Address Verification works very well and is
definitely not a blight on the Internet. I welcome it on my servers. If
someone is sending email using one of my domains I want people verifying
the sender addresses. That way spam that is spoofing my domains won't
get delivered.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by John Rudd <jr...@ucsc.edu>.
Nikolay Shopik wrote:
> On 8/26/2007 12:08 AM, John Rudd wrote:
>> mouss wrote:
>>> Kai Schaetzl wrote:
>>>> Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200:
>>>>
>>>>
>>>>> I didn't know that a backup MX can lead to more trouble then having
>>>>> just one
>>>>>
>>>>
>>>> Unfortunately, backup MXes attract spammers :-(. You could at least
>>>> add some more backup MXs (that don't exist) on top of that, that may
>>>> help to reduce the influx on the real one.
>>>
>>>
>>> Using bogus MX records is a very bad idea. Google for bogusmx and for
>>> check_sender_mx_access.
>>
>> So, how exactly does "using bogus MX records" differ from "nolisting"?
>>
>>
>> Because, the latter does seem to generally be thought of as a rather
>> good anti-spam technique (it only catches spammers and a few very odd
>> non-RFC compliant MTAs that don't check all MX records). If you have
>> a one or more valid MX records, and one or more non-responsive MX
>> records, then only non-RFC complaint MTAs will have a problem with
>> that. We shouldn't care about the cases which break non-RFC compliant
>> MTAs, as they're only used by morons.
>>
>>
>> Further, how does check_sender_mx_access differ from Sender Address
>> Verification (SAV)? (where SAV is an INCREDIBLY bad idea, and a blight
>> upon the internet)
>>
>> (meaning: if check_sender_mx_access is just the postfix name for SAV,
>> then we not only shouldn't avoid techniques that break
>> check_sender_mx_access, we should all openly adopt techniques that
>> break check_sender_mx_access as a means to further remove the SAV
>> blight from the internet)
>>
>
> Why you so against SAV? I don't see big problem with that, just because
> it's not in RFC doesn't mean it shouldn't be there. SMTP need some kind
> verification of senders for decades already.
>
It's abusive, because it is essentially the same as sending email
bounces, in that it has a huge impact upon innocent bystanders whose
addresses are being forged. A huge spam flood could bring an innocent
site to its knees by having to answer all of those SAV requests.
It is also similar to TDMA type verifications, only you're asking the
remote MTA for verification, instead of the remote sender.
It's rude, because the SAV using site is using someone else's CPU power
in determining their anti-spam actions. It's also stupid for the same
reason (letting someone else decide what mail you will or wont accept).
Here's some other thoughts:
http://taint.org/2007/03/16/134743a.html
http://spam-vs-freedom.blogspot.com/2007/06/sender-address-verification-we-told-you.html
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by Nikolay Shopik <sh...@inblock.ru>.
On 8/26/2007 12:08 AM, John Rudd wrote:
> mouss wrote:
>> Kai Schaetzl wrote:
>>> Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200:
>>>
>>>
>>>> I didn't know that a backup MX can lead to more trouble then having
>>>> just one
>>>>
>>>
>>> Unfortunately, backup MXes attract spammers :-(. You could at least
>>> add some more backup MXs (that don't exist) on top of that, that may
>>> help to reduce the influx on the real one.
>>
>>
>> Using bogus MX records is a very bad idea. Google for bogusmx and for
>> check_sender_mx_access.
>
> So, how exactly does "using bogus MX records" differ from "nolisting"?
>
>
> Because, the latter does seem to generally be thought of as a rather
> good anti-spam technique (it only catches spammers and a few very odd
> non-RFC compliant MTAs that don't check all MX records). If you have a
> one or more valid MX records, and one or more non-responsive MX records,
> then only non-RFC complaint MTAs will have a problem with that. We
> shouldn't care about the cases which break non-RFC compliant MTAs, as
> they're only used by morons.
>
>
> Further, how does check_sender_mx_access differ from Sender Address
> Verification (SAV)? (where SAV is an INCREDIBLY bad idea, and a blight
> upon the internet)
>
> (meaning: if check_sender_mx_access is just the postfix name for SAV,
> then we not only shouldn't avoid techniques that break
> check_sender_mx_access, we should all openly adopt techniques that break
> check_sender_mx_access as a means to further remove the SAV blight from
> the internet)
>
Why you so against SAV? I don't see big problem with that, just because
it's not in RFC doesn't mean it shouldn't be there. SMTP need some kind
verification of senders for decades already.
Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]
Posted by John Rudd <jr...@ucsc.edu>.
mouss wrote:
> Kai Schaetzl wrote:
>> Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200:
>>
>>
>>> I didn't know that a backup MX can lead to more trouble then having
>>> just one
>>>
>>
>> Unfortunately, backup MXes attract spammers :-(. You could at least
>> add some more backup MXs (that don't exist) on top of that, that may
>> help to reduce the influx on the real one.
>
>
> Using bogus MX records is a very bad idea. Google for bogusmx and for
> check_sender_mx_access.
So, how exactly does "using bogus MX records" differ from "nolisting"?
Because, the latter does seem to generally be thought of as a rather
good anti-spam technique (it only catches spammers and a few very odd
non-RFC compliant MTAs that don't check all MX records). If you have a
one or more valid MX records, and one or more non-responsive MX records,
then only non-RFC complaint MTAs will have a problem with that. We
shouldn't care about the cases which break non-RFC compliant MTAs, as
they're only used by morons.
Further, how does check_sender_mx_access differ from Sender Address
Verification (SAV)? (where SAV is an INCREDIBLY bad idea, and a blight
upon the internet)
(meaning: if check_sender_mx_access is just the postfix name for SAV,
then we not only shouldn't avoid techniques that break
check_sender_mx_access, we should all openly adopt techniques that break
check_sender_mx_access as a means to further remove the SAV blight from
the internet)