unknown_client_reject_code 450 vs. 550

[Rod Dorman]

After searching thru the archives looking for reasons not to change
unknown_client_reject_code to 550 (changing the default of 450) I only
came across one that seemed semi reasonable.

That being with returning a 450 theres a possibility of discovering and
white listing the offending IP before the sending MTA gives up and the
mail is returned to their user.

As I see it that would require someone (i.e. me or my counterpart at the
sending MTA) to examine the logs, notice the problem, and get it fixed,
before the sending MTA gives up.

IMHO the odds of this happening are kinda small.

Since the majority of e-mail users today are members of the Church of
Instantaneous Propagation they'd want to find out about a problem sooner
rather than later.

I guess the best way of wrapping this up is to ask if anyone ever ran
into a problem with unknown_client_reject_code set to a 5xx permanent
error.

[Noel Jones]

Post by Rod Dorman
After searching thru the archives looking for reasons
not to change
unknown_client_reject_code to 550 (changing the default
of 450) I only
came across one that seemed semi reasonable.
That being with returning a 450 theres a possibility of
discovering and
white listing the offending IP before the sending MTA
gives up and the
mail is returned to their user.
As I see it that would require someone (i.e. me or my
counterpart at the
sending MTA) to examine the logs, notice the problem, and
get it fixed,
before the sending MTA gives up.
IMHO the odds of this happening are kinda small.
Since the majority of e-mail users today are members of
the Church of
Instantaneous Propagation they'd want to find out about a
problem sooner
rather than later.
I guess the best way of wrapping this up is to ask if
anyone ever ran
into a problem with unknown_client_reject_code set to a
5xx permanent
error.
--
started, it is too
Rod Dorman late for the pebbles to vote." -
Ambassador Kosh

My opinion is that if you are going to use
reject_unknown_client, you should reject them with a 550 so
everyone knows about it right away. Legit senders will be
notified of the problem quickly and have the opportunity to
contact their recipient via alternate means. The recipient
can then complain to their friendly local postmaster, who
can reestablish harmony in the universe in less than the
default 5 day queue time.

Postfix will automatically change the response to 450 in
the case of temporary DNS errors, so setting it to 550 is safe.

[p***@bitfreak.org]

Post by Noel Jones
My opinion is that if you are going to use
reject_unknown_client, you should reject them with a 550 so
everyone knows about it right away.
Postfix will automatically change the response to 450 in
the case of temporary DNS errors, so setting it to 550 is safe.

How can postfix tell the difference between a non-existent DNS name and
a temporary DNS error that's producing false NXDOMAIN responses?

[Noel Jones]

Post by p***@bitfreak.org

Post by Noel Jones
My opinion is that if you are going to use
reject_unknown_client, you should reject them with a 550
so everyone knows about it right away.
Postfix will automatically change the response to 450 in
the case of temporary DNS errors, so setting it to 550 is safe.

How can postfix tell the difference between a non-existent
DNS name and a temporary DNS error that's producing false
NXDOMAIN responses?

The default response is 450. If you are concerned about
badly administrated domains, don't use a 550 response.

[p***@bitfreak.org]

Post by Noel Jones

Post by p***@bitfreak.org
How can postfix tell the difference between a non-existent
DNS name and a temporary DNS error that's producing false
NXDOMAIN responses?

The default response is 450. If you are concerned about
badly administrated domains, don't use a 550 response.

I don't use reject_unknown_client at all, actually, but that's beside
the point. You said using a 550 is safe because postfix will change it
to 450 if the REJECT is due to a temporary DNS error. I'm asking how
postfix is able to tell if it's a temporary error if accurate and
inaccurate NXDOMAIN responses are indistinguishable from each other.

[Noel Jones]

(Harvey Smith)

Post by Harvey Smith
Nope you don't see what I say. It doesn't matter what I have
unknown_client_reject_code set to, temporary DNS errors

will always

Post by Harvey Smith
return 450 as they should

That's not how it works.
If you change the default to 550, the MTA will treat a
temporary DNS
error as permanent, and reply to the sender with a 550
perm fail code.

The above is inaccurate.

If you change unknown_client_reject_code to 550, postfix
will automatically change the response to 450 in the case
of temporary errors.

