Re: Beating the spam filter ...

On 08/07/06 21:43, Bill Cole wrote:
More weird names for Linux-trained admins to give to Solaris machines... :)

*nod*

(FWIW, that would be the default for at least some BSD systems' 'hostname' whose only possible option is -s for stripping the domain part. "Unix" is so much fun...)

Indeed.

Perhaps, but one of the reasons to use many names referring to a single machine is to associate names with services or sets of services, rather than with physical machines, and to support various forms of virtualization. A name that is not a machine's internal identity is more easily moved to refer to another machine, and that capability seems to be driving a lot of the interesting novelty in IT these days.

Ah HA! I believe there in lies at least part of the root of our difference in opinions. You use names to refer to services where as I use names to refer to hosts and then use CNAMEs to refer service names to hosts. I do believe that this explains a lot. I don't think either is wrong, but each is vastly different.

Yes, but that's far more relevant to outbound mail than to how you set up inbound MX records. If a mail service provider tells customers to just set up their own MX's pointing at their own names with A records pointing at an IP of the provider, the lack of symmetrical PTR records for those is invisible when that mail server sends mail because it isn't using the ad hoc customer names when it sends mail. No one sane resolves an MX and then refuses to pass along mail simply because the A record of the MX target doesn't have a matching PTR.

The only concern that I see with that is whether or not, or how well SPF filtering / records will apply to your statement. I'm not in the mood to try to figure things out. I do believe SPF TXT records could be set up to support this, possibly with one or two more names included as allowed senders.

Oh, and http://www.rfc-ignorant.org/policy-bogusmx.php might be of interest. I think using the RFC-I lists for spam control is properly career-limiting for a mail admin, but people do use them, and the "bogus MX" list is probably the least problematic.

I too know people that have run in to RFC-I. I think that such lists could have minimal use in spam filtering, possibly worth .1 to the spam score for SA, but that is about it.

Okay, but it does not have much functional operational advantage that I can see. Anyone who really needs to know the "real" name can log in and run hostname (maybe -f...) or if they can't do that maybe just see what the MTA says in its banner (although that's not always the same as the "real" name either.)

I think the operational difference is more a mode of thinking on the admin's part than it is a technical operations issue.

Well, "unclean" has the sound of Leviticus to it... I'm more interested in how it might be problematic.

I can not site specific examples at the moment. Based on some questions that I have seen asked by the type of admins that use RFC-I that are wanting to filter in such a manner as would be caught by this. In an effort to try to prevent spam, I fear the email world is going to erroneously become over restrictive.

As an example, I administer a machine that calls itself asewp452.vwoa.na.vwg internally. That name carries a complex meaning to me and about a dozen other people, and it is in DNS from the viewpoint of tens of thousands of other machines. It is not visible in DNS from the outside world, although that machine provides services to the world at large. It's MTA, accessible to the world, does not banner with that name. There are multiple other names that are visible to the world in DNS which would get someone from the world to that machine, but nothing readily seen from a distance that would identify all those names as referring to to the same host. This has never caused any problems.

Indeed.

It never has yet, in part because for all that time there has been a PTR from whatever IP sc1.scconsult.com resolves to pointing back at sc1.scconsult.com. At present it is one of 4 PTR's for that address, all equally valid.

The problem that I'm fearing will happen is that the forward and reverse DNS for a machine will have to match (no matter how many names it has) as well as said name(s) matching what is used in the HELO name. I do not know and I can not site issues to this effect at the moment. However I do have a fear of this in the not to distant future.

One general problem with CNAME records is that there isn't a solid operational consensus in how strong the "canonical" nature is. Back in the early days of name-based virtual web hosting, at least one browser helpfully treated CNAME records as grounds to "correct" URL's (and Host headers...) One could probably make an argument from RFC1034 and its predecessors that this is not wrong behavior, although it certainly causes problems.

I'm curious. Would you care to provide a history lesson for thous of us who are interested? If not, that is fine.

On the other side, NOT pushing the real name back up into the application layer to replace the alias also can lead to trouble when using systems such as Kerberos where a client has to address the server by the name it sees itself as.

I can see how this could be a problem.

I was speaking specifically of pointing MX recoprds and addresses that have CNAME's.

Ah, I'll agree to that.



Grant. . . .
.

Relevant Pages

  • Re: Firewall suggestion?
    ... > I have a customer that is using Exchange 5.5 behind a simple firewall. ... > server by trying to use it as a Spam relay. ... The target hosts must be ... If this header is set, ...
    (comp.security.firewalls)
  • Re: Cant see out to .co.uk from inside my .local domain (forward l
    ... and you do need to find out where the problem is in your DNS. ... just add another entry in your hosts file referencing ... network only from the server which I changed the hosts file for. ... us to resolve the issue with DNS. ...
    (microsoft.public.windows.server.sbs)
  • Re: Solaris NIS server and Linux NIS client : problems
    ... Changed nsswitch.conf for hosts values. ... hosts: nis dns files ... Sep 2 09:59:57 spock ypbind: bound to NIS server odin. ... Can't get map list for domain. ...
    (comp.os.linux.networking)
  • Re: Solaris NIS server and Linux NIS client : problems
    ... Changed nsswitch.conf for hosts values. ... hosts: nis dns files ... Sep 2 09:59:57 spock ypbind: bound to NIS server odin. ... Can't get map list for domain. ...
    (comp.unix.solaris)
  • Re: VGER does gradual SPF activation (FAQ matter)
    ... It took /years/ until open relays weren't common anymore... ... And it will take years to somwhat get a grip on the the spam ... since they had almost no reverse DNS zones ...
    (Linux-Kernel)