Fred Viles wrote:
>
> | Fred Viles wrote:
> |...
> | > So you *know* what you are advocating is impractical.
> | >
> | What I advocate is no more impractical than those that advocate SPF.
>
> We'll have to agree to disagree about that. You seem to be making some
> connection between the two that I just don't get.
>
Explain to me how implementing SPF is more 'practical' than what I
suggested.
>
> |...
> | > I disagree. Advocating that admins to set up what you view as
> | > proper rDNS would be fine, but you are advocating that admins set up
> | > a system you know perfectly well will block a lot of legitimate
> | > mail. That is not ethical IMO.
> | >
> | Go back over my postings, I have said that this 'should be implemeted
> | first by those that will force a change',
>
> Right, you want someone else to take the heat from their users and
> accept the lost business for the common good.
>
No, I never said that either. This is not something that JUST ONE
comapny/person/entity/orginization/government/etc. can make work, and
neither is SPF, DMP, RMX, DRIP, FSV, Domain-Keys, or "Caller ID for E-mail"
It would, just as any of the above, require multiple (as in MORE than just
ONE or even TWO) entities to adopt.
So again, how is my recomendation different than adoption of anything else?
>
> | and I also am very prudent in always
> | stating that if this is used currently as a 'deny' that you will lose
> | email bothe good and bad. I DO WARN, so how is this unethical?
>
> It wouldn't be, if you actually did it. I can not find any such warning
> in the posts you've made in this thread, though.
>
Go catch up:
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040322/068596.html
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040322/068598.html
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040322/068603.html
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040322/068610.html
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040322/068646.html
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040322/068647.html
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040322/068657.html
>
> |...
> | > You have a small user base, and can not afford the collateral
> | > damage. Yet you want services with millions of users to adopt it.
> | > What do you think would be the impact on MSN if they started to
> | > block a substantial amount of legitimate mail from reaching their
> | > subscribers? How can you imagine they could do such a thing, when
> | > even you can not?
>
> | Because, just as I currently do, AOL, MSN, and others, can encourage
> | the 'rDNS == DNS A == HELO name' by giving 'prefered' service to those
> | MTA's that are 'correct' in this manner, and delay in various ways,
> | the connection to those that do not. Then after some time (6 months?
> | 1 year?) move to the "we gave you plenty o' warning, comply or we
> | deny" stage.
>
> 1. That's not what you said.
>
Then explain to me what it was that I did say. Where did I ever say,
"Hey all, just do this NOW! and all will be good"? Where?
>
> 2. I do not believe the collateral damage would be reduced to an
> acceptable level that way. They would have to actually block email,
> which they can not do. It's a chicken-and-egg problem.
>
They would not have to block at the begining, just as SPF does not suggest
blocking currently, but you can give a dead line.
Just as one example to this end:
220-rly-ya05.mx.aol.com ESMTP mail_relay_in-ya5.5; Mon, 22 Mar 2004
15:13:09 -0500
220-America Online (AOL) and its affiliated companies do not
220- authorize the use of its proprietary computers and computer
220- networks to accept, transmit, or distribute unsolicited bulk
220- e-mail sent from the internet. Effective immediately: AOL
220- may no longer accept connections from IP addresses which
220 have no reverse-DNS (PTR record) assigned.
Yes, That is the banner that you will get from AOL upon connecting to
"mailin-01.mx.aol.com", unless, that is, if you are from a DUL type of
account, then you get a different Banner that notifies you they will not
take your connection. Now, they do not 'give a deadline' but look at the
wording, "-->EFFECTIVE IMMEDIATELY:<-- AOL -->MAY NO LONGER<-- accept
connections from IP addresses which have no reverse-DNS (PTR record)
assigned." They should add a "You have been Warned at the end" ;)
Now, how is this a chicken-and-egg problem???
Warn and delay first, then some time later, deny.
>
> | This is the same approach they are already taking with SPF is it not?
>
> How so? AFAICT, blocking based on SPF records is an entirely different
> kettle of fish.
>
Only if you decide to block NOW. Would be the same kettle if you decided
to deny unVerified HELO NOW. I have never ever said that denying on an
unVerified HELO NOW is going to help. Delay a connection that does not
have Verified HELO, go for it!
>
> With SPF, for better or worse, the recipient server is
> honoring the intentions of the sender domain's owner.
>
Regardless, that does not encourage 'proper RFC MTA implementations'.
Other than the addition of 'rDNS == DNS A == HELO name', ISP's blocking
outbound tcp port 25 for DUL type accounts, I have been saying all along
that before we 'implement something completely new' we MUST implement
(i.e. FORCE UPON ALL) proper RFC compliant MTA connections, message header
format, and meassage body format.
Let us start there first. Then that will make all the rest easier. And
yes, we do have to start somewhere, and for better or worse, that somewhere
is at the LARGE ISPs and freemail providers.
Wich include, AOL, MSN/Hotmail, Comcast, Cox, Earthlink, Yahoo, Mail.com,
etc. If these types of companies cannot, or do not, start the process,
whatever process that may be, then it will never matter what anyone else
does.
--
--EAL--