Now can we please let this thread die.

[Noel Jones]

Post by p***@bitfreak.org

Post by Noel Jones

Post by p***@bitfreak.org
How can postfix tell the difference between a non-existent
DNS name and a temporary DNS error that's producing false
NXDOMAIN responses?

The default response is 450. If you are concerned about
badly administrated domains, don't use a 550 response.

I don't use reject_unknown_client at all, actually, but
that's beside the point. You said using a 550 is safe
because postfix will change it to 450 if the REJECT is due
to a temporary DNS error. I'm asking how postfix is able
to tell if it's a temporary error if accurate and
inaccurate NXDOMAIN responses are indistinguishable from
each other.

You want to distinguish a valid authoritative response from
a valid authoritative response?
This discussion is pointless. If you receive a valid
response, it is by definition valid.

Postfix can be configured to run without DNS. If DNS is
present, it is expected to provide accurate
answers. Anything else is a broken system and outside the
scope of this list.

[p***@bitfreak.org]

Post by Noel Jones

Post by p***@bitfreak.org

Post by Noel Jones
The default response is 450. If you are concerned about
badly administrated domains, don't use a 550 response.

You said using a 550 is safe
because postfix will change it to 450 if the REJECT is due
to a temporary DNS error. I'm asking how postfix is able
to tell if it's a temporary error if accurate and
inaccurate NXDOMAIN responses are indistinguishable from
each other.

You want to distinguish a valid authoritative response from
a valid authoritative response?
[...] If you receive a valid response, it is by definition valid.

Hence, returning a permanent error based on such DNS data is unsafe.

[John Kelly]

- if we don't get an (adequate) answer, then that's generally a
transient error, and 4xx is ok

Didn't I see Wietse comment recently counseling against using 5xx
at all in that situation because transient DNS errors can cause
legitimate mail to be rejected even if the domain exists?

Most DNS timeouts are associated with spam hosts, compromised or
otherwise, having no DNS.

Yes, John Kelly, some people do worry about losing legitimate mail.

It's a rare case where an otherwise reputable host actually has a
transient DNS error. Once the problem is fixed, users can send their
email again, if it was really so important.

But there you go again, feeding the "lost email" hysteria.

[Harvey Smith]

Post by John Kelly

- if we don't get an (adequate) answer, then that's generally a
transient error, and 4xx is ok

Didn't I see Wietse comment recently counseling against using 5xx
at all in that situation because transient DNS errors can cause
legitimate mail to be rejected even if the domain exists?

Most DNS timeouts are associated with spam hosts, compromised or
otherwise, having no DNS.

transient DNS errors always return a 450 reject.

Post by John Kelly

Yes, John Kelly, some people do worry about losing legitimate mail.

Rejected mail is not lost. The sender should be informed nearly
immediately that their mail did not go through, nothing 'lost' about
it. On the other hand mail is lost for a time if it is incorrectly put
into a spam folder. I've spent more time on support because someone
didn't get that email when it turns out it's found later in the spam
folder than I have on support because someone didn't get an email
becuase it was rejected.

Post by John Kelly
It's a rare case where an otherwise reputable host actually has a
transient DNS error. Once the problem is fixed, users can send their
email again, if it was really so important.

There is a large ISP in my area that has flaky DNS and regularly has
soft errors. Since transient DNS errors always return a 450 reject
the sending server should automatically try again in a few minutes. In
my experience transient DNS errors are just that and everything is
working fine in 5 mins time, or its just a spam-zombie anyway and I
don't really care.

[John Kelly]

Post by Harvey Smith
There is a large ISP in my area that has flaky DNS and regularly has
soft errors. Since transient DNS errors always return a 450 reject

The OP wanted to know if there will be problems changing the response
to 550 perm fail. In the case of your flaky ISP is, the worst that
can happen is, users will get a failure message, and will have to try
sending again.

Post by Harvey Smith
or its just a spam-zombie anyway and I don't really care

The 450 temp fail was conceived during the spam free Internet of the
70s and early 80s. In today's spam reality, it has become obsolete.

Perm fail that garbage, and stop worrying about lost mail. There will
always be more.

[Harvey Smith]

