--On October 21, 2012 9:53:49 AM +0000 Mike's unattended mail
<mike.thomas-dlre...@cool.fr.nf> wrote:
On 2012-10-20, The Stovebolt Geek <g...@stovebolt.com> wrote:
But then I've never been one to rigidly demand that everyone else
comply with my concept of what is "right".
Then this means you are not using a DNSBL as a block list - which
indeed promotes a live and let live approach.
No, you've completely misunderstood my point. I have control over one
thing, and one thing only - my domain. On my domain, I set the rules.
What you do on yours is entirely up to you.
If you want to interact with my domain, then you will adjust your systems
so that I'll accept your mail. You don't have to use a hostname if you
don't want to. And I don't have to accept your mail if you don't.
It is precisely those who run a DNSBL as a block list who are
demanding (with force, in fact) that everyone else adopt their
extra-RFC concept of "right" -- and if they do not comply with this
extra-RFC practice, then their mail will be disrupted. It's a great
way for large corporporate conglomerates to control others.
You've got it backwards. They're not demanding anything. They're
controlling what is accepted in their domain. The rules I use on my domain
are none of your concern, nor are they designed to influence what you do.
IF you want to send mail to me, then you will comply with my rules, or you
won't send mail to me or we will work out an accommodation.
But you can still send mail to anyone else who accepts your mail. I'm not
making you change anything, unless you absolutely must send mail to my
domain. In that case you need to work with me to make an accommodation,
either on my part or yours, so that your mail is accepted.
But you have no right to tell me how to run my domain any more than I have
a right to tell you to run yours. If I decide to completely ignore all
RFCs and run "rogue", what concern of yours is that?
BTW, you are wrong about IP addresses for mail servers.
<ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt>
The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a valid principal host name (not a CNAME or MX
name) for its host. If this is not possible (e.g., when the client's
address is dynamically assigned and the client does not have an
obvious name), an address literal SHOULD be substituted for the
domain name and supplemental information provided that will assist in
identifying the client.
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
Note that the SMTP server MUST NOT refuse to accept mail from a client
simply because of an IP/hostname mismatch, however there is nothing said in
that RFC about other mechanisms that will reject for those reasons. For
example, policyd-weight will assign a value to that failure which, in
addition to other anomalies, may send the mail to the bit bucket.
Or, in the case of DNSBLs, policyd-weight may assign a high enough value
that the mail server simply rejects the mail.
Paul Schmehl (g...@stovebolt.com)
The Stovebolt Geek
The Net's Oldest and Most Complete
Resource for Antique Chevy and GM Trucks
http://www.stovebolt.com
