Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[Aaron Wolfe]

On 8/27/07, Marc Perkel <[EMAIL PROTECTED]> 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]

[mouss]

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]

[Marc Perkel]

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]

[Andy Sutton]

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]

[David B Funk]

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
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[Marc Perkel]

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]

[David B Funk]

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
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[Steven Kurylo]

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]

[Marc Perkel]

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]

[Dave Mifsud]

On 27/08/07 12:19, martin f krafft wrote:
> also sprach mouss <[EMAIL PROTECTED]> [2007.08.26.1930 +0200]:
>> Indeed. reject != score. Moreover, I wouldn't put
>> - MX => private IP
>> - MX = "*.mx.*"
> 
> Why *.mx.*?
> 
> I happen to run all my MX as ?.mx.$my_domain and there is no reason
> why this should be indicative of anything.
> 

he literally means *.mx.*, not something.mx.something:

> dig yheweathernetwork.com mx

;; ANSWER SECTION:
yheweathernetwork.com.  9807IN  MX  0 *.mx.*.

dave
-- 
Dave Mifsud
Systems Engineer
Computing Services Centre
University of Malta

CSC Tel: (+356) 2340 3004  CSC Fax: (+356) 21 343 397

Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[martin f krafft]

also sprach mouss <[EMAIL PROTECTED]> [2007.08.26.1930 +0200]:
> Indeed. reject != score. Moreover, I wouldn't put
> - MX => private IP
> - MX = "*.mx.*"

Why *.mx.*?

I happen to run all my MX as ?.mx.$my_domain and there is no reason
why this should be indicative of anything.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
 
this space intentionally left blank.
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[Tony Finch]

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  <[EMAIL PROTECTED]>  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]

[Kai Schaetzl]

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]

[DAve]

Marc Perkel wrote:



Kai Schaetzl wrote:

Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 + (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 
<[EMAIL PROTECTED]>, 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]

[David B Funk]

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
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[Kenneth Porter]

--On Sunday, August 26, 2007 5:31 PM -0700 Marc Perkel <[EMAIL PROTECTED]> 
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]

[Marc Perkel]

Kai Schaetzl wrote:

Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 + (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]

[Kenneth Porter]

--On Sunday, August 26, 2007 11:31 AM +0200 Kai Schaetzl 
<[EMAIL PROTECTED]> 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]

[mouss]

Kai Schaetzl wrote:

Michael Scheidell wrote on Sun, 26 Aug 2007 09:54:16 -0400:

  

Look for 'bogusmx' blacklist.



criteria are different.
  


Indeed. reject != score. Moreover, I wouldn't put
- MX => private IP
- MX = "*.mx.*"
- MX = CNAME or MX=IP
at the same level.

anyway, Michael has missed my first post in the thread (I said "google 
for bogusmx", which return rfci as the first link... )
BTW: please consider using a client that is not broken. Your client 
doesn't include threading information.
  


That's what happens when using a proprietary intranet messaging system 
on the Open Internet (TM). It destroys "open" headers and inserts its 
own...


I wonder if we need a meta rule
- Subject has "Re:"
- no In-Reply-To and References header

;-p

RE: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[Michael Scheidell]

> -Original Message-
> From: Kai Schaetzl [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, August 26, 2007 12:31 PM
> To: users@spamassassin.apache.org
> Subject: Re: Posioned MX is a bad idea [Was: Email forwarding 
> and RBL trouble]
> 
> 
> Michael Scheidell wrote on Sun, 26 Aug 2007 09:54:16 -0400:
> 
> > Look for 'bogusmx' blacklist.
> 
> criteria are different.
> 
> BTW: please consider using a client that is not broken. Your client 
> doesn't include threading information.
> 
No, could you use a brain that isn't broken?
_
This email has been scanned and certified safe by SpammerTrap(tm).
For Information please see http://www.spammertrap.com
_

Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[Nikolay Shopik]

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]

[Kai Schaetzl]

Michael Scheidell wrote on Sun, 26 Aug 2007 09:54:16 -0400:

> Look for 'bogusmx' blacklist.

criteria are different.

BTW: please consider using a client that is not broken. Your client 
doesn't include threading information.

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]

[Dave Pooser]

> 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]

[Michael Scheidell]