No, in the case of my flaky ISP the message gets rejected with a
450 error. transient DNS errors always return a 450 reject.
http://www.postfix.org/postconf.5.html#unknown_client_reject_code

http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname

The unknown_client_reject_code parameter specifies the response code
for rejected requests (default: 450).
Do not change this unless you have a complete understanding of RFC 821

So the default 450 can be changed to 550.

We're not on the same page. I was talking about transient DNS errors,
which always return a 450 reject. spam-zombies don't tend to retry
anyway, so they kinda auto-greylist themselves if the have a transient
DNS error.

I see what you are saying.
But I say, change the code to 550 and perm fail them all. The flaky
ISP users can send their email again. They know it failed.

Nope you don't see what I say. It doesn't matter what I have
unknown_client_reject_code set to, temporary DNS errors will always
return 450 as they should (see the link I posted above). There it IS
safe to set unknown_client_reject_code to a 5xx code. If it didn't
always return 450 for transient failure then it would not be so safe.
It makes no sense to set reject_unknown_client_hostname and keep the
error code at 450 (except for when testing it perhaps). As this will
cause legit servers (those few without proper hostnames) to keep
retrying and it may be several days before the sender gets a message
that the mail did not go through. So yes set the code to 554 (or
whatever your understanding of RFC 821 says) OR don't use
reject_unknown_client_hostname at all (if you are worried about
rejecting small amounts of legit mail)

I actually greylist 'unknown' hosts which seems to be the happy middle
ground between setting reject_unknown_client_hostname or not. But if
you are setting reject_unknown_client_hostname keeping, the error code
at 450 makes no sense to me.

[John Kelly]

I have both the documentation and my experience on my side so you'll
need to back up that with some evidence.
http://www.postfix.org/postconf.5.html#unknown_client_reject_code
"The SMTP server always replies with 450 when the mapping failed due
to a temporary error condition."

When the writer said "always," he only meant until you change the
default.

That's a documentation bug.

[Julien Lesaint]

Post by John Kelly
When the writer said "always," he only meant until you change the
default.
That's a documentation bug.

[pts/13] # postconf -n | grep reject_code
unknown_address_reject_code = 550
unknown_client_reject_code = 550
unknown_hostname_reject_code = 550

XCLIENT NAME=[UNAVAILABLE] ADDR=1.2.3.4
220 anna.titoon.net ESMTP (No UCE/UBE) - Logging access
bla bla...
MAIL FROM:<***@titoon.net>
250 2.1.0 Ok
RCPT TO:<***@titoon.net>
550 5.7.1 Client host rejected: cannot find your hostname, [1.2.3.4]


XCLIENT NAME=[TEMPUNAVAIL] ADDR=1.2.3.4
220 anna.titoon.net ESMTP (No UCE/UBE) - Logging access
bla bla...
MAIL FROM:<***@titoon.net>
250 2.1.0 Ok
RCPT TO:<***@titoon.net>
450 4.7.1 Client host rejected: cannot find your hostname, [1.2.3.4]

[John Kelly]

On Wed, 16 Aug 2006 07:56:06 +0200, Julien Lesaint

Post by Julien Lesaint
XCLIENT NAME=[UNAVAILABLE] ADDR=1.2.3.4
220 anna.titoon.net ESMTP (No UCE/UBE) - Logging access
bla bla...
250 2.1.0 Ok
550 5.7.1 Client host rejected: cannot find your hostname, [1.2.3.4]
XCLIENT NAME=[TEMPUNAVAIL] ADDR=1.2.3.4
220 anna.titoon.net ESMTP (No UCE/UBE) - Logging access
bla bla...
250 2.1.0 Ok
450 4.7.1 Client host rejected: cannot find your hostname, [1.2.3.4]

Thanks. It's good to know Aahz's law still holds true. ;-)

[John Kelly]

Post by Harvey Smith
Nope you don't see what I say. It doesn't matter what I have
unknown_client_reject_code set to, temporary DNS errors will always
return 450 as they should

That's not how it works.

If you change the default to 550, the MTA will treat a temporary DNS
error as permanent, and reply to the sender with a 550 perm fail code.

[John Kelly]

On Tue, 15 Aug 2006 23:06:30 -0500, Noel Jones

