[CentOS] Re: postfix tightening

Mon Apr 4 00:39:54 UTC 2005
Mark A. Lewis <mark at siliconjunkie.net>

> On Saturday 02 April 2005 05:32 pm, karl at streetlampsoftware.com wrote:
> 
> > How
> > would I go about providing a good, solid *matching* ptr (as 
> in, mail 
> > from AcmeWidget.com reflects to mail.AcmeWidget.com at x.x.x.219 ...
> > which also happens to be mail.hostco.com) for the bazillion and one 
> > virtual-hosted email accounts on mail.hostco.com?
> 
> You wouldn't.  That's not and never was the purpose of a ptr record.  
> The ptr record is to attach responsibility for the IP#.  
> That's done by pointing it to the hostname.

But, in this case, it has multiple hostnames, all of which are valid.

> You could have multiple ptr records, but there exists no 
> facility in any DNS or resolution system to match up ptr 
> records with a records.  If I recall correctly, behavior in 
> the case of multiple ptr records is undefined.

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.

It all comes back to a few key points:
1) Refusing mail based on HELO not matching the ptr record is not RFC
compliant, but it is not uncommon.
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.
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.
4) There are some easy to do HELO checks that can eliminate a large
number of spammers and misconfigured MTAs.

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.

IMO, none of the cost based solutions I have read such as "postage" or
something mildly CPU intensive will accomplish anything but a mess.

Good discussion though, I have learned a lot by actually reading some of
the RFCs and some dicussions on them.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.