Jan:
Thanks again for the detailed response. Responding after a fairly invasive
amount of updates to the v2 code. I've tried to fix each scenario you
identified and added much more informative debug information.
Kevin A. McGrail wrote:
http://www.peregrinehw.com/downloads/MIMEDefang/contrib/check_primary_mx_stub-v2.pl
If anyone has any comments...
Hmm... it might be useful to include the particular offending IP in the $reason:
Suggested changes to invalid_mx routine follow... note ' becomes so $ip
- Original Message -
From: [EMAIL PROTECTED]
Hmm... it might be useful to include the particular offending IP in the
$reason:
Thanks, I've been working on making the returns more and more informative.
And I originally thought about making this change but had decided not to
because the
On Mon, Oct 24, 2005 at 05:07:40AM -0400, Kevin A. McGrail wrote:
So for example, we don't reject
outright on private IP space in MX records, as long as there are
other reachable addresses too.
I chose to only check the primary MX because my analysis showed that it was
likely to be a good
Sorry, I'm coming a little late to this discussions, but I have
a few hopefully useful suggestions.
Wow, what a great response, no apologies needed. I'll go through it point
by point!
Actually, use Net::DNS; should be at the top of your file, it doesn't
need
to be in a subroutine (in fact,
Sorry, I'm coming a little late to this discussions, but I have
a few hopefully useful suggestions.
On Tue, Oct 11, 2005 at 11:58:26AM -0400, Kevin A. McGrail wrote:
We have added the check_primary_mx for senders to our filter with good
success and I've added this feature to
On Mon, 12 Sep 2005, Les Mikesell wrote:
On Mon, 2005-09-12 at 17:31, Kelson wrote:
I remember a year or two ago there was a fad in which admins would set
up a tertiary or higher MX pointing to 127.0.0.1 in order to hassle spam
software that used the highest MX instead of the lowest.
I don't
--On Tuesday, September 13, 2005 1:29 PM +0200 Steffen Kaiser
[EMAIL PROTECTED] wrote:
Well, the same effort in to detect bad MX hosts can be performed by
ratware, hence, this technique can last for short while only, perhaps the
usefullness is gone by now.
The 2nd best solution is to use
[EMAIL PROTECTED] wrote on 09/12/2005 05:24:53
PM:
I'm not arguing it's right or good, I'm simply saying it's commonplace
and
will cause false positives.
I'm also not sure yet if I would use this to reject or discard emails.
That
code (based on Joseph Brennan's) is coming later.
On Tue, 2005-09-13 at 07:07, Kenneth Porter wrote:
Well, the same effort in to detect bad MX hosts can be performed by
ratware, hence, this technique can last for short while only, perhaps the
usefullness is gone by now.
The 2nd best solution is to use black hole space for the last MX,
On Tue, 13 Sep 2005, Kenneth Porter wrote:
--On Tuesday, September 13, 2005 1:29 PM +0200 Steffen Kaiser
[EMAIL PROTECTED] wrote:
Well, the same effort in to detect bad MX hosts can be performed by
ratware, hence, this technique can last for short while only, perhaps the
usefullness is gone
I agree this is really nice, complete and not messy, but I really just don't
want to use extra, non-stock modules for this.
Unless there is a performance reason, I think the current code is good
enough to move forward on. Now we're just nitpicking some code that really
isn't that hard to
Joseph Brennan was kind enough to share more code snippets with me which had
predisposed me against a bounce. BUT Joseph's code was originally done in
filter_begin which led to my initial worry about reject/bounce vs discard.
However, right now, I am thinking I should be able to do the
On Feb 3, 3:35am, Kevin A. McGrail wrote:
}
} Joseph Brennan was kind enough to share more code snippets with me which had
} predisposed me against a bounce. BUT Joseph's code was originally done in
} filter_begin which led to my initial worry about reject/bounce vs discard.
}
} However,
} However, right now, I am thinking I should be able to do the invalid
helo
} and invalid MX check in filter_sender since I have $sender and that's
all I
} need. If I reject in filter_sender, I haven't received the entire email
yet
} and it isn't a very costly transaction.
If you do
On Tue, 2005-09-13 at 09:25, Kevin A. McGrail wrote:
} However, right now, I am thinking I should be able to do the invalid
helo
} and invalid MX check in filter_sender since I have $sender and that's
all I
} need. If I reject in filter_sender, I haven't received the entire email
yet
}
How is this a hostile to the relay? We aren't even accepting the mail. We
are rejecting it before the conversation between the SMTP servers is
finished. This email won't even hit your local queue.
If the only or best MX target is 127.0.0.1, this is fairly hostile
toward your neighbor relay.
KAM wrote:
Les Mikesell wrote:
If the only or best MX target is 127.0.0.1, this is fairly hostile
toward your neighbor relay. But, as I mentioned before, the spam
appliance I am forwarding through is doing a 451 temp_fail which
just prolongs the problem and backs up my queue. There's
On Tue, 2005-09-13 at 10:34, Kevin A. McGrail wrote:
How is this a hostile to the relay? We aren't even accepting the mail. We
are rejecting it before the conversation between the SMTP servers is
finished. This email won't even hit your local queue.
It's unlikely you are talking to the
Les Mikesell wrote:
On Tue, 2005-09-13 at 10:34, Kevin A. McGrail wrote:
How is this a hostile to the relay? We aren't even accepting the
mail. We are rejecting it before the conversation between the SMTP
servers is finished. This email won't even hit your local queue.
It's unlikely you
.
To discard, you will need to perform the tests in filter_begin.
Regards,
KAM
- Original Message -
From: Les Mikesell [EMAIL PROTECTED]
To: mimedefang@lists.roaringpenguin.com
Sent: Tuesday, September 13, 2005 11:51 AM
Subject: Re: [Mimedefang] MX - 127.0.0.1
On Tue, 2005-09-13 at 10:34, Kevin
On Tue, 13 Sep 2005, Les Mikesell wrote:
On Tue, 2005-09-13 at 10:34, Kevin A. McGrail wrote:
How is this a hostile to the relay? We aren't even accepting the mail. We
are rejecting it before the conversation between the SMTP servers is
finished. This email won't even hit your local
On Tue, 2005-09-13 at 13:33, Jim McCullars wrote:
It's unlikely you are talking to the original sender. Assume a
forwarding relay has accepted a copy (as I am doing now), then
trying to deliver. If you give a 5xx smtp response you force the
sending relay to construct a bounce. But you
Les Mikesell wrote:
On Tue, 2005-09-13 at 13:33, Jim McCullars wrote:
It's unlikely you are talking to the original sender. Assume a
forwarding relay has accepted a copy (as I am doing now), then
trying to deliver.
Depending on your topology, that assumption may be a certainty - or it may
On Tue, 2005-09-13 at 14:28, [EMAIL PROTECTED] wrote:
Anyone who has gone to the trouble of poisoning public DNS with an
MX that ends up at 127.0.0.1 really doesn't want that bounce back
so I think we can assume they won't make an extra effort to make it
work from certain machines. Or,
Les Mikesell wrote:
On Tue, 2005-09-13 at 14:28, [EMAIL PROTECTED] wrote:
Anyone who has gone to the trouble of poisoning public DNS with an
MX that ends up at 127.0.0.1 really doesn't want that bounce back
so I think we can assume they won't make an extra effort to make it
work from
[EMAIL PROTECTED] wrote:
Also, this case
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040412/069931.html
is rapidly falling out of favor. In fact, ibase.com has fixed that somewhat.
I'm worried in particular about the novice Exchange admin who has misconfigured
his Active Directory
This looks like a good idea! Where (which routine) did you add this to
your relay? filter_end?
Also, does this stop people from using sendmail directly to send email or
the few local users who might send mail with mutt or pine?
Oops!! Sorry. This comes inside a large if that excludes
Also does this actually do the MX lookup? The ones I'm getting
have reasonable looking names and you don't see the problem
until you follow the MX record and find the IP address is
127.0.0.1, 0.0.0.0 or something equally crazy. I have
sendmail set to reject if the sending domain doesn't
Here is my test stub to add a resolution of the MX records for the domain.
Would appreciate peer review and comments but it looks like a pretty
straightforward test.
#!/usr/bin/perl -w
use strict;
use Net::DNS; #Put in filter_initialize
print check_primary_mx('[EMAIL PROTECTED]');
sub
Sorry, not paying enough attention. I have to resolve the exchanges first.
New version in a moment.
KAM
Here is my test stub to add a resolution of the MX records for the domain.
Would appreciate peer review and comments but it looks like a pretty
straightforward test.
KAM wrote:
Sorry, not paying enough attention. I have to resolve the exchanges
first. New version in a moment.
Have you seen this code:
http://www.mimedefang.org/kwiki/index.cgi?CheckForMX
Perhaps this wiki page is not sufficiently generalized, as this is another use
of some of that code?
On Mon, 2005-09-12 at 13:19, Kevin A. McGrail wrote:
Sorry, not paying enough attention. I have to resolve the exchanges first.
New version in a moment.
If you need some test cases:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
Les Mikesell
[EMAIL PROTECTED]
On Mon, 2005-09-12 at 13:34, [EMAIL PROTECTED] wrote:
KAM wrote:
Sorry, not paying enough attention. I have to resolve the exchanges
first. New version in a moment.
Have you seen this code:
http://www.mimedefang.org/kwiki/index.cgi?CheckForMX
Perhaps this wiki page is not
Les Mikesell wrote:
On Mon, 2005-09-12 at 13:34, [EMAIL PROTECTED] wrote:
Have you seen this code:
http://www.mimedefang.org/kwiki/index.cgi?CheckForMX
Perhaps this wiki page is not sufficiently generalized, as this is
another use of some of that code?
Time for another philosophical
I hadn't seen it but it's good code and more functionalized than my code.
However, it's missing the issue that while CNAMEs are not RFC compliant,
people do use them. And I also found a bug where the MX resolution is
supposed to be returned in preference order but it doesn't seem to be done
so in
Thanks for the extra test cases. Assuming they should all fail, here's my
new test stub. Looks good to me. Review and comment appreciated.
http://www.pccc.com/downloads/MIMEDefang/contrib/check_primary_mx_stub.pl
Regards,
KAM
If you need some test cases:
[EMAIL PROTECTED]
[EMAIL
--On Monday, September 12, 2005 3:06 PM -0400 Kevin A. McGrail
[EMAIL PROTECTED] wrote:
However, it's missing the issue that while CNAMEs are not RFC compliant,
people do use them. And I also found a bug where the MX resolution is
supposed to be returned in preference order but it doesn't
KAM wrote:
Thanks for the extra test cases. Assuming they should all fail,
here's my new test stub. Looks good to me. Review and comment
appreciated.
http://www.pccc.com/downloads/MIMEDefang/contrib/check_primary_mx_stub.pl
Comment: not sufficiently general
Failing 127.0.0.1 and
KAM wrote:
Thanks for the extra test cases. Assuming they should all fail,
here's my new test stub. Looks good to me. Review and comment
appreciated.
http://www.pccc.com/downloads/MIMEDefang/contrib/check_primary_mx_stub.pl
Review:
Why do we only care about the first? I'm tempted to
[EMAIL PROTECTED] ([EMAIL PROTECTED]) @ 2005.09.12 12:57:30 -0700:
KAM wrote:
Checking the IP against all of these bad subnets is probably cheap
computationally, as the expensive part is getting the DNS lookup in
the first place.
For a very complete list of bad subnets, check the Bogon IP
On Mon, 2005-09-12 at 14:59, [EMAIL PROTECTED] wrote:
KAM wrote:
Thanks for the extra test cases. Assuming they should all fail,
here's my new test stub. Looks good to me. Review and comment
appreciated.
http://www.pccc.com/downloads/MIMEDefang/contrib/check_primary_mx_stub.pl
Les Mikesell wrote:
Any MX of 127.0.0.1 is not only broken but malicious. However, I'd
expect it to be pretty common to have multiple MX's mixing public
and private targets on the assumption that inside hosts would hit
the working private number and outside hosts would fail and then
connect
On Mon, 12 Sep 2005, David F. Skoll wrote:
Any MX of 127.0.0.1 is not only broken but malicious. However, I'd
expect it to be pretty common to have multiple MX's mixing public
and private targets on the assumption that inside hosts would hit
the working private number and outside hosts would
David F. Skoll wrote:
Les Mikesell wrote:
Any MX of 127.0.0.1 is not only broken but malicious
I would reject mail from a domain that does that.
So in principle...
sub filter_sender
{ ...
if (any_illegal_mxs_for($sender) )
{
# Les-style
The Sef firewall (formally know as raptor) 's mail proxy will reject any
connection (ie drop it once resovled before proxying to the mail server)
that has that set and an MX record, as it considers anything publishing
private address space as suspect.
Cheers
Mack
I would reject mail from a
Any MX of 127.0.0.1 is not only broken but malicious. However, I'd
expect it to be pretty common to have multiple MX's mixing public
and private targets on the assumption that inside hosts would hit
the working private number and outside hosts would fail and then
connect to the public
Exactly. If you need different MX for both inside and outside users, set
up
a split DNS. for the inside users, they ask an internal DNS that answers
with
the internal IPs. The external users query a public DNS that answers with
public IPs.
It's easy to set up and solves a bunch of problems.
No problem and BTW, in fairness to Net::DNS, I'm not sure the bug for
sorting MX's is in Net::DNS or in my interpretation of the documents but
it's easy enough to sort once the answer is returned.
Good catches. It was originally coded just to check for existence (so no
need for priority), with
New version now at
http://www.pccc.com/downloads/MIMEDefang/contrib/check_primary_mx_stub.pl
which takes into account much more of the cases you stated. Thanks for the
feedback and I've added some comments inline below.
Comment: not sufficiently general
I've added a function called invalid_mx
Kevin A. McGrail wrote:
It's easy to set up and solves a bunch of problems. There's no excuse for
publishing RFC1918's IPs in a public DNS
I'm not arguing it's right or good,
I'm arguing that it's wrong and bad.
Publishing RFC1918 addresses as MX hosts means you're willing to let
people send
KAM wrote:
New version now at
http://www.pccc.com/downloads/MIMEDefang/contrib/check_primary_mx_stub.pl
which takes into account much more of the cases you stated. Thanks
for the feedback and I've added some comments inline below.
Beautiful.
One nitpick:
#172.16/12
if ($ip =~
Let me restate my position - It's just not a battle I feel that strongly
about advocating to fight ;-) I'll worry about people doing dumb things
after I worry about people doing malicious things.
But, as always, I appreciate the point of view and discussion. And in
deference, I've added the
Thanks! My brain completely just read that as 172.16/16...
Fixed and again at
http://www.pccc.com/downloads/MIMEDefang/contrib/check_primary_mx_stub.pl
thought I chose to be more explicit in the code than try and use condensed
code though as a personal preference for maintenance.
Regards,
KAM
David F. Skoll wrote:
I'm arguing that it's wrong and bad.
I agree!!!
Whenever I see mail loops back to me (MX problem?) errors I can't help
but think how clueless the domain administrator is for sending that
domains email to an unknown host that can be different on every network.
If they find
On Mon, 2005-09-12 at 16:45, [EMAIL PROTECTED] wrote:
One nitpick:
#172.16/12
if ($ip =~ /^172\.16\./) { # not complete
#return 1;
}
True enough, but actually 172.16/12 includes 172.16-31...
#172.16/12
if ($ip =~ /^172\.(16|17|18|19|2[0-9]|30|31)\./) { # messy?
On Feb 2, 9:20am, [EMAIL PROTECTED] wrote:
} KAM wrote:
} New version now at
} http://www.pccc.com/downloads/MIMEDefang/contrib/check_primary_mx_stub.pl
} which takes into account much more of the cases you stated. Thanks
} for the feedback and I've added some comments inline below.
}
}
--On Monday, September 12, 2005 2:45 PM -0700 [EMAIL PROTECTED]
wrote:
True enough, but actually 172.16/12 includes 172.16-31...
#172.16/12
if ($ip =~ /^172\.(16|17|18|19|2[0-9]|30|31)\./) { # messy?
#return 1;
}
It might be cleaner to simply convert the address to a 32-bit value
Les Mikesell wrote:
On Mon, 2005-09-12 at 14:59, [EMAIL PROTECTED] wrote:
Why do we only care about the first? I'm tempted to say, fail if ANY of
the MX records is invalid. Are there any broken configs out there that
have multirecord MX's with only one of them (not the first) being 127.0.0.1?
[EMAIL PROTECTED] wrote:
Comment: not sufficiently general
Failing 127.0.0.1 and 0.0.0.0 is a good start... but there's all
kinds of invalid IP assignments that are being missed. How often are
they used? I don't know.
...
Checking the IP against all of these bad subnets is probably cheap
On Mon, 2005-09-12 at 17:31, Kelson wrote:
I remember a year or two ago there was a fad in which admins would set
up a tertiary or higher MX pointing to 127.0.0.1 in order to hassle spam
software that used the highest MX instead of the lowest.
I don't know how many of these are still
Joseph,
This looks like a good idea! Where (which routine) did you add this to your
relay? filter_end?
Also, does this stop people from using sendmail directly to send email or
the few local users who might send mail with mutt or pine?
Thanks,
KAM
We've been doing this for quite a while:
On Sun, 2005-09-11 at 13:01, Kevin A. McGrail wrote:
Joseph,
This looks like a good idea! Where (which routine) did you add this to your
relay? filter_end?
Also, does this stop people from using sendmail directly to send email or
the few local users who might send mail with mutt or pine?
--On Friday, September 9, 2005 5:51 PM -0500 Les Mikesell
[EMAIL PROTECTED] wrote:
I think I've seen this mentioned before but can't find the answer. I'm
getting a bunch of spam where the sender MX ends up pointing to
127.0.0.1 or 0.0.0.0. Is there a way to reject this quickly? Not
only
I think I've seen this mentioned before but can't find the answer. I'm
getting a bunch of spam where the sender MX ends up pointing to
127.0.0.1 or 0.0.0.0. Is there a way to reject this quickly? Not
only is there the obvious problem of a bounce, but many of the
destination users have moved and
Les Mikesell wrote:
I think I've seen this mentioned before but can't find the answer.
I'm getting a bunch of spam where the sender MX ends up pointing to
127.0.0.1 or 0.0.0.0. Is there a way to reject this quickly? Not
only is there the obvious problem of a bounce, but many of the
66 matches
Mail list logo