Post by John Kelly
If you change the default to 550, the MTA will treat a
temporary DNS error as permanent, and reply to the sender
with a 550 perm fail code.

The above is inaccurate.
If you change unknown_client_reject_code to 550, postfix
will automatically change the response to 450 in the case
of temporary errors.

That's not the way I would expect it to work, but maybe I'm wrong.
Let me take a look at the code and see ...

[Harvey Smith]

Post by John Kelly

Post by Harvey Smith
Nope you don't see what I say. It doesn't matter what I have
unknown_client_reject_code set to, temporary DNS errors will always
return 450 as they should

That's not how it works.
If you change the default to 550, the MTA will treat a temporary DNS
error as permanent, and reply to the sender with a 550 perm fail code.

I have both the documentation and my experience on my side so you'll
need to back up that with some evidence.

http://www.postfix.org/postconf.5.html#unknown_client_reject_code

"The SMTP server always replies with 450 when the mapping failed due
to a temporary error condition."

[Gino Cerullo]

I

officially

proclaim

this

the

longest

thread

in

the

world.

Now please stop! It's been beat'n to death. :-(

--
Gino Cerullo

[John Kelly]

No, in the case of my flaky ISP the message gets rejected with a
450 error. transient DNS errors always return a 450 reject.
http://www.postfix.org/postconf.5.html#unknown_client_reject_code

Also see:

http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname

The unknown_client_reject_code parameter specifies the response code
for rejected requests (default: 450).
Do not change this unless you have a complete understanding of RFC 821

So the default 450 can be changed to 550.

We're not on the same page. I was talking about transient DNS errors,
which always return a 450 reject. spam-zombies don't tend to retry
anyway, so they kinda auto-greylist themselves if the have a transient
DNS error.

I see what you are saying.

But I say, change the code to 550 and perm fail them all. The flaky
ISP users can send their email again. They know it failed.

[Harvey Smith]

Post by John Kelly

Post by Harvey Smith
There is a large ISP in my area that has flaky DNS and regularly has
soft errors. Since transient DNS errors always return a 450 reject

The OP wanted to know if there will be problems changing the response
to 550 perm fail. In the case of your flaky ISP is, the worst that
can happen is, users will get a failure message, and will have to try
sending again.

No No, in the case of my flaky ISP the message gets rejected with a
450 error. transient DNS errors always return a 450 reject.

http://www.postfix.org/postconf.5.html#unknown_client_reject_code

Post by John Kelly

Post by Harvey Smith
or its just a spam-zombie anyway and I don't really care

The 450 temp fail was conceived during the spam free Internet of the
70s and early 80s. In today's spam reality, it has become obsolete.
Perm fail that garbage, and stop worrying about lost mail. There will
always be more.

We're not on the same page. I was talking about transient DNS errors,
which always return a 450 reject. spam-zombies don't tend to retry
anyway, so they kinda auto-greylist themselves if the have a transient
DNS error.

[Charles Gregory]

Post by John Kelly
The 450 temp fail was conceived during the spam free Internet of the
70s and early 80s. In today's spam reality, it has become obsolete.

Did I mention that I am underwhelmed by the lack of intelligence being
demonstrated? From everything I've heard, most spambots don't retry to
send mail. So a 450 or 550 will have the same result with spam. I think
the original poster was concerned that if a legitimate sender had a bad
DNS they would wait five days to find out. The answer is, of course, that
a decently configured MTA sends a warning after 5 hours or so. And I don't
think that anyone with a badly configured DNS would stay that way for too
long because they would see too many 5 hour warnings. So really, you've
got legitimate temporary failures, and spammers who will treat any failure
as a 550.

Oh, and just because some moron keeps advocating that it's okay to lose
e-mail, I will just voice the counter-argument that people *rely* upon it
more and more, and we should 'worry' about it as much as our customers do.
A business that fails to be responsive to the needs of its customers is
not going to be in business for long.

Duh.

- Charles

[/dev/rob0]

Post by Charles Gregory
Did I mention that I am underwhelmed by the lack of intelligence
being demonstrated? From everything I've heard, most spambots don't
retry to send mail. So a 450 or 550 will have the same result with
spam. I think the original poster was concerned that if a legitimate

XBL spam vs. SBL spam (as I mentioned in another thread), yes. But SBL
spammers usually have perfect FCrDNS anyway.

Post by Charles Gregory
sender had a bad DNS they would wait five days to find out. The
answer is, of course, that a decently configured MTA sends a warning
after 5 hours or so. And I don't think that anyone with a badly

That's not the Postfix default, BTW, you have to set
"delay_warning_time".

Post by Charles Gregory
as our customers do. A business that fails to be responsive to the
needs of its customers is not going to be in business for long.

Microsoft and the US Government both appear to be going strong. ;)

