Re: Scoring PTR's
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. 14.in-addr.labs.ntrg.com domain name pointer bulldog.labs.ntrg.com. All of that's ok. The question is: is bulldog.labs.ntrg.com an A record, or a CNAME record? That's the thing I have been testing for (is it a CNAME). That's the thing that RFC1912 doesn't like (the PTR record itself, not merely in-addr.arpa aliases that eventually get to the PTR record, but the PTR record itself, may not _refer_to_ a CNAME record, it must refer to an A record) There's nothing that prohibits the target domain name entry of a PTR from having a CNAME record. A PTR is just "a pointer to some other domain name". The target domain name can have whatever records the owner feels they need. It's probably something that should be discouraged, since additional processing would be needed to obtain a complete answer, but on its face it's not illegal (again RFC1912 is informational, is not authoritative, and has significant errors). You'd probably need a plugin to check for this, since you'd need to generate your own query for the RRs associated with the target domain name in order to get a definitive answer. I'm not really sure this would be reliable spam-sign. I can imagine some legitimate uses for this. Like I said, it hasn't shown up in the my logs in the 15 or so months I've been testing it. Which means it is: a) probably not as used as you're saying b) definitely not a useful test for what I'm doing Though, I do think I need to build a plugin for the "hostname contains hex encoded IP address" check. I just need to know where to start on building a plugin, and being sure it can see the pseudo-headers. I think I saw a little bit about that on the wiki for the first part, but I have no idea about the second part (accessing the pseudo-headers from within a plugin). John
Re: Scoring PTR's
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. >> 14.in-addr.labs.ntrg.com domain name pointer bulldog.labs.ntrg.com. > > All of that's ok. The question is: > > is bulldog.labs.ntrg.com an A record, or a CNAME record? > > That's the thing I have been testing for (is it a CNAME). That's the > thing that RFC1912 doesn't like (the PTR record itself, not merely > in-addr.arpa aliases that eventually get to the PTR record, but the PTR > record itself, may not _refer_to_ a CNAME record, it must refer to an A > record) There's nothing that prohibits the target domain name entry of a PTR from having a CNAME record. A PTR is just "a pointer to some other domain name". The target domain name can have whatever records the owner feels they need. It's probably something that should be discouraged, since additional processing would be needed to obtain a complete answer, but on its face it's not illegal (again RFC1912 is informational, is not authoritative, and has significant errors). You'd probably need a plugin to check for this, since you'd need to generate your own query for the RRs associated with the target domain name in order to get a definitive answer. I'm not really sure this would be reliable spam-sign. I can imagine some legitimate uses for this. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Scoring PTR'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 not 1000:1 kind of ratios. On Oct 24, 2006, at 2:58 PM, mouss wrote: There is no requirement that limits the number of helonames, as far as they all resolve to the outgoing IP. Some hosters want this so that outgoing mail contains per-customer headers. They may be wrong, but it'll be hard to convince them that they are. I wouldn't try. It's fine to me if they do. The point was that the original poster was complaining about having to match PTR->A and that it isn't always possible. I simply asked how many HeloNames he was trying to use. If he wants to have 1000 HeloNames, then he'll (a) need to customize his e-mail software and (b) need to find a way to make the A<->PTRs all match up. There are better ways to do this. A->PTR matching is not a steep requirement unless you try to do this all back-asswards :-) -- Jo Rhett Senior Network Engineer Network Consonance
Re: Scoring PTR'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 not 1000:1 kind of ratios. There is no requirement that limits the number of helonames, as far as they all resolve to the outgoing IP. Some hosters want this so that outgoing mail contains per-customer headers. They may be wrong, but it'll be hard to convince them that they are.
Re: Scoring PTR's
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 only works on /8, /16 and /24 subnets due to the way that octets are mapped to domain name labels in that hierarchy. RFC 1912 says "don't do that" :-) RFC1912 is informational non-authoritative. It has some big errors (ie, it says a label may not be all-numeric, which is wrong). Though, honestly, I've yet to see it actually get triggered in my mimedefang filter, so I don't mind losing it. Can you clarify what you are looking for here? 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. 14.in-addr.labs.ntrg.com domain name pointer bulldog.labs.ntrg.com. All of that's ok. The question is: is bulldog.labs.ntrg.com an A record, or a CNAME record? That's the thing I have been testing for (is it a CNAME). That's the thing that RFC1912 doesn't like (the PTR record itself, not merely in-addr.arpa aliases that eventually get to the PTR record, but the PTR record itself, may not _refer_to_ a CNAME record, it must refer to an A record)
Re: Scoring PTR's
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. That may be spam-sign, but unless there's something more than what you're showing it's not a standards violation. Yes, not all of my tests are standards violations. The point of the tests is: identifying likely spam-bots, and flagging their messages for review.
Re: Scoring PTR's
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 spam-sign, but unless there's something more than what you're showing it's not a standards violation. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Scoring PTR's
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 and /24 subnets due to the way that >> octets are mapped to domain name labels in that hierarchy. > > RFC 1912 says "don't do that" :-) RFC1912 is informational non-authoritative. It has some big errors (ie, it says a label may not be all-numeric, which is wrong). > Though, honestly, I've yet to see it actually get triggered in my > mimedefang filter, so I don't mind losing it. Can you clarify what you are looking for here? 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. 14.in-addr.labs.ntrg.com domain name pointer bulldog.labs.ntrg.com. In that example, the entry for 14.71.65.207.in-addr.arpa. has a CNAME RR pointing to 14.in-addr.ntrg.com. (the entry has been delegated to my zone using a CNAME), which in turn aliases to 14.in-addr.labs.ntrg.com., which in turn has a PTR record that resolves to bulldog.labs.ntrg.com. A "PTR" record is just "a pointer to some other domain name" and only has semantic meaning when lookups are keyed to a name in the in-addr.arpa. hierarchy. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Scoring PTR's
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
Re: Scoring PTR's
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 octal notations too, which is another valid address encoding syntax that should never appear naturally. I see it in about 10% of cases where the IP address is in the hostname. 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.
Re: Scoring PTR's
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 hierarchy. No. A CNAME can point to anything, but nothing can refer to a CNAME. -- Jo Rhett Network/Software Engineer Net Consonance
Re: Scoring PTR's
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 about that long too. I always used to
handcraft my sendmail configs until I finally gave in to m4 a few years
ago. Bragging aside, can we get back on topic?
In every sendmail release for the last decade there's been a document
"doc/op/op.me" which is the configuration and operations manual. In that
doc for 8.13.* you'll find:
Which is *ALWAYS* way out of date, and had *NO* mention of HeloName. I
checked that.
> h use name of interface for HELO command
If ``h'' is set, the name corresponding to
the outgoing interface address (whether cho-
sen via the Connection parameter or the
default) is used for the HELO/EHLO command.
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 not 1000:1 kind of ratios.
Now if the only way you can relate to things is via a web-page then
look at: http://www.sendmail.org/doc/sendmail-current/doc/op/op.pdf
Better yet, I can read the thread and reply to the topic at hand.
Looking at the code, heloname would appear to be statically defined,
I'm not sure what your strong points are Jo, but reading 'c' code doesn't
appear to be one of them. I made no mention of 'heloname' ('c' is case
sensitive). In the sendmail source file readcf.c the variable 'HeloName'
is assigned a value in the case statement:
case O_HELONAME:
HeloName = newstr(val);
break;
Yes. Once. It doesn't alter based on input for each message. Thus
it's static for the lifetime of the process.
I'm done taking your bullshit. You didn't read the original topic, and
your blatant attacks are doing nothing but prove that in addition to
failing to read the topic, you're too stupid to check the contributors
to sendmail before you sent me ad hoc attacks about things I know very
well better than you do.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: Scoring PTR's
>... >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 need to use a plugin for it): >> >> 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 hierarchy. > Eric, I think you either misread, or have it backwards; Indeed a PTR to a CNAME is illegal (RFC not on the fingertips at the moment). What is *very* common is a CNAME to a PTR (which *is* legal). Example: % host 64.32.188.109 109.188.32.64.in-addr.arpa is an alias for 109.104/29.188.32.64.in-addr.arpa. 109.104/29.188.32.64.in-addr.arpa domain name pointer smtp.mpa0.Plectere.COM. >> 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 octal notations too, which is another valid address >encoding syntax that should never appear naturally. > >> c) does the hostname in the PTR record actually going to an A record >> which includes the relay's IP addr > >that's a reasonable test Also called FCrDNS (i.e. "Full Circle reverse DNS"). > >-- >Eric A. Hallhttp://www.ehsco.com/ >Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > Paul Shupak [EMAIL PROTECTED]
Re: Scoring PTR's
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 your mailserver use in its HELO?
> >>
> >> And what mailserver is that? That's not possible in qmail, postfix,
> >> sendmail, et al...
> >
> > You're a bit behind the times Jo, check out the 'h' argument to
> > 'ClientPortOptions' or the 'HeloName' variable in sendmail 8.13.
>
> I can find no documentation of either. Googling just gets me lots of
> examples of a script called SendMail()
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).
In every sendmail release for the last decade there's been a document
"doc/op/op.me" which is the configuration and operations manual. In that
doc for 8.13.* you'll find:
ClientPortOptions=options
[O] Set client SMTP options. The options
are key=value pairs separated by commas.
Known keys are:
Port Name/number of source port for connection
(defaults to any free port)
Addr Address mask (defaults INADDR_ANY)
FamilyAddress family (defaults to INET)
SndBufSizeSize of TCP send buffer
RcvBufSizeSize of TCP receive buffer
Modifier Options (flags) for the client
The Address mask may be a numeric address in
dot notation or a network name. Modifier
can be the following character:
h use name of interface for HELO command
A don't use AUTH when sending e-mail
S don't use STARTTLS when sending e-mail
If ``h'' is set, the name corresponding to
the outgoing interface address (whether cho-
sen via the Connection parameter or the
default) is used for the HELO/EHLO command.
Now if the only way you can relate to things is via a web-page then
look at: http://www.sendmail.org/doc/sendmail-current/doc/op/op.pdf
> Looking at the code, heloname would appear to be statically defined,
I'm not sure what your strong points are Jo, but reading 'c' code doesn't
appear to be one of them. I made no mention of 'heloname' ('c' is case
sensitive). In the sendmail source file readcf.c the variable 'HeloName'
is assigned a value in the case statement:
case O_HELONAME:
HeloName = newstr(val);
break;
where 'val' is the token that has just been parsed out of the config file.
(not a static definition).
> which brings me back to my original point: how many names does his
> mailserver use in helo?
>
> Sure, if it has 3 interfaces (and uses them all) then he'll need three
> names. But he won't need 1000 or however many virtual hosts he has...
If that was your point, then why did you make that bogus assertion that
it wasn't possible for MTAs (at least sendmail) to use different HELO names?
And if he wants to use TLS-SSL then he'll have to have a different
interface and matching name for each virtual host.
My whole point here was not to make you look foolish but to point
out that maybe you should stop and think a bit more before going off
and making unsupportable statements.
For example, a while back you were complaining about a FP from a bank
anti-phisihing rule. It was probably caused by that defective milter you
were using. A bit of digging (rather than ranting) might have shown
you something that other sendmail-2-SA milter authors found out years
ago, the need for that added 'Received:' header.
--
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: Scoring PTR's
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 I can't do with them >>> (probably need to use a plugin for it): >>> >>> 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 hierarchy. > > RFC 1912 says "don't do that" :-) > And RFC 2317 says "Do that". http://www.faqs.org/rfcs/rfc2317.html
Re: Scoring PTR's
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 (probably need to use a plugin for it): 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 hierarchy. RFC 1912 says "don't do that" :-) Though, honestly, I've yet to see it actually get triggered in my mimedefang filter, so I don't mind losing it. 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 octal notations too, which is another valid address encoding syntax that should never appear naturally. I see it in about 10% of cases where the IP address is in the hostname. c) does the hostname in the PTR record actually going to an A record which includes the relay's IP addr that's a reasonable test
Re: Scoring PTR's
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 need to use a plugin for it): > > 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 hierarchy. > 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 octal notations too, which is another valid address encoding syntax that should never appear naturally. > c) does the hostname in the PTR record actually going to an A record > which includes the relay's IP addr that's a reasonable test -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Scoring PTR'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 hostname in the PTR record point to a CNAME instead of an A record b) does the hostname contain it's IP address in _hex_ form (instead of in decimal form, which I've already got working) c) does the hostname in the PTR record actually going to an A record which includes the relay's IP addr Short of those things, I think this works the way I want it to: http://people.ucsc.edu/~jrudd/spamassassin/jr_rfc1912.cf Now I just need to decide if getting those other 3 items in place is worth the time I'd spend learning to write a plugin. Probably is, since it's learning... but I'm not sure I have the time to actually do it.
Re: Scoring PTR's
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 your mailserver use in its HELO? And what mailserver is that? That's not possible in qmail, postfix, sendmail, et al... You're a bit behind the times Jo, check out the 'h' argument to 'ClientPortOptions' or the 'HeloName' variable in sendmail 8.13. I can find no documentation of either. Googling just gets me lots of examples of a script called SendMail() Looking at the code, heloname would appear to be statically defined, which brings me back to my original point: how many names does his mailserver use in helo? Sure, if it has 3 interfaces (and uses them all) then he'll need three names. But he won't need 1000 or however many virtual hosts he has... -- Jo Rhett Network/Software Engineer Net Consonance
Re: R: R: Scoring PTR's
>... >> 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: the information about verification >>failure is for logging and tracing only. >> ... >> >> It can mean whatever you like (do note "MAY" and "MUST NOT" though). > >It just mean you can't drop a message based solely on the parameter of the >EHLO command. You MAY check it, if you like to. But you MUST NOT drop it. > > >> >> Paul Shupak >> [EMAIL PROTECTED] > > > I did say it could mean whatever you wanted:-) It says nothing about dropping any message. It says only that you "MUST NOT refuse to accept a message" because the EHLO argument doesn't match the client's IP - read later in the same document that you could always: 550 I do not like you. And as long as the cause above was not the reason, the clause above would not be violated. I'll leave for another day and another argument whether or not if the cause above contributed to a weighted system, and the message would not have otherwise been refused, it would be a violation of either the letter or spirit of the RFC to reject it (if it would have been rejected for another reason or set of reasons, the argument is moot). Oh, and no RFC says your "administrative policies" have to be reasonable or even rational (i.e. you can be an idiot, yet still not violate any RFC - no implications about anyone in particular:). Dropping a message is always to be avoided (the valid reasons are mostly the causes for DSNs that are not controversial). Free free to drop, mark-up, deliver by avian carrier or quarantene any messages you choose, except maybe some of those to role accounts (and that's a separate argument too). Paul Shupak [EMAIL PROTECTED]
Re: R: R: Scoring PTR's
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 >> reason if the verification fails: the information about verification >> failure is for logging and tracing only. ... >> >> It can mean whatever you like (do note "MAY" and "MUST NOT" though). > > It just mean you can't drop a message based solely on the parameter of > the EHLO command. You MAY check it, if you like to. But you MUST NOT > drop it. 2821 is for implementors, not operators. Software developers must not automatically drop mail for this reason -->as a matter of design<-- but as an operator you can do whatever you want with any piece of mail. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
R: R: Scoring PTR's
> 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: the information about verification >failure is for logging and tracing only. > ... > > It can mean whatever you like (do note "MAY" and "MUST NOT" though). It just mean you can't drop a message based solely on the parameter of the EHLO command. You MAY check it, if you like to. But you MUST NOT drop it. > > Paul Shupak > [EMAIL PROTECTED]
RE: R: Scoring PTR's
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: the information about verification failure is for logging and tracing only. ... It can mean whatever you like (do note "MAY" and "MUST NOT" though). Paul Shupak [EMAIL PROTECTED]
RE: Scoring PTR's
This is exactly what I was looking for.although I did enjoy the flame war Robert Peace he would say instead of goodbyepeace my brother. -Original Message- From: Eric A. Hall [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 1:07 AM To: Robert Swan Cc: 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/
Re: R: R: Scoring PTR's
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 hostname that appears to be an end-client of some other > network than my own (contains its own IP addr in the hostname, contains > words like "dynamic", "dsl", "dial-up", etc.) > > are generating spam. It's a bigger list than that but yeah. My theory is that if they can't get their network configured, no telling what else is broken, so I flag it. > In order to exempt my own legitimate users, I skip the check if they're > on my IP block OR if they do SMTP-AUTH. I've got two listeners, one for SMTP 25, one for SUBMIT 587. The latter only allows authenticated sessions. Mail sent to the former is heavily inspected while the session is action, while mail to the latter bypasses the filters altogether. > The one thing I'm thinking about changing is, at home I _reject_ > messages that fail these checks (using filter_sender in mimedefang). > I'm thinking that, for the production systems at work, just to cover > that incredibly small percentage of people who can't or wont use their > ISP's mail server or do SMTP-AUTH, I'll merely quarantines their > messages, via spam assassin score, instead of rejecting them. Yeah, I moved almost everything out of postfix and into spamassassin so that I could work on probability instead of binary. Just make sure to whitelist all traffic for any mailing list that you're on, possibly including to/cc whitelists. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Scoring PTR's
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? That's not possible in qmail, postfix,
> sendmail, et al...
You're a bit behind the times Jo, check out the 'h' argument to
'ClientPortOptions' or the 'HeloName' variable in sendmail 8.13.
--
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: R: Scoring PTR's
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 rejection though?
>
> milter-regex
Doesn't even have to be that fancy, can be done with simple sendmail
rules. If any remote system HELOs to one of our MXs with one of our
domain names or IP-addr-literals, it'll tell them to go away.
I've also taken it one step further and built up a list of common
well-known sites (EG "aol.com", "hotmail.com", "yahoo.com" etc).
If a remote site uses one of those names in its HELO then their rdns
better point back to that same domain.
Slam the door at the SMTP level and don't even waste time on SA.
I also used to check for such bogus HELOs as 'localhost' and
'localhost.localdomain' but there were far too many FPs due to
semi-clueless ISP admins. ;(
Note that I do run a MSA with SMTP-AUTH for our road-warriors
and that system is configured with "AllowBogusHELO=True" ;)
--
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: R: Scoring PTR's
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 rejection though? milter-regex > Doesn't say you cant, just says you shouldn't. Yeah. -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- ...the Fates notice those who buy chainsaws... -- www.darwinawards.com --- 12 days until Halloween
Re: R: Scoring PTR's
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 procedure at http://homepages.tesco.net/J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html, but he mostly argues that RFC2317 delegation makes life more difficult for people maintaining servers running Microsoft DNS or Dan Bernstein's djbdns. He'd prefer a scheme where the upstream provider aliases every single address, not subnet blocks. When Microsoft or djbdns become the dominant name servers on the Internet, perhaps we'll all need to change. Until then, the millions of us running BIND will probably stick with RFC2317 delegation.
RE: R: Scoring PTR's
> > > 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 though? Doesn't say you cant, just says you shouldn't. And it is old old old. Was the rfc revised? - rh -- Robert - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
RE: R: Scoring PTR's
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 PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- ...the Fates notice those who buy chainsaws... -- www.darwinawards.com --- 12 days until Halloween
RE: R: Scoring PTR's
> > 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 instance, mail.cyways.com resolves to > 12.148.244.151, but a reverse query for that address yields: > > # host -t ptr 151.244.148.12.in-addr.arpa > 151.244.148.12.in-addr.arpa is an alias for > 151.128/27.244.148.12.in-addr.arpa. > 151.128/27.244.148.12.in-addr.arpa domain name pointer mail.cyways.com. > > That's because the 244.148.12.in-addr.arpa zone belongs to our provider > (AT&T), but they have delegated our /27 subnet's zone to us via this > aliasing process. RFC 2181 makes clear that aliasing is fine in the PTR > resolution process as long as the aliasing eventually points to a > canonical name like mail.cyways.com. > > This is a much better solution than requiring us to go to the provider to > update their PTR records every time we change the names of the hosts in > our subnet. RFC's like 1912 reflect a time when most people had control > over both forward and reverse name service for a class-A, B, or C IP > block. That came to an end when "classless," or "CIDR," addressing > became the norm. > > > Peter Delegation of reverse DNS is not hard at any size block of IP addresses if the authoritative company will allow your name servers to be authoritative "correctly" It may say it is ok, yet it isn't ok. Nothing personal, yet that is some messed up reverse dns delegation. They do not have to alias anything other than authority. $ dig -x 12.148.244.151 ; <<>> DiG 9.2.4 <<>> -x 12.148.244.151 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18524 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;151.244.148.12.in-addr.arpa. IN PTR ;; ANSWER SECTION: 151.244.148.12.in-addr.arpa. 172800 IN CNAME 151.128/27.244.148.12.in-addr.arpa. 151.128/27.244.148.12.in-addr.arpa. 43200 IN PTR mail.cyways.com. ;; AUTHORITY SECTION: 128/27.244.148.12.in-addr.arpa. 43200 IN NS ns.cfmr.com. 128/27.244.148.12.in-addr.arpa. 43200 IN NS ns.cyways.com. 128/27.244.148.12.in-addr.arpa. 43200 IN NS ns2.cyways.com. ;; ADDITIONAL SECTION: ns.cfmr.com.172800 IN A 12.148.244.131 ns.cyways.com. 86400 IN A 12.148.244.151 ns2.cyways.com. 86400 IN A 12.148.244.157 - rh -- Robert - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
RE: R: Scoring PTR's
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 upon HELO Lord knows if that was stomped on by a later RFC. - rh -- Robert - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
Re: R: R: Scoring PTR's
Giampaolo Tomassoni wrote: But... this is automaticly enforced by most ISPs. What's the meaning of this?!? Suppose I have this in my virtual domain yoyodine.com: @ MX 10 mta.yoyodine.com. mta A 1.2.3.4 When my MTA connects to your, your see that I'm connecting from 1.2.3.4, issues a DNS PTR request 4.3.2.1.in-addr.arpa. and obtains, say, c4-l3-t2.isp.net. Then, if your MTA issues a DNS A request for c4-l3-t2.isp.net and my ISP is not that bad (i.e.: it follows your guidelines), your MTA should get a 1.2.3.4 reply. Your MTA ends saing "Ok". If the client's ISP is not rfc-1912-conformant, your MTA says: "Bad". So, what's the purpose of this? Penalize people who got a rfc-1912 non-conforming ISP? 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 hostname that appears to be an end-client of some other network than my own (contains its own IP addr in the hostname, contains words like "dynamic", "dsl", "dial-up", etc.) are generating spam. The reason is: they're spam/virus -bots that spewing infection at every mail server to which they can get a connection. I have yet to come across an exception to my observation (for my own experience). I have been compiling this observation for 2 years, and practicing it on my home server for 15 months. I plan to put it into production at work in 3 months. Enforcing the RFC 1912 guideline, in a strict interpretation, supports A and B. If the SMTP client passes A and B, I can then comfortably use that hostname for the check in C. In order to exempt my own legitimate users, I skip the check if they're on my IP block OR if they do SMTP-AUTH. The one thing I'm thinking about changing is, at home I _reject_ messages that fail these checks (using filter_sender in mimedefang). I'm thinking that, for the production systems at work, just to cover that incredibly small percentage of people who can't or wont use their ISP's mail server or do SMTP-AUTH, I'll merely quarantines their messages, via spam assassin score, instead of rejecting them. Thus my interest in moving this to SA rules and/or plugin.
Re: R: Scoring PTR's
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, exactly as the RFC states, that "For every IP address, there should be a matching PTR record in the in-addr.arpa domain." And "That all IP addresses have a corresponding PTR record." AND that the PTR record point back to a valid A record. Further into the same paragraph it says: Also, PTR records must point back to a valid A record, Given that the point of this paragraph is "Make sure your PTR and A records match", I would comfortably assert that one necessary element to making this A record "valid" is that at least one such A record from that hostname matches the IP address for that PTR record. That does NOT mean that other A records cannot resolve to, and thus be used for, the same IP address. Show me where I said that was prohibited. Then be sure you go and read all of the places I've said that is allowed.
Re: R: Scoring PTR's
John Rudd wrote: RFC 1912, section 2.1, 2nd paragraph: PTR records must point back to a valid A record, not a alias defined by a CNAME. 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 instance, mail.cyways.com resolves to 12.148.244.151, but a reverse query for that address yields: # host -t ptr 151.244.148.12.in-addr.arpa 151.244.148.12.in-addr.arpa is an alias for 151.128/27.244.148.12.in-addr.arpa. 151.128/27.244.148.12.in-addr.arpa domain name pointer mail.cyways.com. That's because the 244.148.12.in-addr.arpa zone belongs to our provider (AT&T), but they have delegated our /27 subnet's zone to us via this aliasing process. RFC 2181 makes clear that aliasing is fine in the PTR resolution process as long as the aliasing eventually points to a canonical name like mail.cyways.com. This is a much better solution than requiring us to go to the provider to update their PTR records every time we change the names of the hosts in our subnet. RFC's like 1912 reflect a time when most people had control over both forward and reverse name service for a class-A, B, or C IP block. That came to an end when "classless," or "CIDR," addressing became the norm. Peter
I got it! (Was: R: Scoring PTR's)
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] > > 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 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 names (say, based on hosting of virtual servers), whilst the > > > IP address for that MTA has a "fixed" PTR. > > > > The statement you're replying to doesn't say anything about the HELO > > string. > > Oh? The OP's example was: > > cirencester.co.uk (c204131.adsl.hansenet.de [213.39.204.131]) > > Here, "cirencester.co.uk" is the HELO name; and "c204131.adsl.hansenet.de" > the PTR. Similarly, in the line: > > Received: from mail.apache.org (hermes.apache.org [209.237.227.199]) > > "mail.apache.org" was the supplied HELO name, whereas the connecting IP > address resolves to "hermes.apache.org". > > > ... It says the PTR and A records should match (and they SHOULD). > > Oh? An IP address lookup will give you a single PTR; but many domains can > be registered in DNS with the same IP address, of course. An A record > lookup for "mail.apache.org" resolves to 209.237.227.199; whereas the > 199.227.237.209.in-addr.arpa query (PTR) gives you "hermes.apache.org". > This is neither an error, nor wrong in any other way. > > Besides, what do you mean by an A record in the context of a mail > exchanger anyway? The A record of the HELO name? Or an A record for the > PTR? The A record for "hermes.apache.org" (PTR) resolves nicely to > 209.237.227.199. But it doesn't have to. For instance, in the case of > microsoft.com and yahoo.com there are multiple A records (done for load > balancing?). And you will get them returned in random order. Exit "PTR and > A records should match". > > - Mark >
RE: R: Scoring PTR's
> -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, exactly as the RFC > > states, that "For every IP address, there should be a matching PTR > > record in the in-addr.arpa domain." And "That all IP addresses > > have a corresponding PTR record." > > AND that the PTR record point back to a valid A record. > > Further into the same paragraph it says: > > Also, PTR records must point back to a valid A record, > > Given that the point of this paragraph is "Make sure your PTR and A > records match", I would comfortably assert that one necessary > element to making this A record "valid" is that at least one such > A record from that hostname matches the IP address for that PTR record. That does NOT mean that other A records cannot resolve to, and thus be used for, the same IP address. That's the whole point: not if someone has defined a valid A record for a PTR; but whether the PTR of the reverse DNS lookup should match that of the A record used. Received: from mail.apache.org (hermes.apache.org [209.237.227.199]) Even if hermes.apache.org actually used "hermes.apache.org" for HELO, then still, there's nothing in any RFC, that says that their PTR should also be "hermes.apache.org" (RFC 1912 just says that for whatever PTR they use, a matching A record should exist also). That's what we're talking about here. Not whether an A record exists to match the PTR, but whether the A record used for HELO should match the PTR. And I remaim firm in my conviction that this is not the case. - Mark
R: R: Scoring PTR's
> 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. You took this too much literally, I guess. The meaning of this phrase is a bit broader and is explained by the following: > For every IP address, there > should be a matching PTR record in the in-addr.arpa domain. This is the purpose of 2.1: there shouldn't be IP addresses without associated PTR records. This doesn't mean the "the A and PTR records must match". Infact, often you can't feed the result of a PTR query back to obtain the IP address: most ISP (even country-wide ISPs, not me) do define PTRs with names which may help them to identify the trunk and link where that ip is located, but which doesn't match an associated A record... > If a > host is multi-homed, (more than one IP address) make sure that all IP > addresses have a corresponding PTR record (not just the first one). > Failure to have matching PTR and A records can cause loss of Internet > services similar to not being registered in the DNS at all. Also, > PTR records must point back to a valid A record, not a alias defined > by a CNAME. It is highly recommended that you use some software > which automates this checking, or generate your DNS data from a > database which automatically creates consistent data. > > (note: RFC 1912 is not a "Standard", it is informational, but it is > basically trying to establish guidelines for good DNS configurations) Maybe it is informational because it is unreasonable to be enforced? The reason is also that Internet works fine even without PTR records... > >> This doesn't bother virtual domains at all. > >> > >> For example: > >> > >> IP addr A.B.C.D might have a PTR return "virtdomains.domain.tld" > >> > >> virtdomains should have an A record returning A.B.C.D (perhaps among > >> other IP addrs). > > > > But there may be more zones with an A record returning A.B.C.D. > That's how a domain is virtualized. > > Funny. The _very_ next thing you quoted from me, addresses the virtual > domains issue: > > > >> The virtual domains can also have A records that say A.B.C.D. That > >> works, and doesn't violate the "PTR and A records should > match" guideline. > > > > Who did sell you these guidelines? > > RFC 1912 Ok. RFC 1912. > >> And, in any case, the HELO string can be anything. It can be > >> virtdomains.domain.tld, or it can be one of the virtual domains, and > >> nothing should be wrong. > > > > HELO/EHLO must indicate the MTA official name. > > That's true, and irrelevant to whether or not the PTR record and A > record should match. Since the latter is the discussion in this > side-thread, the content of the HELO/EHLO string can be anything and > still not break "the PTR record and A record should match". I would prefer something like "the IP address specified by the EHLO/HELO string, either explicitly or as a DNS name, must match the one of the SMTP client itself". But you're right: even this way is almost irrelevant. > > ...omissis... > > That's not what I said. I said the PTR record and A record should > match. What this means is the the PTR record should lead to a hostname > which has an A record (not a CNAME), and that hostname should have an A > record that points to the IP address you started with. But... this is automaticly enforced by most ISPs. What's the meaning of this?!? Suppose I have this in my virtual domain yoyodine.com: @ MX 10 mta.yoyodine.com. mta A 1.2.3.4 When my MTA connects to your, your see that I'm connecting from 1.2.3.4, issues a DNS PTR request 4.3.2.1.in-addr.arpa. and obtains, say, c4-l3-t2.isp.net. Then, if your MTA issues a DNS A request for c4-l3-t2.isp.net and my ISP is not that bad (i.e.: it follows your guidelines), your MTA should get a 1.2.3.4 reply. Your MTA ends saing "Ok". If the client's ISP is not rfc-1912-conformant, your MTA says: "Bad". So, what's the purpose of this? Penalize people who got a rfc-1912 non-conforming ISP? > The hostname may > have multiple A records (round robin DNS), but at least one of them must > be the IP address you started with (the SMTP client). This is multihoming matter. Multihoming is not concerned into this discussion. Is it? Why do you speak about it? > Further, this has absolutely no impact on multiple hostnames having an A > record with that IP address. There is NOTHING in this statement that > prevents this situation. So, what are we discussing about? /Me lost. > What matters is "the hostname listed in the > PTR record" should point back to the IP address you started with (whose > PTR record you looked up, resulting in the hostname). All other > hostnames w
Re: R: Scoring PTR's
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. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). I now see the cause of your confusion. "Make sure your PTR and A records match", in this context, means, exactly as the RFC states, that "For every IP address, there should be a matching PTR record in the in-addr.arpa domain." And "That all IP addresses have a corresponding PTR record." AND that the PTR record point back to a valid A record. I'm not the one who is confused here. It does NOT say "The PTR of an IP address should match that of an A record with the same name." Further into the same paragraph it says: Also, PTR records must point back to a valid A record, Given that the point of this paragraph is "Make sure your PTR and A records match", I would comfortably assert that one necessary element to making this A record "valid" is that at least one such A record from that hostname matches the IP address for that PTR record. Otherwise, they don't match, and thus the thesis of the paragraph is not satisfied.
Re: Scoring PTR's
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 names (say, based on hosting of virtual servers), whilst the IP address for that MTA has a "fixed" PTR. The statement you're replying to doesn't say anything about the HELO string. Oh? The OP's example was: I didn't say "the OP's example", I said "the statement you're replying to", as quoted above. The statement that was being replied to was specifically about PTR and A record matching. ... It says the PTR and A records should match (and they SHOULD). Oh? An IP address lookup will give you a single PTR; but many domains can be registered in DNS with the same IP address, of course. Yes. A situation I have already covered. Multiple times. Besides, what do you mean by an A record in the context of a mail exchanger anyway? The A record of the HELO name? Is the HELO string a PTR record? or merely a string that may or may not match a PTR record? Then clearly that's not what I'm referring to. Or an A record for the PTR? Clearly, that's what I'm referring to. The A record for "hermes.apache.org" (PTR) resolves nicely to 209.237.227.199. But it doesn't have to. For instance, in the case of microsoft.com and yahoo.com there are multiple A records (done for load balancing?). And you will get them returned in random order As long as the hostname in the PTR record has an A record which contains the IP address in question, all is good. As I have said multiple times. Exit "PTR and A records should match". Not even close.
RE: R: Scoring PTR's
> -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. For every IP address, there > should be a matching PTR record in the in-addr.arpa domain. If a > host is multi-homed, (more than one IP address) make sure that all IP > addresses have a corresponding PTR record (not just the first one). I now see the cause of your confusion. "Make sure your PTR and A records match", in this context, means, exactly as the RFC states, that "For every IP address, there should be a matching PTR record in the in-addr.arpa domain." And "That all IP addresses have a corresponding PTR record." It does NOT say "The PTR of an IP address should match that of an A record with the same name." In the context of this RFC, "match" is more like a matching pair: for every A record there should be a PTR defined also. In the OP's post, he wanted to 'penalize' a relay because it's HELO name was not identical to the PTR. And that's just plain silly, and not supported by any RFC I know. - Mark
Re: Scoring PTR's
Jo Rhett wrote: 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, especially outside of the US. And fixed reverse IP information is common for T1 level service too. You're thinking too small. Not at all. Because the answer is still "not my problem". * There are commercial mail services out there, that act independently of being ISPs. * There are hosting companies that will provide you with a virtual host that you could just use as an outbound mail relay. Pick a solution. Use it. Keep your mangy end-customer-DNS-name off of my lawn.
RE: Scoring PTR's
> -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 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 names (say, based on hosting of virtual servers), whilst the > > IP address for that MTA has a "fixed" PTR. > > The statement you're replying to doesn't say anything about the HELO > string. Oh? The OP's example was: cirencester.co.uk (c204131.adsl.hansenet.de [213.39.204.131]) Here, "cirencester.co.uk" is the HELO name; and "c204131.adsl.hansenet.de" the PTR. Similarly, in the line: Received: from mail.apache.org (hermes.apache.org [209.237.227.199]) "mail.apache.org" was the supplied HELO name, whereas the connecting IP address resolves to "hermes.apache.org". > ... It says the PTR and A records should match (and they SHOULD). Oh? An IP address lookup will give you a single PTR; but many domains can be registered in DNS with the same IP address, of course. An A record lookup for "mail.apache.org" resolves to 209.237.227.199; whereas the 199.227.237.209.in-addr.arpa query (PTR) gives you "hermes.apache.org". This is neither an error, nor wrong in any other way. Besides, what do you mean by an A record in the context of a mail exchanger anyway? The A record of the HELO name? Or an A record for the PTR? The A record for "hermes.apache.org" (PTR) resolves nicely to 209.237.227.199. But it doesn't have to. For instance, in the case of microsoft.com and yahoo.com there are multiple A records (done for load balancing?). And you will get them returned in random order. Exit "PTR and A records should match". - Mark
Re: R: Scoring PTR's
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 every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data. (note: RFC 1912 is not a "Standard", it is informational, but it is basically trying to establish guidelines for good DNS configurations) This doesn't bother virtual domains at all. For example: IP addr A.B.C.D might have a PTR return "virtdomains.domain.tld" virtdomains should have an A record returning A.B.C.D (perhaps among other IP addrs). But there may be more zones with an A record returning A.B.C.D. That's how a domain is virtualized. Funny. The _very_ next thing you quoted from me, addresses the virtual domains issue: The virtual domains can also have A records that say A.B.C.D. That works, and doesn't violate the "PTR and A records should match" guideline. Who did sell you these guidelines? RFC 1912 And, in any case, the HELO string can be anything. It can be virtdomains.domain.tld, or it can be one of the virtual domains, and nothing should be wrong. HELO/EHLO must indicate the MTA official name. That's true, and irrelevant to whether or not the PTR record and A record should match. Since the latter is the discussion in this side-thread, the content of the HELO/EHLO string can be anything and still not break "the PTR record and A record should match". Maybe that the SMTP rfc doesn't clearly states that, but the DSN rfcs do state that, under the smtp domain, the name of a MTA must be a name mapping to the IP address of the MTA itself. This means that is must be the dns name or the ip address of the MTA. And it wont violate the "PTR and A records should match" guideline. Technically, it can be garbage, and still be ok. Whatever it is, it doesn't change the item you replied to. Again, I can't recall a single RFC asserting that an A record must mutually map a PTR record. That's not what I said. I said the PTR record and A record should match. What this means is the the PTR record should lead to a hostname which has an A record (not a CNAME), and that hostname should have an A record that points to the IP address you started with. The hostname may have multiple A records (round robin DNS), but at least one of them must be the IP address you started with (the SMTP client). Further, this has absolutely no impact on multiple hostnames having an A record with that IP address. There is NOTHING in this statement that prevents this situation. What matters is "the hostname listed in the PTR record" should point back to the IP address you started with (whose PTR record you looked up, resulting in the hostname). All other hostnames with the same IP address are not a factor in this "matching". ...omissis... (but if they send email directly to me, instead of through their ISP, I will reject them, because their customer oriented IP address shouldn't be directly submitting email to my mail server) This is clearly stated in RFC 101974192374. :) You're "their ISP", isn't it? No, I am not their ISP, thus I have no desire, and certainly no obligation, to be their mail server :-)
Re: Scoring PTR's
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 write a header rule similar to below, to identify if the announce name and PTR name do not match? header LOCAL_INVALID_PTR2 Received =~ /from \S+ \(unknown / Doesn't sendmail usually insert the phrase "claiming to be some.other.host" in these situations? For instance, Received: from exchange.fccj.edu(207.203.47.99), claiming to be "fccj-sbm-03.fccj.org" Unfortunately a quick grep for 'claiming to' in my mail spool shows dozens of perfectly legitimate mail servers that result in a "claiming" header, like the one above. The only one of these cases that I score is "claiming to be localhost" which gets 3 points here. They're nearly always spams though they're usually tagged by other rules. A quick grep of my logs shows that the lowest SA score received by a message that claims to be localhost is about 10 (including the 3 points for this rule). Peter
R: Scoring PTR's
> 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 "virtdomains.domain.tld" > > virtdomains should have an A record returning A.B.C.D (perhaps among > other IP addrs). But there may be more zones with an A record returning A.B.C.D. That's how a domain is virtualized. > The virtual domains can also have A records that say A.B.C.D. That > works, and doesn't violate the "PTR and A records should match" guideline. Who did sell you these guidelines? > And, in any case, the HELO string can be anything. It can be > virtdomains.domain.tld, or it can be one of the virtual domains, and > nothing should be wrong. HELO/EHLO must indicate the MTA official name. Maybe that the SMTP rfc doesn't clearly states that, but the DSN rfcs do state that, under the smtp domain, the name of a MTA must be a name mapping to the IP address of the MTA itself. This means that is must be the dns name or the ip address of the MTA. > And it wont violate the "PTR and A records > should match" guideline. Technically, it can be garbage, and still be > ok. Whatever it is, it doesn't change the item you replied to. Again, I can't recall a single RFC asserting that an A record must mutually map a PTR record. > > ...omissis... > > (but if they send email directly to me, instead of through their ISP, I > will reject them, because their customer oriented IP address shouldn't > be directly submitting email to my mail server) This is clearly stated in RFC 101974192374. :) You're "their ISP", isn't it? giampaolo
Re: Scoring PTR's
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, especially outside of the US. And fixed reverse IP information is common for T1 level service too. You're thinking too small. -- Jo Rhett Network/Software Engineer Net Consonance
Re: Scoring PTR's
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 different HELO names (say, based on hosting of virtual servers), whilst the IP address for that MTA has a "fixed" PTR. 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). This doesn't bother virtual domains at all. For example: IP addr A.B.C.D might have a PTR return "virtdomains.domain.tld" virtdomains should have an A record returning A.B.C.D (perhaps among other IP addrs). The virtual domains can also have A records that say A.B.C.D. That works, and doesn't violate the "PTR and A records should match" guideline. And, in any case, the HELO string can be anything. It can be virtdomains.domain.tld, or it can be one of the virtual domains, and nothing should be wrong. And it wont violate the "PTR and A records should match" guideline. Technically, it can be garbage, and still be ok. Whatever it is, it doesn't change the item you replied to. And, for dynamic end hosts, this guideline still works. The IP addr W.X.Y.Z might go to client-W-X-Y-Z.someisp.com then client-W-X-Y-Z.someisp.com has A record pointing to W.X.Y.Z. And, last, mail.domain.tld might also be an A record pointing to W.X.Y.Z. That still doesn't violate "PTR and A records should match". The IP address leads to a hostname whose A record leads back to the IP address. All is good. And you can still mail to [EMAIL PROTECTED] and it will work. (but if they send email directly to me, instead of through their ISP, I will reject them, because their customer oriented IP address shouldn't be directly submitting email to my mail server)
Re: Scoring PTR's
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 match, IT IS JUST GOOD PRACTICE, I am also not trying to block people who don't qualify, I just want to identify and score it!! Received: from *cirencester.co.uk*(*c204131.adsl.hansenet.de*[213.39.204.131]) 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. 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.
Re: Scoring PTR's
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 their ISP's mail server, mail server sends to you. That's
a good situation, you don't want to flag that. If that same end client
connects to you, THEN you can to smack 'em down.
I was thinking about doing this in a plugin, because I have some extra
DNS checks I want to do on that information (be sure the PTR record
points to an A record, be sure that the A record resolves back to the
relaying IP address). Then look to see if the hostname in question
looks like a dynamic hostname.
In particular, you might want to look at variations of this pattern, to
match against the X-Spam-Relays-Untrusted psudoheader:
/^\[ ip=(\d+)\.(\d+)\.(\d+)\.(\d+) rdns=\S*(0*(\1|\2|\3|\4)\S?){2,4}\S*
[^\]]* auth= /
/^\[ [^\]]* rdns=\S*(dynamic|dsl|dial-?up|ppp|cable|dhcp|ddns|catv)/
/^\[ [^\]]* rnds=\s/
#1 looks for IP address within the hostname
#2 looks for words that seem like dynamic host names
#3 looks for no PTR record at all
In all 3 cases, the [^\]]* makes sure you don't look past the first
element of the list (so the data obtained from the first received header).
I'd probably assign a score of 4.5 to #1 and #2, and 6 to #3 (but that's
because I want to be sure to flag them as spam, but not exceed a score
of 10 if #1 and #2 are both true ... because I reject at a score >= 10;
if you aren't worried about exceeding 10, then I might assign a score of
5 or 6 to all 3 rules ... keeping in mind that #3 wont happen in
combination with #1 and #2, but #1 and #2 might happen together).
Right now, I don't use SA for this. I use mimedefang. And it rejects
the message outright for this... but some people suggested I might look
into merely quarantining these messages for those few legitimate
businesses who are stuck on a bad ISP, and are too thick headed to use
their ISP's mail server.
R: Scoring PTR's
> 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" You lucky: mine got one of that weird PTR that my ISP likes to use... My ISP told me that I can handle the PTR name I like provided I buy at least a whole C class bunch. It is a bargain! :( > The original questions was how do I write a header rule similar to > below, to identify if the announce name and PTR name do not match? > > header LOCAL_INVALID_PTR2 Received =~ /from \S+ \(unknown / > > > > thanks, > > Robert > > > > > > > Peace he would say instead of goodbyepeace my brother. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL 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 a good example: > >> > >> Received: from mail.apache.org (hermes.apache.org [209.237.227.199]) > >> > >> There is really nothing score-worthy about that (spam-wise). > >> > >> Your example, btw, on my server would be REJECT-ed for another > reason, > >> though: > >> > >> Go away, spammer! [213.39.204.131]: "United Kingdom" [.uk HELO] != > >> "Germany" [.de PTR]" > >> > >> In the strictest sense, I'm not allowed to do that, either. But my > >> rationale is, that the connecting host's HELO is perpetrating a lie > here > >> that under any reasonable circumstance is just irreconcilable with > the > >> PTR (the MTA simply cannot be in both countries at the same time). > >> > >> - Mark > >> > >> > wouldn't it be possible for a .de hosting companyto host a .uk domain or > vice versa? > Of course I would not like to be hosted on an adsl link but that kis a > different story > > Wolfgang Hamann > >
RE: Scoring PTR's
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 write a header rule similar to below, to identify if the announce name and PTR name do not match? header LOCAL_INVALID_PTR2 Received =~ /from \S+ \(unknown / thanks, Robert Peace he would say instead of goodbyepeace my brother. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL 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 a good example: >> >> Received: from mail.apache.org (hermes.apache.org [209.237.227.199]) >> >> There is really nothing score-worthy about that (spam-wise). >> >> Your example, btw, on my server would be REJECT-ed for another reason, >> though: >> >> Go away, spammer! [213.39.204.131]: "United Kingdom" [.uk HELO] != >> "Germany" [.de PTR]" >> >> In the strictest sense, I'm not allowed to do that, either. But my >> rationale is, that the connecting host's HELO is perpetrating a lie here >> that under any reasonable circumstance is just irreconcilable with the >> PTR (the MTA simply cannot be in both countries at the same time). >> >> - Mark >> >> wouldn't it be possible for a .de hosting companyto host a .uk domain or vice versa? Of course I would not like to be hosted on an adsl link but that kis a different story Wolfgang Hamann
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 [209.237.227.199]) >> >> There is really nothing score-worthy about that (spam-wise). >> >> Your example, btw, on my server would be REJECT-ed for another reason, >> though: >> >> Go away, spammer! [213.39.204.131]: "United Kingdom" [.uk HELO] != >> "Germany" [.de PTR]" >> >> In the strictest sense, I'm not allowed to do that, either. But my >> rationale is, that the connecting host's HELO is perpetrating a lie here >> that under any reasonable circumstance is just irreconcilable with the >> PTR (the MTA simply cannot be in both countries at the same time). >> >> - Mark >> >> wouldn't it be possible for a .de hosting companyto host a .uk domain or vice versa? Of course I would not like to be hosted on an adsl link but that kis a different story Wolfgang Hamann
Re: Scoring PTR's
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 MDaemon used to switch the helo based on the recipient domain, it may still. *cirencester.co.uk*(*c204131.adsl.hansenet.de*[213.39.204.131]) There is really nothing score-worthy about that (spam-wise). Your example, btw, on my server would be REJECT-ed for another reason, though: Go away, spammer! [213.39.204.131]: "United Kingdom" [.uk HELO] != "Germany" [.de PTR]" In the strictest sense, I'm not allowed to do that, either. But my rationale is, that the connecting host's HELO is perpetrating a lie here that under any reasonable circumstance is just irreconcilable with the PTR (the MTA simply cannot be in both countries at the same time). What if my email virtual host isn't in the same country as me and the rest of my stuff? Daryl
R: Scoring PTR's
> > 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 > > PRACTICE, I am also not trying to block people who don't qualify, I just > > want to identify and score it!! > > Received: from > > *cirencester.co.uk*(*c204131.adsl.hansenet.de*[213.39.204.131]) > > 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. I agree in this at whole. That's my case, in example. And I'm from Italy, not US: we too are used to "annoyances" from our ISPs... :) giampaolo
RE: Scoring PTR's
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 HELO names (say, based on hosting of virtual servers), whilst the IP address for that MTA has a "fixed" PTR. That's not a sign of spam; not even a bit. It is, however, good practice, as I pointed out, to have those HELO names resolve to the IP address of the connecting client. Though not an RFC specific MUST, certainly a good idea to have one's own stuff in order. > > *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 nothing score-worthy about that (spam-wise). Your example, btw, on my server would be REJECT-ed for another reason, though: Go away, spammer! [213.39.204.131]: "United Kingdom" [.uk HELO] != "Germany" [.de PTR]" In the strictest sense, I'm not allowed to do that, either. But my rationale is, that the connecting host's HELO is perpetrating a lie here that under any reasonable circumstance is just irreconcilable with the PTR (the MTA simply cannot be in both countries at the same time). - Mark
Re: Scoring PTR's
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 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? That's not possible in qmail, postfix, sendmail, et al... -- Jo Rhett Network/Software Engineer Net Consonance
Re: Scoring PTR's
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 match, IT IS JUST GOOD PRACTICE, I am also not trying to block people who don't qualify, I just want to identify and score it!! Received: from *cirencester.co.uk*(*c204131.adsl.hansenet.de*[213.39.204.131]) 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. ...Don't ask me why we call things which annoy us "a Tax" in the US. Probably just still emotionally locked up around that whole Tea Party thing ;-) 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.
Re: Scoring PTR's
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 GOOD PRACTICE, I am also not trying to block people who don't qualify, I just want to identify and score it!! Received: from *cirencester.co.uk*(*c204131.adsl.hansenet.de*[213.39.204.131]) 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. ...Don't ask me why we call things which annoy us "a Tax" in the US. Probably just still emotionally locked up around that whole Tea Party thing ;-) -- Jo Rhett Network/Software Engineer Net Consonance
RE: Scoring PTR's
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 Peace he would say instead of goodbyepeace my brother. From: Chris Santerre [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 9:25 AM To: Robert Swan; SpamAssassin Users Subject: RE: Scoring PTR's > -Original Message- > From: Robert Swan [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 19, 2006 9:10 AM > To: SpamAssassin Users > Subject: Scoring PTR's > > > 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 > PRACTICE, I am also not trying to block people who don't > qualify, I just > want to identify and score it!! > > I would appreciate some help writing this rule..the SPAMMER who sent > this knows what he/she is doing and it would be helpful to > identify this > trick. > > Received: from > *cirencester.co.uk*(*c204131.adsl.hansenet.de*[213.39.204.131]) Hey its your system, I'll help you mark it as spam if its got a Subject line! :) However, I don't think you will be able to do this with a straight rule. You will most likely need an Eval. --Chris The fact that Matt can quote actual RFC sections.is scary :)
RE: Scoring PTR's
Title: RE: Scoring PTR's > -Original Message- > From: Robert Swan [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 19, 2006 9:10 AM > To: SpamAssassin Users > Subject: Scoring PTR's > > > 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 > PRACTICE, I am also not trying to block people who don't > qualify, I just > want to identify and score it!! > > I would appreciate some help writing this rule..the SPAMMER who sent > this knows what he/she is doing and it would be helpful to > identify this > trick. > > Received: from > *cirencester.co.uk*(*c204131.adsl.hansenet.de*[213.39.204.131]) Hey its your system, I'll help you mark it as spam if its got a Subject line! :) However, I don't think you will be able to do this with a straight rule. You will most likely need an Eval. --Chris The fact that Matt can quote actual RFC sections.is scary :)
Scoring PTR's
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 PRACTICE, I am also not trying to block people who don't qualify, I just want to identify and score it!! I would appreciate some help writing this rule..the SPAMMER who sent this knows what he/she is doing and it would be helpful to identify this trick. Received: from *cirencester.co.uk*(*c204131.adsl.hansenet.de*[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: > > 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 the > reported mail server like the SPAMMER below?: > > > > Received: from *cirencester.co.uk* (*c204131.adsl.hansenet.de* > [213.39.204.131]) > > >
RE: Scoring PTR's
> -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, supplied by the > > connecting client. This FQDN has to resolve to the connecting > > IP address, 209.237.227.199, which is does. > > Actually, according to RFC 2821 section 4.1.1.1 the EHLO/HELO string > doesn't have to be a FQDN at all, I didn't say that, did I? I was talking about "mail.apache.org", and then spoke of *this* FQDN. There's no address literal here. > According to that RFC, if there's no meaningful domain name you SHOULD > use an address literal.. but even that that is not a MUST. I didn't say MUST. SHOULD, however, is the imperative word. HELO names SHOULD be a FQDN or an address literal. Also, It is common practice not to fault people over regular words like "should, should not, must, may", unless they are capitalized (indicating RFC 2119 significance). So, I stand by what I said: FQDNs, used in EHLO/HELO definitely should (not SHOULD) resolve to the IP address of the connecting client. The point, however, was, that the connecting IP address definitely does not have to resolve to the HELO name of the connecting client. - Mark
Re: Scoring PTR's
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 ignorance. :) > > "mail.apache.org" is the HELO name, supplied by the connecting client. > This FQDN has to resolve to the connecting IP address, 209.237.227.199, > which is does. Actually, according to RFC 2821 section 4.1.1.1 the EHLO/HELO string doesn't have to be a FQDN at all, much less resolve to 209.237.227.199. According to that RFC, if there's no meaningful domain name you SHOULD use an address literal.. but even that that is not a MUST.
RE: Scoring PTR's
> -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 below?: > 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 ignorance. :) "mail.apache.org" is the HELO name, supplied by the connecting client. This FQDN has to resolve to the connecting IP address, 209.237.227.199, which is does. But the reverse logic is faulty: 209.237.227.199 does NOT have to resolve to "mail.apache.org" (and it doesn't; it resolves to "hermes.apache.org"). - Mark
Re: Scoring PTR's
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 rule to score if the PTR is different than the reported mail server like the SPAMMER below?: Received: from *cirencester.co.uk* (*c204131.adsl.hansenet.de* [213.39.204.131]) I would advise against scoring items like that. Want to see an example of a legitimate system looking like that? Look at the headers for this message. Here are one of the lines from your message coming in to my system through this list: 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. Richard
Scoring PTR's
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 the reported mail server like the SPAMMER below?: Received: from cirencester.co.uk (c204131.adsl.hansenet.de [213.39.204.131]) Thanks in advance, Robert Peace he would say instead of goodbyepeace my brother.
