[arin-ppml] How bad is it really?

[Ted Mittelstaedt]

On 7/17/2010 8:22 PM, Stephen Sprunk wrote:
> On 13 Jul 2010 01:48, Ted Mittelstaedt wrote:
>> Before getting too worked up, please keep in mind that the fact that
>> the mail message was ACCEPTED by your mail system and not immediately
>> bounced, indicates that there's a valid e-mail box there.
>
> No, it does not.  I'm aware of at least one firewall appliance that
> "accepts" all mail submitted to any address and, after doing some
> security checks, blindly forwards it to an internal smarthost (which
> might or might not send a DSN if the address is invalid).

That kind of architecture is unworkable in practice and I'll tell you
why.  Today spammers figure out valid e-mail addresses by mailing 
domains and waiting for an error 500.  If this firewall appliance 
accepts everything then every address query the spammer sends will be
considered valid, thus the spammer will have hundreds of thousands of
bogus e-mail addresses for that domain - and when they start spamming
then your going to melt the internal smarthost down.

> I'm not sure
> whether this is an RFC violation, but either way it's existence proof
> that the SMTP response code that ARIN receives is _not_ a reliable
> indication that the address used does in fact correspond to an actual
> mailbox.
>

I think your confused in any case.  All the firewall appliances I've 
seen that forward mail are written to use LDAP or Microsoft Networking
protocols or just SMTP queries on the smarthost to verify the incoming
e-mail recipient address BEFORE dropping the SMTP handshake.

> And, of course, we all know about mailboxes that reside at /dev/null,
> spam filtering systems, old mailboxes for ex-employees, etc. that mean
> some (unknown) fraction of mail never gets seen by a human even if the
> address _does_ have a valid mailbox of some sort, so validity in that
> sense is a meaningless measure anyway.
>

I have to disagree here.  The WHOIS standard requires contact info, it
does NOT require that valid contact info is only people who actually
get off their fat ass and RESPOND to e-mails.

Technically if I issue a SWIP that has a POC with an e-mail address that
goes to an e-mail box that I never respond to, never read, then that IS
a valid e-mail address and I'm good under the NRPM.

Nobody than me would LOVE to see an adjustment to the RSA and NRPM that 
mandated that recipients of address blocks respond to legitimate 
e-mails.  So, I actually LIKE what ARIN is doing with requiring e-mail
links to be responded to.  But, I'm not naieve enough to think that
anywhere in the NRPM or RSA that there's language that explicitly gives
ARIN the right to do POC verification by requiring a human response.
My gut feel is that sooner or later some bozo out there is going to
sue ARIN claiming that they are overstepping their authority to do
POC verification, so the earlier that we can head that off by modifying
language in the NRPM and RSA that defines what a valid contact is, the
happier I'll be.

But clearly there's a lot of people out there who would consider the
parent ISP to be "valid POC contact info" and would fight any attempt
to mandate real addresses and e-mail addresses on the SWIP POCs, so
good luck with getting any requirements for specifying valid contacts
passed.

>> I'd hazard a guess that if you didn't click on the link at all that
>> ARIN is going to still consider the POC  "most likely valid".
>
> Why would they?  They sent an email and the intended recipient didn't
> click one of the links.  Either the message never reached the recipient
> or the recipient disregarded it, which indicates that email address is
> not a reliable means of contacting them--and that's what we're trying to
> determine, isn't it?
>

Unfortunately, no.  If you can point to language in the RSA or NRPM that
disallows e-mail addresses in POCs that go to recipients that disregard
them, please do so.  I would love to be corrected on that.

Ted

> S
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.