Seriously, and as this is off-topic please don't extend this thread on
this account, I wonder if we've got a new paradigm. Consider the music
and film industries, who treat their paying customers as criminals,
even like enemies! Retailers and retail packaging: I have kids, and I
mutter things I don't want them to hear every time I have to struggle
with the packaging of a new toy. :) Success in the 21st century: get
big and treat customers poorly.

My apologies to the list for the off-topic diversion, but note, I
stayed out of the flame war, and I managed a small bit of topical
discussion herein. ;) :)

[Charles Gregory]

Post by /dev/rob0

Post by Charles Gregory
as our customers do. A business that fails to be responsive to the
needs of its customers is not going to be in business for long.

Microsoft and the US Government both appear to be going strong. ;)

(smile) That thought *had* crossed my mind. But I know a few well-meaning
people in government jobs. Wouldn't want to blame them for their system.
:)

- Charles

[mouss]

Post by p***@bitfreak.org
Hence, returning a permanent error based on such DNS data is unsafe.

you seem confused.
- if one of the domain servers says the domain exists, then we consider
that the domain exists
- if it says the domain does not exist, then we consider that the domain
does not exist and a 5xx is ok
- if we don't get an (adequate) answer, then that's generally a
transient error, and 4xx is ok
- ...

[Colin Campbell]

Hi,

Post by p***@bitfreak.org

Post by Noel Jones

Post by p***@bitfreak.org
How can postfix tell the difference between a non-existent
DNS name and a temporary DNS error that's producing false
NXDOMAIN responses?

The default response is 450. If you are concerned about
badly administrated domains, don't use a 550 response.

I don't use reject_unknown_client at all, actually, but that's beside
the point. You said using a 550 is safe because postfix will change it
to 450 if the REJECT is due to a temporary DNS error. I'm asking how
postfix is able to tell if it's a temporary error if accurate and
inaccurate NXDOMAIN responses are indistinguishable from each other.

The following is my understanding of how the universe works:

There is no such thing as "an inaccurate NXDOMAIN" response. A DNS query
will come back with one of three answers:

a) the answer (eg MX or A records)
b) NXDOMAIN when the requested data doesn't exist
c) SERVFAIL when there is a problem somewhere, eg an authoritative
server can't be reached, or the server has a problems or some other
error

When postfix gets either (a) or (b) it has a definitive answer from the
server - the data exists or it doesn't. It's when the third scenario
occurs that postfix decides to use a 450 since it doesn't know what
happened. It didn't get a definitive answer so rather than drop the
email for what may only be a transient error. However, postfix has no
way of knowing whether the problem is transient or not, so postfix keeps
trying until a definitive answer returns or the email times out.

Unfortunately, way too many servers return SERVFAIL when they probably
should return NXDOMAIN.

Colin

[Noel Jones]

Post by p***@bitfreak.org

Post by Noel Jones

Post by p***@bitfreak.org

Post by Noel Jones
The default response is 450. If you are concerned about
badly administrated domains, don't use a 550 response.

You said using a 550 is safe because postfix will change
it to 450 if the REJECT is due to a temporary DNS
error. I'm asking how postfix is able to tell if it's a
temporary error if accurate and inaccurate NXDOMAIN
responses are indistinguishable from each other.

You want to distinguish a valid authoritative response
from a valid authoritative response?
[...] If you receive a valid response, it is by
definition valid.

Hence, returning a permanent error based on such DNS data
is unsafe.

Hence, delivering mail based on DNS responses is also
unsafe, arguably far more so. Do you have a point?

[John Kelly]

