ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
>
>> Externally administered backup MXes run into backscattering because
>> they don't maintain a copy of the users database.
>
> Some don't, many do.
Hm... would you expand on that, please? I browsed a few backup MX
providers (DydDNS, ZoneEdit and Mailfail) and saw no evidence that
they do.
You're looking at commercial backup provision services. Historically this isn't
how backuup MX arrangements have worked. Most of them are simply one small site
helping out another. In such cases providing a copy of your address list often
isn't a big deal.
In fact there's even a suggested protocol for it. I don't recall the draft
name, but it works by putting the address list in the DNS. You then use zone
transfer to move the data around and keep it up to date.
There are also at least two, and probably more, "lookahead" milters that use
part of an SMTP transaction to perform early address validation. (I use one of
these myself as part of providing backup MX service for a couple of people.)
>> To amend that status
>> of affairs implies that a user's email address will also be stored at
>> an externally controlled backup MX. Such situation should interest the
>> users, as those addresses are part of their personally identifiable
>> information.
>
> Not necessarily. The obvious trick is to store hashes of valid addresses
> along
> with per-domain rules for how to strip stuff like subaddresses, prefix
> characters, etc. Yes, a dictionary attack can be performed on this
> information,
> but you can also do that by whacking on the primary MX.
More easily, a backup MX provider can just store each hit it finds.
However, even if cute tricks may rule out any relevant information
leakage, in principle, users should be aware of what organizations
take part in managing their data. Currently, that info is relegated to
a non-machine readable ISP's policy page, if any.
That's ... idealistc, I must say. I doubt very much if most administrators
agree that simply the list of active addresses, with no additional attached
data whatsoever, in their domains have such serious privacy implications.
The rule to strip subaddresses is a good point. Apparently, a regex
might suffice,
At one point I suggested using NAPTR records as part of the address
distribution protocol for secondaries in order to get exactly this effect.
although in some cases passing the complete subaddress
(or its hash) may be preferable.
It depends on what the rules are for unknown subaddresses. A site that limits
subaddresses to the specific ones a user allows would be better off passing the
whole thing. But if unknown subaddresses are simply ignored, as is often the
case, canonicalizing subaddresses away makes the most sense.
What about honeypots?
A regex can be made general enough for those too, I think.
Ned