> -Original Message-
> From: mouss [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, August 25, 2007 3:52 PM
> To: users@spamassassin.apache.org
> Subject: Re: Posioned MX is a bad idea [Was: Email forwarding 
> and RBL trouble]
> 
> sure, which may lead to the creation of a dedicated blacklist.

Which is called www.rfc-ignorant.org. And already has SA rule and score.

Look for 'bogusmx' blacklist.
_
This email has been scanned and certified safe by SpammerTrap(tm).
For Information please see http://www.spammertrap.com
_

Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[mouss]

Kai Schaetzl wrote:

Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 + (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]

[mouss]

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 <[EMAIL PROTECTED]>, 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.

Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[Kai Schaetzl]

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]

[Kai Schaetzl]

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 [Was: Email forwarding and RBL trouble]

[Tony Finch]

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  <[EMAIL PROTECTED]>  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]

[Kai Schaetzl]

Duane Hill wrote on Sat, 25 Aug 2007 22:29:50 + (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]

[Marc Perkel]

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]

[Duane Hill]

On Sat, 25 Aug 2007 at 13:42 -0700, [EMAIL PROTECTED] confabulated:


Duane Hill wrote:

On Sat, 25 Aug 2007 at 13:08 -0700, [EMAIL PROTECTED] 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]

[Rob McEwen]

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
[EMAIL PROTECTED]

Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[Dave Pooser]

> 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]

[Marc Perkel]

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]

[John Rudd]

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]

[Marc Perkel]

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]

[John Rudd]

Duane Hill wrote:

On Sat, 25 Aug 2007 at 13:08 -0700, [EMAIL PROTECTED] 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]

[Duane Hill]

On Sat, 25 Aug 2007 at 13:08 -0700, [EMAIL PROTECTED] 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]

[John Rudd]

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)

Re: Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[mouss]

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]

[Kai Schaetzl]

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

Posioned MX is a bad idea [Was: Email forwarding and RBL trouble]

[mouss]

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: Email forwarding and RBL trouble

[John D. Hardin]

On Wed, 22 Aug 2007, Rense Buijen wrote:

> I didn't know that a backup MX can lead to more trouble then
> having just one, gee, I thought it was a good thing but it turned
> out to be a quite bad one :)

It *is* a good idea. You just can't cheap out on configuring it. 

Ideally, your backup MXs should be configured with all the same
capabilities as your primary MX - username authentication, SA,
antivirus, RBLs, etc. - or they become an exploitable back door and a
nuisance to the rest of the world.

Spammers routinely target backup MXs first to try to take advantage of
this.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  People seem to have this obsession with objects and tools as being
  dangerous in and of themselves, as though a weapon will act of its
  own accord to cause harm. A weapon is just a force multiplier. It's
  *humans* that are (or are not) dangerous.
---
 3 days until The 1928th anniversary of the destruction of Pompeii

Re: Email forwarding and RBL trouble

[Aaron Wolfe]

On 8/22/07, Rense Buijen <[EMAIL PROTECTED]> wrote:
>
> Thanks a lot all, it's all clear to me now!
> I though that the trusted networks mean that the message will just be
> passed it it came from that source.
> I didnt know it will skip to the next "Received" IP. Thanks a lot.
>
> One question about the "backscatter" problem though, if I understand
> correctly it is always my Exchange server (the machine inline with SA)
> who will send out "user does not exist" messages, right? The backup MX
> will merely try to forward it and the Exchange server decides if that
> mail address exists or not. I think Exchange is configured the right way
> in such a way that it knows what users it has on the system..


Older Exchange servers will accept any message to a domain they are
responsible for, and then generate a new NDR message to the "sender" if the
user does not exist.  This is pretty retarded and leads to tons of
undeliverable NDRs clogging up your outbound queues, innocent people
gettings NDRs from spam they didn't send, etc.  At some point (I don't
remember the exact Exchange version, but definately 2003 and 2007, probably
2000) MS started allowing you to make Exchange reject mail for unknown users
during the SMTP transaction, which is a much better way to go about
things.   In your situation, that would just make your SA machine have to
send NDRs instead of your Exchange box, since it accepted the message.  This
is where you need to add recipient verification to your SA servers.  When
Exchange is in the "reject unknown" mode, that works fine and you can reject
unknowns before they enter your network at all.  This way you do not need to
mess with LDAP or expose any active directory to dmz/outside servers, and
you never have any NDR responsibility for spam.


> I would really like to drop the second mx altogether but policy forbids
> it :)



Backup MXs are a good thing, just have to configure them correctly and they
are don't require much maintenance after that.