Post by Rod Dorman
I guess the best way of wrapping this up is to ask if anyone ever ran
into a problem with unknown_client_reject_code set to a 5xx permanent
error.

I perm fail all DNS errors, including unmatched forward/reverse. I
check DNS before anything else, and that alone stops 60% + of the spam
hitting my server. Is it a problem? Not for senders who have proper
DNS. :-)

Do I lose any "legit" mail? Periodic review of my mail logs indicates
that it's not enough to worry about.

Disclaimer: I'm still using "the other guys" MTA.

[Rick Zeman]

When did a sender having to have a reverse DNS entry become canon?

It's been de facto standard for some time now.

Which RFC was that again?
Many services available on the Internet will not talk to you if you
aren't correctly registered in the DNS.

De facto's not de jure. Where's the REQUIREMENT? Right. There isn't one.

If you bounce mail solely on that lack you should have your root
password taken away from you.

Whenever you're ready big boy, try and take it.

Just like there are no dogs on the internet, everyone's a tough guy, too.

[John Kelly]

This post might be inappropriate. Click to display it.

[Rick Zeman]

Post by John Kelly

Post by Rick Zeman
Just like there are no dogs on the internet, everyone's a tough guy, too.

You started this fight in private mail, and now you want it on the
list too. So in the interest of full disclosure ...

Post by Rick Zeman
When did a sender having to have a reverse DNS entry become canon?

It's been de facto standard for some time now.

Post by Rick Zeman
Which RFC was that again?
Many services available on the Internet will not talk to you if you
aren't correctly registered in the DNS.
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

But I'm not doing your homework for you. If you want to know which
one, find it yourself.

Post by Rick Zeman
If you bounce mail solely on that lack you should have your root
password taken away from you.

Whenever you're ready big boy, try and take it.

Oh, that was my mistake. I was unaware that the original went to you
solely in email. With gmail, it's easy (at least for me) to make that
mistake. Sorry--at least for that.

[John Kelly]

I was unaware that the original went to you solely in email.
With gmail, it's easy ... to make that mistake.

I don't understand why people use gmail. I sure wouldn't want my mail
archived in one convenient place where the government can easily snoop
on it.

[Sipos Gabor]

this reminds me a well-known cartoon: two stupid dogs.

anyway: there may not be a requirement to have an rdns record for a
sender. also, there is no requirement to accept mail from this kind of
sender (and btw, no requirement to accept mail from anywhere, that
is). I can reject mail from wherever I want, beacuse it is MY system,
and I decide what mail I want to get...

that said, please stop flaming.... :)

Post by Rick Zeman

Many services available on the Internet will not talk to you if you
aren't correctly registered in the DNS.

De facto's not de jure. Where's the REQUIREMENT? Right. There isn't one.

If you bounce mail solely on that lack you should have your root
password taken away from you.

Whenever you're ready big boy, try and take it.

Just like there are no dogs on the internet, everyone's a tough guy, too.

[John Kelly]

there may not be a requirement to have an rdns record for a sender

Suppose RFC1912 was a "standard," and said MUST? Would every spammer
comply? Though RFC1912 is "informational," it's foolish to ignore it.

there is no requirement to accept mail from this kind of sender

The vast majority of mail originating from hosts lacking proper DNS,
is spam.

DNS is like auto registration. An honest citizen would not operate
their car on the highway without a valid registration. So why would
anyone expect to send email without proper DNS? Of course spammers
do, and since no honest emailer wants to look like a spammer, having
matching forward and reverse DNS is like having an auto registration.

It's such an easy check to do, and it catches so much spam, it is the
de facto standard for email.

[John Kelly]

Post by John Kelly
The vast majority of mail originating from hosts lacking proper DNS,
is spam.

Vast majority < 100%. Until then....

It's impossible to win a war without any collateral damage, and those
who can't accept any collateral damage will never defeat spam.

The notion that businesses can't tolerate losing any "legit" email is
the fanatical thinking of a computer geek, one with an inflated belief
of the importance of his skills and profession.

until it's a requirement for EVERYONE,

And then, you think spammers will comply?

improper choice for an admin to make ON BEHALF OF OTHER PEOPLE.

Around here, we still have telephones and fax machines. So if a few
emails don't get through, we don't become hysterical.

