On Sunday 03 April 2005 05:39 pm, Mark A. Lewis wrote: > But, in this case, it has multiple hostnames, all of which are valid. No, it really doesn't. I'm surprise that even on a Sunday night this post managed over two hours without being challenged. See a link to several definitions, here: http://www.google.com/search?hl=en&lr=&oi=defmore&q=define:Hostname > Interesting, never tried creating multiple ptr records. I guess if > the MTA knew how to deal with that it would be a very good solution. > I will have to do some testing to see how it reacts to the scenario. The MTA wouldn't get a chance to deal with it, since most resolvers don't deal with it. > 1) Refusing mail based on HELO not matching the ptr record is not RFC > compliant, but it is not uncommon. Commonness and stupidity are not mutually exclusive, I'm afraid. > 2) There are some vanity issues with someone who cares what the mail > headers say in them. As someone else said, if they are expecting > that, they should expect to pay for it. Then give them their own IP#. And figure out how to get your MUA to use that IP# for outgoing email. And reverse that IP# with whatever they want. We do it. By renting them mailservice on a Virtuozzo VPS. > 3) All of the RFCs pertaining to this were written in a much more > trusting time, and as we are seeing, they need to be revisited. Many of us take RFCs the way we take prescription medication... carefully. > 4) There are some easy to do HELO checks that can eliminate a large > number of spammers and misconfigured MTAs. The key, if you've got commercial clients (we have many) is differentiating between spammers and misconfigured MTAs belonging to folk who are important to those clients. > I do think that the RFCs need to address dynamic address space more > sufficently. I think that the one proposal where the source IP must > be listed under a particular record type in DNS will go a long way > towards addressing many of these issues. I'm going to leave responding to this one until I have a year to study all the RFCs that we already have to follow <smile>. > IMO, none of the cost based solutions I have read such as "postage" > or something mildly CPU intensive will accomplish anything but a > mess. Neither actual or cpu-time "cost" will ever work. And the first things to suffer will be these mailing lists we've come to depend on. > Good discussion though, I have learned a lot by actually reading some > of the RFCs and some dicussions on them. Glad to be part of the group! Jeff -- Jeff Lasman, nobaloney.net, P. O. Box 52672, Riverside, CA 92517 US Professional Internet Services & Support / Consulting / Colocation Our blists address used on lists is for list email only Phone +1 951 324-9706, or see: "http://www.nobaloney.net/contactus.html"