Thanks for all the help guys!
>
> Rense
>
> Bowie Bailey wrote:
> > Rense Buijen wrote:
> >
> >> Mathhias,
> >>
> >> The problem is that when the mail enters the backup MX, we dont know
> >> if that mail is blacklisted at for instance spamcop.
> >> So if the backup mx accepts the mail (because it's dumb and it will
> >> accept it), and my primary mx (SA) has set the backup mx as trusted
> >> network/source, the mail will be delivered while it should not have
> >> been. You see the problem? SA cannot see if the mail that has been
> >> forwarded by my backup MX is valid (black/whitelisted) or not because
> >> it cannot check the IP against the RBL, it will lookup the wrong IP.
> >> And it should do this because there is NO rbl checking on the backup
> >> MX itself...
> >>
> >
> > You are making assumptions about what trusted_networks implies.  Just
> > because mail comes from a machine in your trusted_networks doesn't mean
> > that it will not be scanned.  The ONLY thing that trusted_networks means
> > is that you trust those machines to put valid header information in the
> > message.  It does NOT mean that you trust them not to forward spam.
> >
> > For your configuration, you need to put your backup MX into
> > trusted_networks in order for the RBLs to work properly.
> >
> > The real problem with this setup is that once your backup MX starts
> > forwarding messages to the primary and spam is rejected, then your
> > backup is in the bad position of having to issue a delivery notification
> > to the sender.  This is bad because most spam and viruses fake the
> > sender information.  So most of your bounces will be going to the wrong
> > person.  This is called "backscatter" and is another form of spam.  A
> > mailserver should not accept mail that it will not be able to deliver.
> >
> > I would suggest that you either configure your backup the same as your
> > primary, or just drop the backup altogether.  Without the backup, the
> > sending MTAs will still retry the message (usually for at least a couple
> > of days), so you don't lose anything unless your MX is down for an
> > extended period of time.
> >
> >
>
>
> --
> Met vriendelijke groeten,
>
> Rense Buijen
> Chess Service Management
> Tel.: 023-5149250
> Email: [EMAIL PROTECTED]
>
>

Re: Email forwarding and RBL trouble

[Kai Schaetzl]

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. And all MXes should normally behave the 
same, that is, do the same virus scanning etc.

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

RE: Email forwarding and RBL trouble

[Bowie Bailey]

Rense Buijen wrote:
> Thanks a lot all, it's all clear to me now!
> I though that the trusted networks mean that the message will just be
> passed it it came from that source.
> I didnt know it will skip to the next "Received" IP. Thanks a lot.
> 
> One question about the "backscatter" problem though, if I understand
> correctly it is always my Exchange server (the machine inline with SA)
> who will send out "user does not exist" messages, right? The backup MX
> will merely try to forward it and the Exchange server decides if that
> mail address exists or not. I think Exchange is configured the right
> way in such a way that it knows what users it has on the system..
> 
> I would really like to drop the second mx altogether but policy
> forbids it :)

Here is an example of the backscatter problem:

1) Mail is accepted at your backup MX
2) Backup MX forwards to primary MX
3) Primary MX refuses mail (spam, virus, bad user, whatever)
4) Backup MX sends delivery notification to "From" address
5) Innocent user whose address was in the "From" field of the message
   gets the delivery notification and has to deal with it.

Imagine 500 spams with the same forged From address going to various
non-existent users on your domain.  If you accept these messages, then
your server will be responsible for sending 500 delivery notification
messages to the poor guy whose email was forged in the spam.  (and
speaking as someone who has had their email address forged in a spam
run, this is REALLY annoying)

This is what should happen:

1) Mail arrives at backup MX
2) Mail is refused (spam, virus, bad user, etc)
3) It is now the responsibility of the sending server to send a delivery
   notification.

Depending on where the mail originated from, it is still possible that
the sending server is generating backscatter, but at least you are no
longer contributing to the problem.

To avoid contributing to the backscatter problem (which can get you on
some blacklists), you must ensure that all of your frontline MX servers
are capable of rejecting mail for unknown users and that they all do the
same virus/spam filtering.  The basic idea is that your frontline
servers should never accept an email that will be rejected later on.

-- 
Bowie

Re: Email forwarding and RBL trouble

[Rense Buijen]

Hi Kai,

I didn't know that a backup MX can lead to more trouble then having just 
one, gee, I thought it was a good thing but it turned out to be a quite 
bad one :)
I'll go and use LDAP on the second MX to make sure the remote user 
exists, otherwise drop it silently.
It's indeed getting a bit off-topic so I'll thank everyone for their 
input, it made me a lot wiser on this issue.

And as for spamassassin... keep up the good work, I love it!

Rense

Kai Schaetzl wrote:

Rense Buijen wrote on Wed, 22 Aug 2007 16:01:09 +0200:

  
I think Exchange is configured the right way 
in such a way that it knows what users it has on the system..



But your backup MX doesn't. As you say you are taking in all mail, forward 
it to primary and then bounce it back to the sender. But your primary MX 
doesn't know the sender! Basically *all* viruses and spam come with forged 
senders. So, what you do is bounce back spam and viruses to innocent 
bystanders. This is bad, really bad!
What you should do is check on the secondary MX if a user exists and don't 
accept it if a user doesn't exist. This depends on the mail server you 
use, there are several solutions for this and it's off-topic on this list. 
And until you don't have such a solution in place do *not* send out *any* 
DSNs from your primary MX if they are for messages you got in from your 
secondary!


Kai

  



--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

Re: Email forwarding and RBL trouble

[Kai Schaetzl]

Rense Buijen wrote on Wed, 22 Aug 2007 16:01:09 +0200:

> I think Exchange is configured the right way 
> in such a way that it knows what users it has on the system..

But your backup MX doesn't. As you say you are taking in all mail, forward 
it to primary and then bounce it back to the sender. But your primary MX 
doesn't know the sender! Basically *all* viruses and spam come with forged 
senders. So, what you do is bounce back spam and viruses to innocent 
bystanders. This is bad, really bad!
What you should do is check on the secondary MX if a user exists and don't 
accept it if a user doesn't exist. This depends on the mail server you 
use, there are several solutions for this and it's off-topic on this list. 
And until you don't have such a solution in place do *not* send out *any* 
DSNs from your primary MX if they are for messages you got in from your 
secondary!

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

Re: Email forwarding and RBL trouble

[Rense Buijen]

Thanks a lot all, it's all clear to me now!
I though that the trusted networks mean that the message will just be 
passed it it came from that source.

I didnt know it will skip to the next "Received" IP. Thanks a lot.

One question about the "backscatter" problem though, if I understand 
correctly it is always my Exchange server (the machine inline with SA) 
who will send out "user does not exist" messages, right? The backup MX 
will merely try to forward it and the Exchange server decides if that 
mail address exists or not. I think Exchange is configured the right way 
in such a way that it knows what users it has on the system..


I would really like to drop the second mx altogether but policy forbids 
it :)


Thanks for all the help guys!

Rense

Bowie Bailey wrote:

Rense Buijen wrote:
  

Mathhias,

The problem is that when the mail enters the backup MX, we dont know
if that mail is blacklisted at for instance spamcop.
So if the backup mx accepts the mail (because it's dumb and it will
accept it), and my primary mx (SA) has set the backup mx as trusted
network/source, the mail will be delivered while it should not have
been. You see the problem? SA cannot see if the mail that has been
forwarded by my backup MX is valid (black/whitelisted) or not because
it cannot check the IP against the RBL, it will lookup the wrong IP.
And it should do this because there is NO rbl checking on the backup
MX itself... 



You are making assumptions about what trusted_networks implies.  Just
because mail comes from a machine in your trusted_networks doesn't mean
that it will not be scanned.  The ONLY thing that trusted_networks means
is that you trust those machines to put valid header information in the
message.  It does NOT mean that you trust them not to forward spam.

For your configuration, you need to put your backup MX into
trusted_networks in order for the RBLs to work properly.

The real problem with this setup is that once your backup MX starts
forwarding messages to the primary and spam is rejected, then your
backup is in the bad position of having to issue a delivery notification
to the sender.  This is bad because most spam and viruses fake the
sender information.  So most of your bounces will be going to the wrong
person.  This is called "backscatter" and is another form of spam.  A
mailserver should not accept mail that it will not be able to deliver.

I would suggest that you either configure your backup the same as your
primary, or just drop the backup altogether.  Without the backup, the
sending MTAs will still retry the message (usually for at least a couple
of days), so you don't lose anything unless your MX is down for an
extended period of time.

  



--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

RE: Email forwarding and RBL trouble

[Bowie Bailey]

Rense Buijen wrote:
> Mathhias,
> 
> The problem is that when the mail enters the backup MX, we dont know
> if that mail is blacklisted at for instance spamcop.
> So if the backup mx accepts the mail (because it's dumb and it will
> accept it), and my primary mx (SA) has set the backup mx as trusted
> network/source, the mail will be delivered while it should not have
> been. You see the problem? SA cannot see if the mail that has been
> forwarded by my backup MX is valid (black/whitelisted) or not because
> it cannot check the IP against the RBL, it will lookup the wrong IP.
> And it should do this because there is NO rbl checking on the backup
> MX itself... 

