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/
RFC 2821 Section 4.1.4 Order of Commands
...
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails:
On 10/20/2006 10:43 AM, Giampaolo Tomassoni wrote:
RFC 2821 Section 4.1.4 Order of Commands ...
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
-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
*[213.39.204.131])
Robert
Peace he would say instead of goodbyepeace my brother.
-Original Message-
From: Richard Frovarp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 18, 2006 7:02 PM
To: users@spamassassin.apache.org
Subject: Re: Scoring PTR's
Robert Swan wrote
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
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 GOOD
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
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 a good example:
Received: from mail.apache.org (hermes.apache.org
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,
The statement you're replying to doesn't say anything about the HELO
string. It says the PTR and A records should match (and they SHOULD).
Oh, come on. Which RFC states that?
This doesn't bother virtual domains at all.
For example:
IP addr A.B.C.D might have a PTR return
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
Giampaolo Tomassoni wrote:
The statement you're replying to doesn't say anything about the HELO
string. It says the PTR and A records should match (and they SHOULD).
Oh, come on. Which RFC states that?
RFC 1912, section 2.1, 2nd paragraph:
Make sure your PTR and A records match. For
-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
Mark wrote:
-Original Message-
From: John Rudd [mailto:[EMAIL PROTECTED]
Sent: donderdag 19 oktober 2006 23:38
To: Giampaolo Tomassoni
Cc: users@spamassassin.apache.org
Subject: Re: R: Scoring PTR's
RFC 1912, section 2.1, 2nd paragraph:
Make sure your PTR and A records match
Giampaolo Tomassoni wrote:
The statement you're replying to doesn't say anything about the HELO
string. It says the PTR and A records should match (and they SHOULD).
Oh, come on. Which RFC states that?
RFC 1912, section 2.1, 2nd paragraph:
Make sure your PTR and A records
He's trying to spread his own spamtrap!
giampaolo
-Messaggio originale-
Da: Mark [mailto:[EMAIL PROTECTED]
Inviato: giovedì 19 ottobre 2006 23.46
A: users@spamassassin.apache.org
Oggetto: RE: Scoring PTR's
-Original Message-
From: John Rudd [mailto:[EMAIL PROTECTED
Mark wrote:
-Original Message-
From: John Rudd [mailto:[EMAIL PROTECTED]
Sent: vrijdag 20 oktober 2006 0:18
To: Mark
Cc: users@spamassassin.apache.org
Subject: Re: R: Scoring PTR's
I now see the cause of your confusion. Make sure your PTR
and A records match, in this context, means
Actually, by definition they are supposed to match A to PTR and PTR to A.
Just because everyone doesn't do it perfectly does not mean it is correct to
not do reverse DNS or to not do it correctly.
There are variations on best practices. Oh well...
RFC 1123 says you should not reject based
This suggestion has been superceded, or perhaps better elucidated, by
later RFC's, particularly RFC 2181, section 10.2.
Nowadays many of us have reverse-DNS delegation in place since as an
end-user we have no control over the in-addr.arpa records for our
particular IP subnet. For
On Thu, 19 Oct 2006, R Lists06 wrote:
RFC 1123 says you should not reject based upon HELO
Bah. If some mechine I don't control tries to HELO
whatever.impsec.org I'm absolutely going to tell them to go away.
--
John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/
[EMAIL
RFC 1123 says you should not reject based upon HELO
Bah. If some mechine I don't control tries to HELO
whatever.impsec.org I'm absolutely going to tell them to go away.
--
John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/
what program is doing the rejection
R Lists06 wrote:
Nothing personal, yet that is some messed up reverse dns delegation.
Perhaps, but RIPE, for instance, calls RFC2317, which proposed this
method, a Best Current Practices RFC:
http://www.ripe.net/rs/reverse/infosources.html
I also skimmed the list of complaints about this
On Thu, 19 Oct 2006, John D. Hardin wrote:
On Thu, 19 Oct 2006, R Lists06 wrote:
RFC 1123 says you should not reject based upon HELO
Bah. If some machine I don't control tries to HELO
whatever.impsec.org I'm absolutely going to tell them to go away.
what program is doing the
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
On 10/19/2006 7:11 PM, John Rudd wrote:
It is my observation that the messages which come from an immediately
relay that:
A) does not have a PTR record, or
B) has forged DNS (PTR record doesn't lead to an A record which
resolves back to the SMTP client's IP address), or
C) has a
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 rule to score if the PTR is different
than
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
59 matches
Mail list logo
