On Mon, 3 Apr 2006, Johann Steigenberger wrote:
> We make a decision on smtp dialog after rcpt to:
>
> RCPT TO: Recipient@example.com
> 550 Your mail was rejected, because your Server has no PTR. To have an
> exception made for you emailaddress contact us using the form on ...
Off topic, but a pet peeve of mine: small domain owners often cannot
set their PTR records because of incompetent ISPs. Changing ISPs is
not possible, since broadband is typically a monopoly, and dialup
(too slow) and T1 (too expensive) are not options. If the
HELO name is correct for an SMTP connection (and resolves to
the connecting IP), you should accept that in lieu of a PTR record.
Any competent admin can configure a correct HELO name - even on a
single static IP, and with no ISP cooperation. It proves that the
MTA was authorized by the domain owner to send email. A PTR record
only proves that the sender has a large block of IPs or a competent ISP.
Further more, a correct HELO name is an actual RFC 2821 requirement:
3.6 Domains
Only resolvable, fully-qualified, domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or A RRs (as discussed in section 5) are
permitted, as are CNAME RRs whose targets can be resolved, in turn,
to MX or A RRs. Local nicknames or unqualified names MUST NOT be
used. There are two exceptions to the rule requiring FQDNs:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
Since 3.6 does not *explicity* say that it should resolve to the
connect IP, some feel that it doesn't matter what it resolves
to. However, it is clear to me that HELO serves no purpose unless
it resolves to the connect IP - thus providing the prefered primary
host name of the connecting MTA (which may be different from any PTR record).
In any case, a HELO (actually EHLO) name that resolves to the connect IP
is a much better RFC compliant validation of the MTA responsible for the
email than PTR.
You have to have a class C or larger block of IP addresses to directly
change your PTR record. For a small domain, you are dependent on
a competent ISP to setup PTR delegation, or to provide an efficient
interface to add/change the direct PTR records maintained for you by the
ISP. Very few ISPs do this properly (AT&T does it right - configuring
PTR delegation by default, all ready to go).
Our current ISP, Cox, actually has an official policy that they will not
provide PTR delegation. They do no provide an interface to maintain the PTR
records either. It took a week, and four hours long phone calls with
escalation to get a technician to enter some acceptable direct PTR records.
Many of our clients with broadband ISPs have no PTR records - because no amount
of pestering will convince their ISP to enter or delegate PTR records.
The ISP is a broadband monopoly in their area.
The following section of RFC 2821 is particularly relevant to our
discussion of reasons to reject mail:
6.3 Compensating for Irregularities
Unfortunately, variations, creative interpretations, and outright
violations of Internet mail protocols do occur; some would suggest
that they occur quite frequently. The debate as to whether a well-
behaved SMTP receiver or relay should reject a malformed message,
attempt to pass it on unchanged, or attempt to repair it to increase
the odds of successful delivery (or subsequent reply) began almost
with the dawn of structured network mail and shows no signs of
abating. Advocates of rejection claim that attempted repairs are
rarely completely adequate and that rejection of bad messages is the
only way to get the offending software repaired. Advocates of
"repair" or "deliver no matter what" argue that users prefer that
mail go through it if at all possible and that there are significant
market pressures in that direction. In practice, these market
pressures may be more important to particular vendors than strict
conformance to the standards, regardless of the preference of the
actual developers.
...
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
> We make a decision on smtp dialog after rcpt to:
>
> RCPT TO: Recipient@example.com
> 550 Your mail was rejected, because your Server has no PTR. To have an
> exception made for you emailaddress contact us using the form on ...
Off topic, but a pet peeve of mine: small domain owners often cannot
set their PTR records because of incompetent ISPs. Changing ISPs is
not possible, since broadband is typically a monopoly, and dialup
(too slow) and T1 (too expensive) are not options. If the
HELO name is correct for an SMTP connection (and resolves to
the connecting IP), you should accept that in lieu of a PTR record.
Any competent admin can configure a correct HELO name - even on a
single static IP, and with no ISP cooperation. It proves that the
MTA was authorized by the domain owner to send email. A PTR record
only proves that the sender has a large block of IPs or a competent ISP.
Further more, a correct HELO name is an actual RFC 2821 requirement:
3.6 Domains
Only resolvable, fully-qualified, domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or A RRs (as discussed in section 5) are
permitted, as are CNAME RRs whose targets can be resolved, in turn,
to MX or A RRs. Local nicknames or unqualified names MUST NOT be
used. There are two exceptions to the rule requiring FQDNs:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
Since 3.6 does not *explicity* say that it should resolve to the
connect IP, some feel that it doesn't matter what it resolves
to. However, it is clear to me that HELO serves no purpose unless
it resolves to the connect IP - thus providing the prefered primary
host name of the connecting MTA (which may be different from any PTR record).
In any case, a HELO (actually EHLO) name that resolves to the connect IP
is a much better RFC compliant validation of the MTA responsible for the
email than PTR.
You have to have a class C or larger block of IP addresses to directly
change your PTR record. For a small domain, you are dependent on
a competent ISP to setup PTR delegation, or to provide an efficient
interface to add/change the direct PTR records maintained for you by the
ISP. Very few ISPs do this properly (AT&T does it right - configuring
PTR delegation by default, all ready to go).
Our current ISP, Cox, actually has an official policy that they will not
provide PTR delegation. They do no provide an interface to maintain the PTR
records either. It took a week, and four hours long phone calls with
escalation to get a technician to enter some acceptable direct PTR records.
Many of our clients with broadband ISPs have no PTR records - because no amount
of pestering will convince their ISP to enter or delegate PTR records.
The ISP is a broadband monopoly in their area.
The following section of RFC 2821 is particularly relevant to our
discussion of reasons to reject mail:
6.3 Compensating for Irregularities
Unfortunately, variations, creative interpretations, and outright
violations of Internet mail protocols do occur; some would suggest
that they occur quite frequently. The debate as to whether a well-
behaved SMTP receiver or relay should reject a malformed message,
attempt to pass it on unchanged, or attempt to repair it to increase
the odds of successful delivery (or subsequent reply) began almost
with the dawn of structured network mail and shows no signs of
abating. Advocates of rejection claim that attempted repairs are
rarely completely adequate and that rejection of bad messages is the
only way to get the offending software repaired. Advocates of
"repair" or "deliver no matter what" argue that users prefer that
mail go through it if at all possible and that there are significant
market pressures in that direction. In practice, these market
pressures may be more important to particular vendors than strict
conformance to the standards, regardless of the preference of the
actual developers.
...
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com