You are making assumptions about what trusted_networks implies.  Just
because mail comes from a machine in your trusted_networks doesn't mean
that it will not be scanned.  The ONLY thing that trusted_networks means
is that you trust those machines to put valid header information in the
message.  It does NOT mean that you trust them not to forward spam.

For your configuration, you need to put your backup MX into
trusted_networks in order for the RBLs to work properly.

The real problem with this setup is that once your backup MX starts
forwarding messages to the primary and spam is rejected, then your
backup is in the bad position of having to issue a delivery notification
to the sender.  This is bad because most spam and viruses fake the
sender information.  So most of your bounces will be going to the wrong
person.  This is called "backscatter" and is another form of spam.  A
mailserver should not accept mail that it will not be able to deliver.

I would suggest that you either configure your backup the same as your
primary, or just drop the backup altogether.  Without the backup, the
sending MTAs will still retry the message (usually for at least a couple
of days), so you don't lose anything unless your MX is down for an
extended period of time.

-- 
Bowie

Re: Email forwarding and RBL trouble

[Ben O'Hara]

Thats the one

Ben

On 8/22/07, Rense Buijen <[EMAIL PROTECTED]> wrote:
>
> ...thats it? So it will skip the IP of the second MX and do an RBL check
> against the IP who'm delivered it to the second MX? COOL! I thought it
> would just ignore everything and pass on the mail Thanks!
>
> Ben O'Hara wrote:
> > On 8/22/07, *Rense Buijen* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Hi Pawel,
> >
> > I dont think I can check the recipient,  if it doesnt exist the
> > mailserver should send a normal bounce like every mailserver does,
> > right? So does the primary machine (Exchange)  I dont see a
> > problem with
> > that.
> >
> > Do you know if there is another good setup without having to sync
> > all my
> > antispam stuff to my second MX? I would really just use forwarding
> if
> > that is possible. Can I not rewrite the last "Received" header? That
> > should work maybe?
> >
> >
> >
> > You dont have to, add your secondary mx to trusted_networks on the
> > primary and it will know the fact to do the RBL lookups on the host
> > that sent the mail to  the secondary MX rather than the secondary mx
> > itself.
> >
> > Ben
> >
> > Kind regards,
> >
> > Rense
> >
> > Pawel Sasin wrote:
> > > Hi
> > >> I cannot utilize the trusted_networks settings because I cannot
> > trust
> > >> the mail that my backup MX sends to me.
> > >>
> > >> The backup MX does NO filtering at all, it just accepts ALL
> > mail that
> > >> has a certain destination domain and then forwards it to the
> > Primary
> > >> MX where SA is running, SA is doing all the filtering and
> > >> white/black/grey-listing.
> > >>
> > >> When SA is down (the Pri MX), it will just hold it until it
> > gets back
> > >> up. So basically all mail that comes from my second MX should be
> > >> checked for spam and virus, it has not capabilities of it's
> > own. It's
> > >> working like a charm were it not for my black/white/grey-lists
> and
> > >> the RBL's now all do lookups on the last known IP which is my
> > >> secondary MX.
> > >>
> > >> I don't think I am the first to utilize this method of
> > redundancy so
> > >> I figured there must be a way, I just dont know how :)
> > >> So please advice further, your (and everyones) help is greatly
> > >> appreciated.
> > >
> > > SA checks all 'Received' headers against RBLs.
> > >
> > > If you add secondary MX to trusted_networks, SA will just skip the
> > > header from your exim and continue with the rest.
> > >
> > > But there is another problem with such config:
> > > 1. see the numbers here http://nolisting.org/
> > > 2. does your dumb exim (secondary mx) check if the recipent
> address
> > > exists?
> > >
> > > If not you will end up sending tons of bounce messages to innocent
> > > people from your secondary MX. Even if it does, your primary MX
> can
> > > refuse a spammy message and then you will be generating even more
> > > bounce messages. This is not acceptable and you will end up in
> some
> > > RBLs yourself.
> > >
> >
> >
> > --
> > Met vriendelijke groeten,
> >
> > Rense Buijen
> > Chess Service Management
> > Tel.: 023-5149250
> > Email: [EMAIL PROTECTED] 
> >
> >
> >
> >
> > --
> > "A Scientist will earn a living by taking a really difficult problem
> > and spends many years solving it, an engineer earns a living by
> > finding really difficult problems and side stepping them"
>
>
> --
> Met vriendelijke groeten,
>
> Rense Buijen
> Chess Service Management
> Tel.: 023-5149250
> Email: [EMAIL PROTECTED]
>
>


