One slowly emerging story I've been following is the "IPocalypse" -- the
exhaustion of IPv4 internet addresses. This will almost certainly be
the first year in which reasonable (by previous years' standards)
requests for new IP addresses will be denied due to shortage.
This will probably affect e-mail more strongly than other protocols,
because this very scarcity makes spam-fighting easier -- if
reputation-burned IP addresses cannot be replaced, then blacklists will
both have a greater immediate effect, and cause more pain to lax ISPs.
In turn, that means even e-mail servers with a working IPv6 connection
may find it profitable to only accept mail over IPv4.
So, any entity that wishes to send mail will have to obtain at least one
public IPv4 address, far into the future. As this becomes harder, they
will have to share.
Now ideally this sharing would take place via a dualstack smarthost
server that can recognize each individual client organization (via SPF on
IPv6, TLS, DKIM, whatever) and stop them from forging each other. But
they may only be able to get a laxly maintained smarthost, or even just a
NAT/PAT box.
For such an organization, the correct SPFv1 record would be something
like:
example.com SPF "v=spf1 ?a:six-to-four.example.net -all"
which would be less definite than we'd like.
To fix this, we should add one or more flags to indicate other indicia
than the IP address.
One obvious one, which I have suggested before (but as a
forwarding-problem solution), is a modifier that indicates all
legitimate mail bears a DKIM signature against the envelope sender.
(This would be orthogonal to the DKIM project's own ADSP, which is
concerned with the From: address. From: and MAIL FROM: aren't always the
same.)
Another approach is a flag to require a TLS certificate. This has the
advantage over DKIM of allowing forged connections to be rejected at
RCPT or earlier -- DKIM must go to DATA to be inspected. But it would
only help with NAT/PAT sharing, not with actual smarthosts.
---- Michael Deutschmann <michael@talamasca.ocis.net>
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110306032607:614872B2-47CB-11E0-95E8-917A24E42A5B
Powered by Listbox: http://www.listbox.com
exhaustion of IPv4 internet addresses. This will almost certainly be
the first year in which reasonable (by previous years' standards)
requests for new IP addresses will be denied due to shortage.
This will probably affect e-mail more strongly than other protocols,
because this very scarcity makes spam-fighting easier -- if
reputation-burned IP addresses cannot be replaced, then blacklists will
both have a greater immediate effect, and cause more pain to lax ISPs.
In turn, that means even e-mail servers with a working IPv6 connection
may find it profitable to only accept mail over IPv4.
So, any entity that wishes to send mail will have to obtain at least one
public IPv4 address, far into the future. As this becomes harder, they
will have to share.
Now ideally this sharing would take place via a dualstack smarthost
server that can recognize each individual client organization (via SPF on
IPv6, TLS, DKIM, whatever) and stop them from forging each other. But
they may only be able to get a laxly maintained smarthost, or even just a
NAT/PAT box.
For such an organization, the correct SPFv1 record would be something
like:
example.com SPF "v=spf1 ?a:six-to-four.example.net -all"
which would be less definite than we'd like.
To fix this, we should add one or more flags to indicate other indicia
than the IP address.
One obvious one, which I have suggested before (but as a
forwarding-problem solution), is a modifier that indicates all
legitimate mail bears a DKIM signature against the envelope sender.
(This would be orthogonal to the DKIM project's own ADSP, which is
concerned with the From: address. From: and MAIL FROM: aren't always the
same.)
Another approach is a flag to require a TLS certificate. This has the
advantage over DKIM of allowing forged connections to be rejected at
RCPT or earlier -- DKIM must go to DATA to be inspected. But it would
only help with NAT/PAT sharing, not with actual smarthosts.
---- Michael Deutschmann <michael@talamasca.ocis.net>
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110306032607:614872B2-47CB-11E0-95E8-917A24E42A5B
Powered by Listbox: http://www.listbox.com