The messages are processed automatically and are not read by humans other than the recipient. They are reject or filtered to a "SPAM" folder. The expectation of privacy is still met. The ISP is processing the email for acceptance or rejection, it is not redirecting it to another party. Additionally the checks are being done on behalf of the recipient and can often be disabled by the recipient.
With a telegram you have a telegraph operator who types up your message for you then sends it. With a postcard you have a sorter / deliverer who reads the address and sees the message even if it is not read. Neither process is fully automated.
With email you type up your own message and send it into a system that does not require human interaction to deliver the message. The only time a human other than the intended recipient sees a email is when there is a delivery error.
"Lift the buckle" is not the same as "push the button". Airplane seat belts have different mechanisms to most (not all) car seat belts and while you may use a car seat belt 600+ times a year, unless you are a frequent flyer you don't come anywhere close to that in a plane even going to the toilets. The message is telling the passengers that there is a different mechanism in the hope that it will save your life in the event of a survivable crash.
Actually it is utilisation. IPv4 ran out of addresses over a decade ago when NAT no longer became optional for the majority of users of the Internet. Ever since then we have been in stopgap mode. Unfortunately most users have never experience the real Internet when everyone can be both a producer and a consumer.
In most of the world you can use cryptography for authentication even if you can't use it for confidentiality.
Without cryptographically verified authentication you can't even verify the MX or A records are valid so you have nothing to verify against. It is only a matter of time, if they are not already, spoofing DNS responses to enable delivery of their messages.
It's perfectly possible to authenticate email with distributed senders. It just requires willingness to deploy the tools to do it. This includes updated clients. Whether that email is spam or not is a orthogonal matter.
SPF is not a spam solution. Spammers can have legitimate SPF records.
SPF is design so that the recipient can reject forged emails without the blow back impacting the person whose email address is being forged. This only works if the published SPF records reflect reality.
DNSSEC was designed around real world constraints, not the mythical world where every resolver can talk to authoritative servers directly or only through trusted recursive servers. Yes, there are ISP that force you to use their name servers.
DNSSEC is designed to cope with untrusted authoritative servers. Most people don't have the resources to provide the servers necessary for fault tolerance. With DNSCurve you have to trust those operators to not change the data as any change they make can go undetected. With DNSSEC the worst they can do is reduce the effective number of name servers for the zone.
As for OpenDNS you still have to establish a trusted path to them.
Eyeball ISP's that light up IPv6 and control the router see a significant percentage of traffic (double digits) as IPv6.
Content sites that enable IPv6 see ~1% of traffic being IPv6.
ISP's that delay turning on IPv6 are just increasing their long term costs as they will need to install bigger CGN's and will have a bigger customer base to move when the time comes as customers will continue to buy IPv4 only equipment.
For most sites there is not a significant cost or pain to deploy IPv6 these days. The servers boxes already support IPv6 as do the desktops.
For a home user, assuming that their ISP supports IPv6, you are looking at replacing a single router. IPv6 capable routers can be got for around $150 and cheaper ones are coming.
For customer facing servers you turn on IPv6 in the router or check the IPv6 box with the cloud provider. Add a test DNS entry with the IPv6 address for the server and check that your backends work. Once that is done you put a AAAA address on the main DNS entry. If thing break at this sage you remove the AAAA record and re-test.
The day to day costs of dual stack vs IPv4 only is negligible.
Virgin Media are missing the point. Some places in the world have already run out of IPv4 address and Virgin Media have customers that need to talk to those places. There is no good IPv4 to IPv6 solution.
Additionally delaying deploying IPv6 just forces their customers to delay testing of IPv6 with their systems. ISP are already years behind where they should be and this is just Virgin Media using spin merchants to deflect from the fact that they dropped the ball.
Firstly NAT64 isn't tunnelling, it is translation. Secondly NAT64 does NOT work for IPv4 initiated connections. As long as you have legacy IPv4 only devices that need to talk to the world you need a IPv4 path out bound. This could be dual stack, DS-Lite, 4rd.
The difference is that you control the configuration of the NAT in the home. You DO NOT control the configuration of the NAT that the ISP runs. If you have never changed the defaults and do not have applications that depend on UPnP then you are unlikely to see issues with CGN.
If on the other hand you configure port forwarding or or have applications that depend on UPnP then it is likely you will see reduced functionality with a CGN in the path.
And yet it has been done in the past. Australia is a federation of States. Its constitution is all about what State rights are ceded to the Federation. This didn't stop all the measures I mentioned before happening. Each state still has its own driving laws. They are just mostly uniform so you don't have to worry about speeds being presented in different units. Signage being significantly different. etc. We even have electronic tolls harmonised so you can transponders from any state in any other state.
You require the prices to be posted in $/kg, $/l with $/lb, $/oz in smaller type face if present. You require all new road signage to be in km or m or km/h. You require new vehicles to have km/h on the speedo and if mph is there it is less prominent. You re-specify the road rules in km/h. You have the national weather service issue reports in ml, deg. C and Hpa. You require fuel efficiency to be reports in l/100km. You have TV and radio report weather in metric units.
Having lived through a metrication process it isn't difficult to do. Old speed signs just had vinyl stickers put on them. A couple of rules of thumb if you have a speedo that only displays in mph.
Firstly once you have entered a intersection legally it does not matter if the light goes red. Running a red light is entering the intersection on red not being in the intersection on red. Cross traffic is required to give you right of way to clear the intersection.
Living in a city with lots of safety camera that detect both speed and running the red light infractions you get used to them and treat the intersection the same as any other. You approach within the speed limit and you stop on yellow if you can.
It's 100% Facebook's fault. They are the ones that designed the system to not require confirmed opt in before telling the world that you are in a group. This was a foreseeable consequence of that design decision.
IPv6 will still only get you the residence. Privacy address are used by default for out going connections and are changed regularly by the OS. If you run a server then you advertise a service the you use the stable address in the DNS which is constructed from the MAC if using SLAAC.
The address tagged as temporary below will be different this time tomorrow and they are the ones your browser uses when it wants to talk to the world.
The messages are processed automatically and are not read by humans other than the recipient. They are reject or filtered to a "SPAM" folder. The expectation of privacy is still met. The ISP is processing the email for acceptance or rejection, it is not redirecting it to another party. Additionally the checks are being done on behalf of the recipient and can often be disabled by the recipient.
You mean the encrypted data streams. :-)
SMTP, IMAP, POP all support encrypted data streams. There really is no reason these days for email to be sent in the clear other than laziness.
With a telegram you have a telegraph operator who types up your message for you then sends it. With a postcard you have a sorter / deliverer who reads the address and sees the message even if it is not read. Neither process is fully automated.
With email you type up your own message and send it into a system that does not require human interaction to deliver the message. The only time a human other than the intended recipient sees a email is when there is a delivery error.
"Lift the buckle" is not the same as "push the button". Airplane seat belts have different mechanisms to most (not all) car seat belts and while you may use a car seat belt 600+ times a year, unless you are a frequent flyer you don't come anywhere close to that in a plane even going to the toilets. The message is telling the passengers that there is a different mechanism in the hope that it will save your life in the event of a survivable crash.
Which is basically down to lack of experience rather than actual gaps in protocol coverage.
Most ISP's are only now starting to ask "how do I do this". They should have been asking this question 7 to 8 years, if not longer, ago.
Actually it is utilisation. IPv4 ran out of addresses over a decade ago when NAT no longer became optional for the majority of users of the Internet. Ever since then we have been in stopgap mode. Unfortunately most users have never experience the real Internet when everyone can be both a producer and a consumer.
In most of the world you can use cryptography for authentication even if you can't use it for confidentiality.
Without cryptographically verified authentication you can't even verify the MX or A records are valid so you have nothing to verify against. It is only a matter of time, if they are not already, spoofing DNS responses to enable delivery of their messages.
It's perfectly possible to authenticate email with distributed senders. It just requires willingness to deploy the tools to do it. This includes updated clients. Whether that email is spam or not is a orthogonal matter.
MX records are for inbound traffic. SPF is for outbound traffic. Don't mix the two.
SPF is not a spam solution. Spammers can have legitimate SPF records.
SPF is design so that the recipient can reject forged emails without the blow back impacting the person whose email address is being forged. This only works if the published SPF records reflect reality.
Google could deliver IPTV and cut into the TV market as well. TV is digital these days. The analog cable plants are almost all gone.
DNSSEC was designed around real world constraints, not the mythical world where every resolver can talk to authoritative servers directly or only through trusted recursive servers. Yes, there are ISP that force you to use their name servers.
DNSSEC is designed to cope with untrusted authoritative servers. Most people don't have the resources to provide the servers necessary for fault tolerance. With DNSCurve you have to trust those operators to not change the data as any change they make can go undetected. With DNSSEC the worst they can do is reduce the effective number of name servers for the zone.
As for OpenDNS you still have to establish a trusted path to them.
Slides from a Bernstein talk
A quote:
Summary so far:
DNSSEC does nothing to improve DNS availability.
Neither does DNSCurve.
DNSSEC allows astonishing levels of DDoS amplification, damaging Internet availability.
Which is not a problem of DNSSEC per say but a basic problem of DNS. It is also solvable. It just requires will to deploy the solutions.
DNSSEC does nothing to improve DNS privacy.
This was a explicit non goal of DNSSEC.
DNSSEC, even with NSEC3, leaks private DNS data.
No more than DNS leaks private data.
Eyeball ISP's that light up IPv6 and control the router see a significant percentage of traffic (double digits) as IPv6.
Content sites that enable IPv6 see ~1% of traffic being IPv6.
ISP's that delay turning on IPv6 are just increasing their long term costs as they will need to install bigger CGN's and will have a bigger customer base to move when the time comes as customers will continue to buy IPv4 only equipment.
For most sites there is not a significant cost or pain to deploy IPv6 these days. The servers boxes already support IPv6 as do the desktops.
For a home user, assuming that their ISP supports IPv6, you are looking at replacing a single router. IPv6 capable routers can be got for around $150
and cheaper ones are coming.
For customer facing servers you turn on IPv6 in the router or check the IPv6 box with the cloud provider. Add a test DNS entry with the IPv6 address for the server and check that your backends work. Once that is done you put a AAAA address on the main DNS entry. If thing break at this sage you remove the AAAA record and re-test.
The day to day costs of dual stack vs IPv4 only is negligible.
add pass tcp from any to me 22 setup in keep-state
It might not be iptable but it is a firewall rule.
Virgin Media are missing the point. Some places in the world have already run out of IPv4 address and Virgin Media have customers that need to talk to those places. There is no good IPv4 to IPv6 solution.
Additionally delaying deploying IPv6 just forces their customers to delay testing of IPv6 with their systems. ISP are already years behind where they should be and this is just Virgin Media using spin merchants to deflect from the fact that they dropped the ball.
Firstly NAT64 isn't tunnelling, it is translation. Secondly NAT64 does NOT work for IPv4 initiated connections. As long as you have legacy IPv4 only devices that need to talk to the world you need a IPv4 path out bound. This could be dual stack, DS-Lite, 4rd.
The difference is that you control the configuration of the NAT in the home. You DO NOT control the configuration of the NAT that the ISP runs. If you have never changed the defaults and do not have applications that depend on UPnP then you are unlikely to see issues with CGN.
If on the other hand you configure port forwarding or or have applications that depend on UPnP then it is likely you will see reduced functionality with a CGN in the path.
You run dual stack within the home. You most probably already are running dual stack within the home without knowing it.
As for home DSL routers that support IPv6 they exist as do ISPs that support IPv6. Just shop around.
And yet it has been done in the past. Australia is a federation of States. Its constitution is all about what State rights are ceded to the Federation.
This didn't stop all the measures I mentioned before happening. Each state still has its own driving laws. They are just mostly uniform so you don't
have to worry about speeds being presented in different units. Signage being significantly different. etc. We even have electronic tolls harmonised
so you can transponders from any state in any other state.
You require the prices to be posted in $/kg, $/l with $/lb, $/oz in smaller type face if present.
You require all new road signage to be in km or m or km/h.
You require new vehicles to have km/h on the speedo and if mph is there it is less prominent.
You re-specify the road rules in km/h.
You have the national weather service issue reports in ml, deg. C and Hpa.
You require fuel efficiency to be reports in l/100km.
You have TV and radio report weather in metric units.
Having lived through a metrication process it isn't difficult to do.
Old speed signs just had vinyl stickers put on them.
A couple of rules of thumb if you have a speedo that only displays in mph.
Firstly once you have entered a intersection legally it does not matter if the light goes red. Running a red light is entering the intersection on red not being in the intersection on red. Cross traffic is required to give you right of way to clear the intersection.
Living in a city with lots of safety camera that detect both speed and running the red light infractions you get used to them and treat the intersection the same as any other. You approach within the speed limit and you stop on yellow if you can.
It's 100% Facebook's fault. They are the ones that designed the system to not require confirmed opt in before telling the world that you are in a group.
This was a foreseeable consequence of that design decision.
IPv6 will still only get you the residence. Privacy address are used by default for out going connections and are changed regularly by the OS. If you run a server then you advertise a service the you use the stable address in the DNS which is constructed from the MAC if using SLAAC.
The address tagged as temporary below will be different this time tomorrow and they are the ones your browser uses when it wants to talk to the world.
% ifconfig en1 inet6
en1: flags=8863 mtu 1500
inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5
inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf
inet6 fd92:7065:b8e::9839:c2cc:8436:dd0b prefixlen 64 autoconf temporary
inet6 2001:470:1f00:820:6233:4bff:fe01:7585 prefixlen 64 autoconf
inet6 2001:470:1f00:820:2c19:2778:d2ee:a35b prefixlen 64 autoconf temporary
%
And there are 35184372088832 /48's available for allocation based on current IPv6 allocation rules. More than enough for everyone to have several.