-- 
"A Scientist will earn a living by taking a really difficult problem and
spends many years solving it, an engineer earns a living by finding really
difficult problems and side stepping them"

Re: Email forwarding and RBL trouble

[Rense Buijen]

Mathhias,

The problem is that when the mail enters the backup MX, we dont know if 
that mail is blacklisted at for instance spamcop.
So if the backup mx accepts the mail (because it's dumb and it will 
accept it), and my primary mx (SA) has set the backup mx as trusted 
network/source, the mail will be delivered while it should not have 
been. You see the problem? SA cannot see if the mail that has been 
forwarded by my backup MX is valid (black/whitelisted) or not because it 
cannot check the IP against the RBL, it will lookup the wrong IP. And it 
should do this because there is NO rbl checking on the backup MX itself...


Matthias Leisi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Rense Buijen schrieb:

  

Thank you for your (quick) reply.
I cannot utilize the trusted_networks settings because I cannot trust
the mail that my backup MX sends to me.



But your backup MX is "trusted" in the sense that it will not forge
sender addresses, Received: lines etc. -- that's what trusted_networks
basically implies.

If trusted_networks etc are set correctly, SA will recognize your backup
MX, and will not apply any RBL checks to it's IP address. The
Mail::SpamAssassin::Conf man-page has all the dirty details, including
those of internal_networks

  

The backup MX does NO filtering at all, it just accepts ALL mail that
has a certain destination domain and then forwards it to the Primary MX
where SA is running, SA is doing all the filtering and
white/black/grey-listing.



You should ensure that connections from your backup MX are not
grey/blacklisted at the MTA level (don't know whether you're already
doing it, but just to mention it...).

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFGzDfTxbHw2nyi/okRAq7jAKCbKv8IknFw2Nmse3l3LTszN7OyYgCfY28l
XAA+s+kES1B4mbmcvK2VE24=
=95OW
-END PGP SIGNATURE-

  



--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

Re: Email forwarding and RBL trouble

[Rense Buijen]

Hi Pawel,

I dont think I can check the recipient,  if it doesnt exist the 
mailserver should send a normal bounce like every mailserver does, 
right? So does the primary machine (Exchange)  I dont see a problem with 
that.


Do you know if there is another good setup without having to sync all my 
antispam stuff to my second MX? I would really just use forwarding if 
that is possible. Can I not rewrite the last "Received" header? That 
should work maybe?


Kind regards,

Rense

Pawel Sasin wrote:

Hi
I cannot utilize the trusted_networks settings because I cannot trust 
the mail that my backup MX sends to me.


The backup MX does NO filtering at all, it just accepts ALL mail that 
has a certain destination domain and then forwards it to the Primary 
MX where SA is running, SA is doing all the filtering and 
white/black/grey-listing.


When SA is down (the Pri MX), it will just hold it until it gets back 
up. So basically all mail that comes from my second MX should be 
checked for spam and virus, it has not capabilities of it's own. It's 
working like a charm were it not for my black/white/grey-lists and 
the RBL's now all do lookups on the last known IP which is my 
secondary MX.


I don't think I am the first to utilize this method of redundancy so 
I figured there must be a way, I just dont know how :)
So please advice further, your (and everyones) help is greatly 
appreciated.


SA checks all 'Received' headers against RBLs.

If you add secondary MX to trusted_networks, SA will just skip the 
header from your exim and continue with the rest.


But there is another problem with such config:
1. see the numbers here http://nolisting.org/
2. does your dumb exim (secondary mx) check if the recipent address 
exists?


If not you will end up sending tons of bounce messages to innocent 
people from your secondary MX. Even if it does, your primary MX can 
refuse a spammy message and then you will be generating even more 
bounce messages. This is not acceptable and you will end up in some 
RBLs yourself.





--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

Re: Email forwarding and RBL trouble

