On 10/24/2006 4:01 PM, John Rudd wrote:
Eric A. Hall wrote:
Note that this is entirely legal, and even necessary:
[ root# ] host 207.65.71.14
14.71.65.207.in-addr.arpa is an alias for 14.in-addr.ntrg.com.
14.in-addr.ntrg.com is an alias for 14.in-addr.labs.ntrg.com.
Eric A. Hall wrote:
On 10/24/2006 4:01 PM, John Rudd wrote:
Eric A. Hall wrote:
Note that this is entirely legal, and even necessary:
[ root# ] host 207.65.71.14
14.71.65.207.in-addr.arpa is an alias for 14.in-addr.ntrg.com.
14.in-addr.ntrg.com is an alias for 14.in-addr.labs.ntrg.com.
...
On 10/23/2006 7:01 PM, John Rudd wrote:
Eric A. Hall wrote:
http://www.ehsco.com/misc/spamassassin/std_compliance.cf might help or
work for what you're doing.
Make sure to read the disclaimers and warnings
Those helped a lot. There's only three checks I can't do with them
(probably
David B Funk wrote:
Some of us pre-date Sir Timothy his bright idea, had to make our
ones zeros the hard way by banging two rocks together, had to learn
to find and read documentation. (I first ran into sendmail on a VAX-750
running BSD-4.2 in the early 80's).
Yeah, I've been doing Sendmail
Eric A. Hall wrote:
a) does the hostname in the PTR record point to a CNAME instead of an A
record
That's not illegal. It's pretty common too, since subnet delegation of
in-addr space only works on /8, /16 and /24 subnets due to the way that
octets are mapped to domain name labels in that
John Rudd wrote:
Eric A. Hall wrote:
On 10/23/2006 7:01 PM, John Rudd wrote:
b) does the hostname contain it's IP address in _hex_ form (instead
of in decimal form, which I've already got working)
I don't recall ever seeing that. If you create a rule for that you might
also want to do
John Rudd wrote:
http://people.ucsc.edu/~jrudd/spamassassin/jr_rfc1912.cf
I had to make an update:
The rule for the hostname having keywords for end clients was case
sensitive (forgot the /i at the end), and I added one more keyword: dip
On 10/23/2006 10:50 PM, John Rudd wrote:
Eric A. Hall wrote:
On 10/23/2006 7:01 PM, John Rudd wrote:
a) does the hostname in the PTR record point to a CNAME instead of an A
record
That's not illegal. It's pretty common too, since subnet delegation of
in-addr space only works on /8, /16
On 10/24/2006 7:55 AM, John Rudd wrote:
Here's an example for one I got tonight (I got 3, but trashed the others
before thinking I should send that as an example).
(i577A0BC3.versanet.de [87.122.11.195])
577A0BC3 is the hex encoding of the IP address, with no separators.
That may be
Eric A. Hall wrote:
On 10/24/2006 7:55 AM, John Rudd wrote:
Here's an example for one I got tonight (I got 3, but trashed the others
before thinking I should send that as an example).
(i577A0BC3.versanet.de [87.122.11.195])
577A0BC3 is the hex encoding of the IP address, with no separators.
Eric A. Hall wrote:
On 10/23/2006 10:50 PM, John Rudd wrote:
Eric A. Hall wrote:
On 10/23/2006 7:01 PM, John Rudd wrote:
a) does the hostname in the PTR record point to a CNAME instead of an A
record
That's not illegal. It's pretty common too, since subnet delegation of
in-addr space
Jo Rhett wrote:
Right. Which proves that you weren't reading. I was replying to the
comment that someone made that any host with more than one address
would have more than one HELO. This isn't true.
Now a host with more than one interface might have more than one helo
name. But that's
Jo Rhett wrote:
Right. Which proves that you weren't reading. I was replying to
the comment that someone made that any host with more than one
address would have more than one HELO. This isn't true.
Now a host with more than one interface might have more than one
helo name. But that's
Eric A. Hall wrote:
http://www.ehsco.com/misc/spamassassin/std_compliance.cf might help or
work for what you're doing.
Make sure to read the disclaimers and warnings
Those helped a lot. There's only three checks I can't do with them
(probably need to use a plugin for it):
a) does the
On 10/23/2006 7:01 PM, John Rudd wrote:
Eric A. Hall wrote:
http://www.ehsco.com/misc/spamassassin/std_compliance.cf might help or
work for what you're doing.
Make sure to read the disclaimers and warnings
Those helped a lot. There's only three checks I can't do with them
(probably
Eric A. Hall wrote:
On 10/23/2006 7:01 PM, John Rudd wrote:
Eric A. Hall wrote:
http://www.ehsco.com/misc/spamassassin/std_compliance.cf might help or
work for what you're doing.
Make sure to read the disclaimers and warnings
Those helped a lot. There's only three checks I can't do with them
John Rudd wrote:
Eric A. Hall wrote:
On 10/23/2006 7:01 PM, John Rudd wrote:
Eric A. Hall wrote:
http://www.ehsco.com/misc/spamassassin/std_compliance.cf might help or
work for what you're doing.
Make sure to read the disclaimers and warnings
Those helped a lot. There's only three checks
On Mon, 23 Oct 2006, Jo Rhett wrote:
David B Funk wrote:
On Thu, 19 Oct 2006, Jo Rhett wrote:
Richard Frovarp wrote:
Or for any machine that hosts more domains than has IPs. Even being able
to edit the reverse doesn't mean it will always be the same.
How many different names does
: SpamAssassin Users
Subject: Re: Scoring PTR's
http://www.ehsco.com/misc/spamassassin/std_compliance.cf might help or
work for what you're doing.
Make sure to read the disclaimers and warnings
--
Eric A. Hall
http://www.ehsco.com/
Internet Core Protocols
http://www.oreilly.com/catalog/coreprot/
-Original Message-
From: Matt Kettler [mailto:[EMAIL PROTECTED]
Sent: donderdag 19 oktober 2006 6:40
To: Mark
Cc: users@spamassassin.apache.org
Subject: Re: Scoring PTR's
Yes, a very bad idea. And a mite on the side of RFC ignorance. :)
mail.apache.org is the HELO name
Title: RE: Scoring PTR's
That is what I thought but the :EvalTests
modules are not documented. Then I thought maybe a rule that compares the two
names on the Received: line because the PTR always falls after
the ( and before the [. Also, The broadcast name
always comes after Received: from
Robert Swan wrote:
Guys, I don't need a lesson on what you think should be done or what you
think is the right thing to do, I just need help writing a rule. I setup
mail servers all the time and I always make sure the: Mail server
broadcast name, the 'A' record and the PTR all match, IT IS JUST
Jo Rhett wrote:
Robert Swan wrote:
Guys, I don't need a lesson on what you think should be done or what you
think is the right thing to do, I just need help writing a rule. I setup
mail servers all the time and I always make sure the: Mail server
broadcast name, the 'A' record and the PTR all
Jo Rhett wrote:
Just FYI, this score will be a Tax on everyone who has a provider who
won't let them edit the reverse DNS. IE, most cable and DSL providers
on the market.
Richard Frovarp wrote:
Or for any machine that hosts more domains than has IPs. Even being able
to edit the reverse
Jo wrote:
I setup mail servers all the time and I always make sure the
Mail server broadcast name, the 'A' record and the PTR all match,
IT IS JUST GOOD PRACTICE.
No, it's NOT good practice. Seriously. Without battering the point, it's
really perfectly legit for an MTA to use different
Mark wrote:
No, it's NOT good practice. Seriously. Without battering the point, it's
really perfectly legit for an MTA to use different HELO names (say, based
on hosting of virtual servers), whilst the IP address for that MTA has a
OK, we recognize the existence of virtual hosts. I know
*cirencester.co.uk*(*c204131.adsl.hansenet.de*[213.39.204.131])
Clearly, the PTR used here indicates a dynamic IP address. That may prompt
an immediate reaction. But Richard gave a good example:
Received: from mail.apache.org (hermes.apache.org [209.237.227.199])
There is really
PROTECTED]
Sent: Thursday, October 19, 2006 4:05 PM
To: users@spamassassin.apache.org
Subject: RE: Scoring PTR's
*cirencester.co.uk*(*c204131.adsl.hansenet.de*[213.39.204.131])
Clearly, the PTR used here indicates a dynamic IP address. That may
prompt
an immediate reaction. But Richard gave
Robert,
I think what you might find more useful is to look at the First
Received Header Only thread on this list from Oct 8th and 9th.
If you write the rule the way you plan to, you'll be checking _every_
received header. That's not good. For example, some end client does a
SMTP-AUTH to
Jo Rhett wrote:
Robert Swan wrote:
Guys, I don't need a lesson on what you think should be done or what you
think is the right thing to do, I just need help writing a rule. I setup
mail servers all the time and I always make sure the: Mail server
broadcast name, the 'A' record and the PTR all
Mark wrote:
Jo wrote:
I setup mail servers all the time and I always make sure the
Mail server broadcast name, the 'A' record and the PTR all match,
IT IS JUST GOOD PRACTICE.
No, it's NOT good practice. Seriously. Without battering the point, it's
really perfectly legit for an MTA to use
John Rudd wrote:
That's why their ISP has a mail server. They shouldn't be directly
connecting to my mail server if they don't have proper reverse DNS set
up. If they're too pig-headed to use their ISP's mail server, then
that's their problem.
Not all ISPs provide e-mail servers,
Robert Swan wrote:
Guys, if my mail server announces itself as mail.somename.com and has a
PTR that matches. I can send mail out as [EMAIL PROTECTED] or
[EMAIL PROTECTED] as long as the MX record for the domain
anothername.com reads as mail.somename.com
The original questions was how do I
-Original Message-
From: John Rudd [mailto:[EMAIL PROTECTED]
Sent: donderdag 19 oktober 2006 22:49
To: Mark
Cc: users@spamassassin.apache.org
Subject: Re: Scoring PTR's
I setup mail servers all the time and I always make sure the
Mail server broadcast name, the 'A' record
Mark wrote:
I setup mail servers all the time and I always make sure the
Mail server broadcast name, the 'A' record and the PTR all
match, IT IS JUST GOOD PRACTICE.
No, it's NOT good practice. Seriously. Without battering
the point, it's really perfectly legit for an MTA to use different
HELO
On Thu, 19 Oct 2006, Jo Rhett wrote:
Richard Frovarp wrote:
Or for any machine that hosts more domains than has IPs. Even being able
to edit the reverse doesn't mean it will always be the same.
How many different names does your mailserver use in its HELO?
And what mailserver is that?
http://www.ehsco.com/misc/spamassassin/std_compliance.cf might help or
work for what you're doing.
Make sure to read the disclaimers and warnings
--
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols
Robert Swan wrote:
OK the rule to block an unknown or a mail server without a PTR works
great:
*header LOCAL_INVALID_PTR2 Received =~ /from \S+ \(unknown /*
*score LOCAL_INVALID_PTR2 2*
*describe LOCAL_INVALID_PTR2 Header contains no PTR2*
Now how can I make a
-Original Message-
From: Richard Frovarp [mailto:[EMAIL PROTECTED]
Sent: donderdag 19 oktober 2006 1:02
To: users@spamassassin.apache.org
Subject: Re: Scoring PTR's
Now how can I make a rule to score if the PTR is different than
the reported mail server like the SPAMMER
Mark wrote:
Received: from mail.apache.org (hermes.apache.org [209.237.227.199])
Here we're lucky and the domain is at least the same, but there is no
need for that to even happen. Especially then you think about virtual
hosting.
Yes, a very bad idea. And a mite on the side of RFC
40 matches
Mail list logo