[Charles Gregory]

Firstly, I agree with whoever said this has been hashed over time and time
again, and should just STOP. I'm not here to further debate the merits of
450 or 550. I'm only replying because I'm getting sick of the *attitudes*
and *ignorance* I'm seeing displayed here....

Post by John Kelly
The notion that businesses can't tolerate losing any "legit" email is
the fanatical thinking of a computer geek, one with an inflated belief
of the importance of his skills and profession.

Fanatical thinking allows no other viewpoints and as a cheap argumentative
trick, belittles the people that express them. So that would be *you*.

Post by John Kelly
Around here, we still have telephones and fax machines. So if a few
emails don't get through, we don't become hysterical.

Around here, we have a helpdesk phone, and if a few e-mails don't get
through it rings .... for each customer missing a 'few' mails. (ick)

And that, I suspect, is true for most of the people on this list, running
various levels of mail servers for multiple users. And strictly speaking a
majority of those users know what is a reasonable expectation for mail
service. And I'm sure all the 'computer geeks' do. But the 'minority'
of users that don't is still very large, and they phone at the first sign
of a false positive. So the professional attitude is to anticipate and
prevent these calls, by minimizing the false positives.

Yes, customers *can* be unreasonable. We educate them wherever possible.
Our web pages are full of disclaimers and clear warnings. They still
phone. And that is a cost we must bear. So we work to minimize it.

Duh.

- Charles

[John Kelly]

On Tue, 15 Aug 2006 13:25:27 -0400 (EDT), Charles Gregory

Post by Charles Gregory
I agree with whoever said this has been hashed over time and time
again, and should just STOP.

If that's what you want, replying to the thread does not help stop it.

Post by Charles Gregory
Fanatical thinking allows no other viewpoints and as a cheap argumentative
trick, belittles the people that express them. So that would be *you*.

Requiring proper forward/reverse DNS is a low cost, high return method
of stopping spam. It provides a good first defense, and the basis for
regex testing of dynamic/dialup host names.

Admins who can't even agree on something as simple as that, because
they fear risking any collateral damage whatsoever, are doomed to the
endless torment of content filtering.

[Tony Earnshaw]

ty den 15.08.2006 Klokka 14:45 (+0100) skreiv John Kelly (of
isp2dial.com):

[...]

Post by John Kelly
The vast majority of mail originating from hosts lacking proper DNS,
is spam.
DNS is like auto registration. An honest citizen would not operate
their car on the highway without a valid registration. So why would
anyone expect to send email without proper DNS? Of course spammers
do, and since no honest emailer wants to look like a spammer, having
matching forward and reverse DNS is like having an auto registration.
It's such an easy check to do, and it catches so much spam, it is the
de facto standard for email.

No it's not. Only non-profs[1] would block all mail originating from
domains without correct DNS configuration - they'd lose too much legit
mail.

--Tonni

[1] If I interpret your own domain correctly, it's isp2dial.com, right?
http://www.isp2dial.com/ says it all ...

[John Kelly]

On Tue, 15 Aug 2006 17:10:41 +0200, Tony Earnshaw

Post by Tony Earnshaw

DNS is like auto registration ... It's such an easy check to do,
and it catches so much spam, it is the de facto standard for email.

No it's not. Only non-profs[1] would block all mail originating from
domains without correct DNS configuration - they'd lose too much legit
mail.

So you say. The facts are otherwise.

[l***@kwsoft.de]