[Matthias Leisi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Rense Buijen schrieb:

> Thank you for your (quick) reply.
> I cannot utilize the trusted_networks settings because I cannot trust
> the mail that my backup MX sends to me.

But your backup MX is "trusted" in the sense that it will not forge
sender addresses, Received: lines etc. -- that's what trusted_networks
basically implies.

If trusted_networks etc are set correctly, SA will recognize your backup
MX, and will not apply any RBL checks to it's IP address. The
Mail::SpamAssassin::Conf man-page has all the dirty details, including
those of internal_networks

> The backup MX does NO filtering at all, it just accepts ALL mail that
> has a certain destination domain and then forwards it to the Primary MX
> where SA is running, SA is doing all the filtering and
> white/black/grey-listing.

You should ensure that connections from your backup MX are not
grey/blacklisted at the MTA level (don't know whether you're already
doing it, but just to mention it...).

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFGzDfTxbHw2nyi/okRAq7jAKCbKv8IknFw2Nmse3l3LTszN7OyYgCfY28l
XAA+s+kES1B4mbmcvK2VE24=
=95OW
-END PGP SIGNATURE-

Re: Email forwarding and RBL trouble

[Rense Buijen]

Hi Matthias,

Thank you for your (quick) reply.
I cannot utilize the trusted_networks settings because I cannot trust 
the mail that my backup MX sends to me.


The backup MX does NO filtering at all, it just accepts ALL mail that 
has a certain destination domain and then forwards it to the Primary MX 
where SA is running, SA is doing all the filtering and 
white/black/grey-listing.


When SA is down (the Pri MX), it will just hold it until it gets back 
up. So basically all mail that comes from my second MX should be checked 
for spam and virus, it has not capabilities of it's own. It's working 
like a charm were it not for my black/white/grey-lists and the RBL's now 
all do lookups on the last known IP which is my secondary MX.


I don't think I am the first to utilize this method of redundancy so I 
figured there must be a way, I just dont know how :)

So please advice further, your (and everyones) help is greatly appreciated.

Kind regards,

Rense

Matthias Leisi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Rense Buijen schrieb:

  

The problem now lies with the RBL's, when the SA box dies, the mail will
be queued on my Exim box and when service is restored, it will forward
it again BUT the last "Received from:" path will be of course the Exim
host IP. SA will then do a lookup on the wrong IP. Basically I want my
Exim box (second mx) to be invisible or need the headers to be rewritten
so Spamassassin does a correct lookup on the IP BEFORE it got to the SA.



trusted_networks, internal_networks etc. will make sure that your "main"
SA correctly recognises your backup box as trustworthy.

  

I've heard about SRS, I don't know precisely if that will do the trick
for me, anyone has some more information, tips or tricks? It's rather
complex matter and I can't find any good documentation on how to solve
this problem.



SRS is a completely different beast (basically it fixes forwarding which
is partially broken by SPF). As long as you only have troubles with IP
addresses, SRS would not solve any issue for you.

- -- Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFGzC5uxbHw2nyi/okRAgtsAJ9kyqrwaZ0waBswmcuV0jsO3HWbUACggovQ
7DPNJbxhSleg+Dkbvh66qd0=
=gIn9
-END PGP SIGNATURE-

  



--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

Re: Email forwarding and RBL trouble

[Pawel Sasin]

Hi
I cannot utilize the trusted_networks settings because I cannot trust 
the mail that my backup MX sends to me.


The backup MX does NO filtering at all, it just accepts ALL mail that 
has a certain destination domain and then forwards it to the Primary 
MX where SA is running, SA is doing all the filtering and 
white/black/grey-listing.


When SA is down (the Pri MX), it will just hold it until it gets back 
up. So basically all mail that comes from my second MX should be 
checked for spam and virus, it has not capabilities of it's own. It's 
working like a charm were it not for my black/white/grey-lists and the 
RBL's now all do lookups on the last known IP which is my secondary MX.


I don't think I am the first to utilize this method of redundancy so I 
figured there must be a way, I just dont know how :)
So please advice further, your (and everyones) help is greatly 
appreciated.


SA checks all 'Received' headers against RBLs.

If you add secondary MX to trusted_networks, SA will just skip the 
header from your exim and continue with the rest.


But there is another problem with such config:
1. see the numbers here http://nolisting.org/
2. does your dumb exim (secondary mx) check if the recipent address exists?

If not you will end up sending tons of bounce messages to innocent 
people from your secondary MX. Even if it does, your primary MX can 
refuse a spammy message and then you will be generating even more bounce 
messages. This is not acceptable and you will end up in some RBLs yourself.


--
p.

WIRTUALNA  POLSKA  SA, ul. Traugutta 115c, 80-226 Gdansk; NIP: 957-07-51-216; 
Sad Rejonowy Gdansk-Polnoc KRS 068548, kapital zakladowy 62.880.024 zlotych (w calosci wplacony)

Re: Email forwarding and RBL trouble

[Rense Buijen]

Hi Matthias,

Thank you for your (quick) reply.
I cannot utilize the trusted_networks settings because I cannot trust 
the mail that my backup MX sends to me.


The backup MX does NO filtering at all, it just accepts ALL mail that 
has a certain destination domain and then forwards it to the Primary MX 
where SA is running, SA is doing all the filtering and 
white/black/grey-listing.


When SA is down (the Pri MX), it will just hold it until it gets back 
up. So basically all mail that comes from my second MX should be checked 
for spam and virus, it has not capabilities of it's own. It's working 
like a charm were it not for my black/white/grey-lists and the RBL's now 
all do lookups on the last known IP which is my secondary MX.


I don't think I am the first to utilize this method of redundancy so I 
figured there must be a way, I just dont know how :)

So please advice further, your (and everyones) help is greatly appreciated.

Kind regards,

Rense

Matthias Leisi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Rense Buijen schrieb:

  

The problem now lies with the RBL's, when the SA box dies, the mail will
be queued on my Exim box and when service is restored, it will forward
it again BUT the last "Received from:" path will be of course the Exim
host IP. SA will then do a lookup on the wrong IP. Basically I want my
Exim box (second mx) to be invisible or need the headers to be rewritten
so Spamassassin does a correct lookup on the IP BEFORE it got to the SA.



trusted_networks, internal_networks etc. will make sure that your "main"
SA correctly recognises your backup box as trustworthy.

  

I've heard about SRS, I don't know precisely if that will do the trick
for me, anyone has some more information, tips or tricks? It's rather
complex matter and I can't find any good documentation on how to solve
this problem.



SRS is a completely different beast (basically it fixes forwarding which
is partially broken by SPF). As long as you only have troubles with IP
addresses, SRS would not solve any issue for you.

- -- Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFGzC5uxbHw2nyi/okRAgtsAJ9kyqrwaZ0waBswmcuV0jsO3HWbUACggovQ
7DPNJbxhSleg+Dkbvh66qd0=
=gIn9
-END PGP SIGNATURE-

  



--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

Re: Email forwarding and RBL trouble

[Matthias Leisi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Rense Buijen schrieb:

> The problem now lies with the RBL's, when the SA box dies, the mail will
> be queued on my Exim box and when service is restored, it will forward
> it again BUT the last "Received from:" path will be of course the Exim
> host IP. SA will then do a lookup on the wrong IP. Basically I want my
> Exim box (second mx) to be invisible or need the headers to be rewritten
> so Spamassassin does a correct lookup on the IP BEFORE it got to the SA.

trusted_networks, internal_networks etc. will make sure that your "main"
SA correctly recognises your backup box as trustworthy.

> I've heard about SRS, I don't know precisely if that will do the trick
> for me, anyone has some more information, tips or tricks? It's rather
> complex matter and I can't find any good documentation on how to solve
> this problem.

SRS is a completely different beast (basically it fixes forwarding which
is partially broken by SPF). As long as you only have troubles with IP
addresses, SRS would not solve any issue for you.

- -- Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFGzC5uxbHw2nyi/okRAgtsAJ9kyqrwaZ0waBswmcuV0jsO3HWbUACggovQ
7DPNJbxhSleg+Dkbvh66qd0=
=gIn9
-END PGP SIGNATURE-

Email forwarding and RBL trouble

[Rense Buijen]

Hello all,

I have two mailservers, a primary and a secondary MX.
The primary MX is a spamassassin (3.2.3 on Ubuntu Linux) box that is 
placed inline of a MS Exchange machine.

Spamassassin is doing a good job, especialy with the RBL's I am using.
The backup MX is a simple EXIM which does only forwarding (to the 
spamassassin box) without any spam control.


This setup should be simple yet effective, if the Pri MX dies, the 
forwarder will hold all the mail and wait until the SA box is back up 
and then send the queued mail to it. It will then be filtered again, 
that way I dont have to sync whitelists, greylist databases and all my 
rules to the second MX.


The problem now lies with the RBL's, when the SA box dies, the mail will 
be queued on my Exim box and when service is restored, it will forward 
it again BUT the last "Received from:" path will be of course the Exim 
host IP. SA will then do a lookup on the wrong IP. Basically I want my 
Exim box (second mx) to be invisible or need the headers to be rewritten 
so Spamassassin does a correct lookup on the IP BEFORE it got to the SA.


I've heard about SRS, I don't know precisely if that will do the trick 
for me, anyone has some more information, tips or tricks? It's rather 
complex matter and I can't find any good documentation on how to solve 
this problem.


Kind regards,

Rense