Post by Tony Earnshaw
ty den 15.08.2006 Klokka 14:45 (+0100) skreiv John Kelly (of
[...]

Post by John Kelly
The vast majority of mail originating from hosts lacking proper DNS,
is spam.
DNS is like auto registration. An honest citizen would not operate
their car on the highway without a valid registration. So why would
anyone expect to send email without proper DNS? Of course spammers
do, and since no honest emailer wants to look like a spammer, having
matching forward and reverse DNS is like having an auto registration.
It's such an easy check to do, and it catches so much spam, it is the
de facto standard for email.

No it's not. Only non-profs[1] would block all mail originating from
domains without correct DNS configuration - they'd lose too much legit
mail.
--Tonni

Please stop this pointless discussion on this list. This topic has
beaten to death many times and the only baseline is that the parties
agree that they don't agree. No need to fight a war because of this.
There are really more urgent problems to solve.

Andreas

[Rick Zeman]

Post by John Kelly

there may not be a requirement to have an rdns record for a sender

Suppose RFC1912 was a "standard," and said MUST? Would every spammer
comply? Though RFC1912 is "informational," it's foolish to ignore it.

there is no requirement to accept mail from this kind of sender

The vast majority of mail originating from hosts lacking proper DNS,
is spam.

Vast majority < 100%. Until then....

Post by John Kelly
DNS is like auto registration. An honest citizen would not operate
their car on the highway without a valid registration. So why would

There's the difference. The law requires proper registration of
vehicles. There is no "law" (RFC) mandating rDNS for proper SMTP
operation. You're doing the equivalent of standing at the curb
shooting the tires out of the cars that you THINK might have improper
registration.

Post by John Kelly
anyone expect to send email without proper DNS? Of course spammers
do, and since no honest emailer wants to look like a spammer, having
matching forward and reverse DNS is like having an auto registration.

See above. Plus, I can go in my mail logs and see how much blocked
spam has a reverse. For instance, most dial up blocks have reverses
and the most US-based spam comes from them. You're attributing much
more causality than there really is.

Post by John Kelly
It's such an easy check to do, and it catches so much spam, it is the
de facto standard for email.

De facto != de jure. It's just like bouncing mail for anyone who
doesn't have an SPF record. Whether or not having an SPF is a good
idea or not doesn't matter (and I think academically that rDNS is a
good idea, but mine is a philosophical problem not a technical one),
but until it's a requirement for EVERYONE, it's an improper choice for
an admin to make ON BEHALF OF OTHER PEOPLE.

There are standards for a reason. Without them, there would be anarchy.

End of soapbox.

[Rick Zeman]

Post by John Kelly

- if we don't get an (adequate) answer, then that's generally a
transient error, and 4xx is ok

Didn't I see Wietse comment recently counseling against using 5xx
at all in that situation because transient DNS errors can cause
legitimate mail to be rejected even if the domain exists?

Most DNS timeouts are associated with spam hosts, compromised or
otherwise, having no DNS.

I suppose you have some evidence to back up that...theory?

[John Kelly]

Post by Rick Zeman

Post by John Kelly
Most DNS timeouts are associated with spam hosts, compromised or
otherwise, having no DNS.

I suppose you have some evidence to back up that...theory?

I'm not a scientist, so I don't need to prove anything. I'm just an
ordinary workman, using my experience and common sense.

[Rick Zeman]

Post by mouss

Post by p***@bitfreak.org
Hence, returning a permanent error based on such DNS data is unsafe.

you seem confused.
- if one of the domain servers says the domain exists, then we consider
that the domain exists
- if it says the domain does not exist, then we consider that the domain
does not exist and a 5xx is ok
- if we don't get an (adequate) answer, then that's generally a
transient error, and 4xx is ok

Didn't I see Wietse comment recently counseling against using 5xx at
all in that situation because transient DNS errors can cause
legitimate mail to be rejected even if the domain exists? (Yes, John
Kelly, some people do worry about losing legitimate mail.)

[mouss]

Post by Rick Zeman

Post by mouss

Post by p***@bitfreak.org
Hence, returning a permanent error based on such DNS data is unsafe.

you seem confused.
- if one of the domain servers says the domain exists, then we consider
that the domain exists
- if it says the domain does not exist, then we consider that the domain
does not exist and a 5xx is ok
- if we don't get an (adequate) answer, then that's generally a
transient error, and 4xx is ok

Didn't I see Wietse comment recently counseling against using 5xx at
all in that situation because transient DNS errors can cause
legitimate mail to be rejected even if the domain exists? (Yes, John
Kelly, some people do worry about losing legitimate mail.)

Transient DNS failures will generate a 4xx whatever is your setting. The
only problem is with DNS misconfigurations. but then, it's good for the
sender to know quickly.

mail can be lost if the mail was relayed by a gateway that cannot bounce
back to the sender. but if the message was delivered, the recipient
can't reply anyway, and this generally not appreciated (the sender can
use an alternate mail system to resend his message).