Email system provision is unregulated in the UK.

rmg1

OK, so maybe a bad example.
But ..... my basic premise still remains valid. It's not entirely out of the question to set up this database and for all email providers to refer to it.
The only people that would sign up to it are those who wanted to keep their email address when they move ISP.
It could even be done as part of the MAC process, something along the following lines:-
Me: I want to change ISP, can I have my MAC please?
Current ISP: One MAC as requested.
New ISP: Have you got a MAC?
Me: Yes, here you go.
New ISP: Have you got an email address you want to keep?
Me: Yes, it's [EMAIL="abc@123.com"]abc@123.com[/EMAIL]
New ISP: No problem, we'll get that set up for you.

New ISP writes the record to the database and it's gets propogated around all the other email providers as necessary.

So, starting database is empty and records are written to it as necessary.

SMTP will need to change slightly to refer to this database to begin with. If a record is found re-route the email to the new address. If no record is found, route email to initally stated address. I don't know how big a change that will be, but I doubt it's beyond the realms of possibility and current technical know-how of people who design these things.

I realise this is now going seriously of-topic (we're getting away from email regulation and onto re-routing emails) but I really don't see the technical or logistical impossibilities in implementing this.

Trinitrotoluene

rmg1 wrote: »

but I really don't see the technical or logistical impossibilities in implementing this.

To understand the technical limitations you have to understand how the process works for e-mail, at a slightly detailed level it goes like this:

In the below, the sender will be ray@projectbuild.co.uk and the recipient will be bob@engineeringdesign.com

1) User generates an e-mail, with an address in the TO field and a subject/message

2) User submits e-mail

3) User's mail server takes the e-mail, and puts it into a queue

4) User's mail server evaluates the end of the recipient e-mail, in this case engineeringdesign.com

5) The server performs a DNS lookup to find the Mail Exchange (MX) record for the domain engineeringdesign.com. It does this by asking the root .com DNS servers where the domain name servers are for engineeringdesign.com. The root .com servers provide an IP address as the answer.

6) The server then performs another query to the engineeringdesign.com DNS servers asking for a mail exchange record. This record gives the IP Address (or A record which resolves to an IP address) of the server that is responsible for accepting mail.

7) The senders server now knows where to deliver mail for that domain. It initiates a connection over port 25 using an application layer protocol called SMTP. The connection looks a bit like this:

a) HELO projectbuild.co.uk <-- The sender identifies themselves
b) 250 mail.engineeringdesign.com Hello <-- The recipient server acknowledges the initial contact
c) MAIL FROM: ray@projectbuild.co.uk <-- The sender gives the e-mail of the sender
d) 250 Sender OK <-- The server accepts the sender
e) RCPT TO: bob@engineeringdesign.com <-- The address it is sending to
d) 250 Recipient OK <-- The server performs checks and then OKs the recipient
e) DATA
SUBJECT: Subject Here <-- start the message and give subject
f) Hi Bob, bla bl bla <-- Message Content sent
g) . <-- a single period followed by a return character will signify the mail is finished
h) Message accepted for delivery
QUIT
250 OK

The server sends back a response code (250 indicating the exchange was accepted and the server disconnects). The recipient server then routes the message to the recipients mailbox. In this case bob@engineeringdesign.com.

There's a reason I've gone into so much depth here, which will become evident shortly. You can probably see there is much room for abuse with this system, which is why there are significant amount of anti-spam technologies built on top of it. A lot of these systems rely on knowing the definitive sender and the definitive recipient. They also rely on knowing that a) e-mail addresses are valid for the servers accepting mail for said e-mail addresses and b) the server at the other end can validate the person sending the message is who they say they are via numerous other checks.

Now that you know how e-mail works, you may be able to see why your solution would never work. Here is an example:

1) I am with ISP A with e-mail address bob@ispa.co.uk
2) I sign up to a newsletter for garden gnomes, using my bob@ispa.co.uk address
3) I move to ISP B, but I take my e-mail address with me as per your process. This requires, at a basic level, a change in SMTP to know to do a lookup on the database at ISP A to know that ISP A no longer has my address, but ISP B is now responsible for my delivery
4) However my Garden Gnomes newsletter server is in the USA.... they chose not to adopt the UK regulation because it didn't make sense. You never get the e-mail - it fails because the server can't recognise where your mail server now is.

Major Point 1: The relevant changes to the SMTP protocol would need to have universal agreement and propagated globally, or e-mail delivery for people moving from ISP A to ISP B would never work.

At it's basic level, your initial idea of having a database that replicated across all mail servers with all e-mail address changes would require a much more complicated and costly infrastructure change. It would make much more sense to have the mail server(s) for each domain a unique database of e-mails that have been transferred from its responsible domain. Then there is no need to share databases across servers.

Now then, lets say this system is in place. For delivery of mail to occur, the sending server has to query ISP As server to determine where my mail server now is, and ISP Bs server to actually deliver the e-mail. It is not a interdependent infrastructure, if ISP As server is down/removed/gone bust, I will not longer get my e-mail and there will be no mechanism for me to get my mail.

Major Point 2: The procedure for mail delivery gives scale to inherent failure as it relies on multiple servers being operational across multiple companies.

This leads me to my next point, lets say I now move to ISP C. For this to work ISP B would have to contact ISP A to update the record to my now third ISP.

Major Point 3: Massive legislative and administrative burdens would raise prices for the consumer. One of the main benefits of the current system is it is largely automated and needs no user involvement.

This leads to the next point - identity management. For this system to work it would be necessary for EVERY GLOBAL mail server to have the ability to facilitate changes to their database of e-mails that are now being forwarded. Each change to this database would need to have the identity verified for person requesting the change.

Major Point 4: No feasible way for people administrating mail servers to verify the identity of the person requesting the mail forward. This gives scope for massive fraud, massive costs in administrating changes as identity needs to be verified.

Anti-spam would be much harder, in the current system ISP A knows it can reject messages that are not addressed to ISPA.co.uk as they are not valid. It is not able to do that anymore, it would have to know that the domain is valid for every user on its system, which would mean it would have to have a database updated on its own system for the mail addresses it has.

Major Point 5: When an e-mail has been migrated more than once it would require the database updated synchronously with its own server and the first server in the mail chain. This would mean that services like @gmail.com would need to maintain an active database of half a billion addresses - an administrative nightmare. It also means companies who no longer have paying clients have to fund the servers and staff required to facilitate the forwarding of e-mails for people who are not paying for any services

That brings me to provisioning e-mail addresses. If I sign up for ISP B and want to move the mail address there, this requires human intervention. No more instant provisioning of e-mail addresses for people.

Now - lets dealing with sending e-mail. It's not just receiving mail we have to consider, it's the user sending e-mail address out as their old e-mail address.

Major Point 6: There would be no way to validate that the sending e-mail server is a valid e-mail server for the domain in question. In point 7) c) of the process I gave at the beginning of this wall of text, the server that is receiving the e-mail is able to perform something called an SPF lookup. This lookup basically queries the DNS SPF entry of the sender to find a list of mail servers that are valid for that particular address. This system stops me sending mail to people and pretending my e-mail address is, say, bill.gates@microsoft.com. Spammers would jump on this immediately and e-mail would become unusable. This would not only break SPF checks but also Reverse pointer checks which is another anti-spam method to make sure the e-mail is coming from a server that is valid for it to send from.

To address your specific points from my previous answers:

No it doesn't, it only requires co-operation of anyone who wants to keep their email address when they change ISP.

As you can see from above, it would be a requirement for all mail servers to maintain their own copy of a transfer database, or the sending server with an older version of SMTP would have no way of querying the database to ensure it is sending mail to the proper place.

True, but then again the opportunity for abuse is already there with the current setup, albeit on a smaller scale.

I also hope I've demonstrated how with such increased complexity in the systems it would be open to fraud at a much wider scale. Not only that but e-mail delivery would be less resilient as it relies on multiple servers to get mail where it needs to go.

Why would you be interested in the middle-points if someone has moved ISP several times? You need the address it was sent to and the address it needs to arrive at (and maybe the date of the last change). OK, double the size of the database, still not beyond the realms of possibility.

Because you need some way of validating that the person who wishes to transfers is the person who actually owns that e-mail address. Lets say I move from ISP A to ISP B to ISP C and take my ISP A e-mail address with me at each move. 5 years down the line ISP A will have no way of verifying who I am when I ring up (or ISP B ring up) to request they forward my e-mail to ISP C. There needs to be a verifiable chain.

Who funds all the companies that register website names? Assuming this needs to be funded separately, 10p for every email address currently in use would soon generate quite a bit of revenue. Make that a monthly charge (£1.20 a year isn't a huge amount, less than a website).

That figure is far off the real cost this would be. There are 2.2 billion e-mail users worldwide - in this scenario each one of those would need access to a human if they need to forward their e-mail address elsewhere.

Such as? I've dealt with database replication on large-scale databases in SQL. It all hinges on the initial set-up for the transaction logs (and how many changes do you envisage there to be on a daily basis)? Reading records (even trillions of them) isn't difficult if you have the right set-up.

I know I discounted this initially but the reason this method wouldn't work:

1) Increased load on mail servers with a requirement for more RAM/CPU/Disk Space

2) Assuming you meant MSSQL - licensing costs for each mail server (and it would have to run windows)

3) Assuming you meant MYSQL - this would need installing and configuring this on every mail server, having a hierarchy in place for master/slave and identifying which server has the right to make changes to which record

4) As mail would be reliant on installed applications, which replicate databases it would be difficult to make this platform neutral. IE it can't be negotiated at a protocol level.

That's why it wouldn't work either technically or in any other way. Wow this post was long.

wealdroam

vofs007 wrote: »

Only 24 hours left to sign the petition. If email is important to you, please register your concern. You know it makes sense.

http://epetitions.direct.gov.uk/petitions/48917

I see that e-petition closed with a total of twenty-five signatories.

That's increase of one since this thread started, and ninety nine thousand nine hundred and seventy five fewer that the number needed to stand a chance of a debate in The House of Commons.

So near...

cookie365

So which one of us signed it 'ironically' at the last moment? Wasn't me, I promise

securityguy

Trinitrotoluene wrote: »

2) Assuming you meant MSSQL - licensing costs for each mail server (and it would have to run windows)

3) Assuming you meant MYSQL - this would need installing and configuring this on every mail server, having a hierarchy in place for master/slave and identifying which server has the right to make changes to which record

Essentially every large mail server is using some sort of SQL database already (except for the very large sites using a NoSQL product), because it's required for authentication, backend routing (it's not 1986 and we aren't just delivering into /usr/spool/mail/$USER any more) and in plenty of cases actually using the database as the mailbox storage. The argument that poor benighted mail administrators would be confused by the need to run a database is bizarre.

In any case, your basic argument is wrong. Mail systems which need access to such a database wouldn't use SQL anyway, they'd use some form of RESTful web service or LDAP. Both of those are in daily use in the mainline of standard mail products.

As I've said consistently through out this thread, the bloke's idea of regulation is silly. That diverted into a discussion of "email address for life" and the technical arguments advanced against it are frankly weak. If there were market pressure, it's relatively easy to do: a couple of trusted third parties would run the directory and it would be referenced via a web service. It would require small changes to the mailers of participating organisations, nothing more. I don't think there's actually a real requirement, but I would be perfectly happy to sit in a room with the appropriate people and deliver the proverbial rough consensus and running code, because it really isn't that hard. There are scalability issues, but they really aren't significant by comparison with other large infrastructure projects. The issue is of need (low), will (minimal) and willingness to pay (zero), and scalability, not fundamental complexity.

securityguy

To answer a few of your points.

The SPF point only arises if people are to be allowed to continue to send mail from the domain they are no longer a subscriber to. As well as SPF, that also breaks DKIM, which is probably at least as serious. If people were to be allowed to continue to send mail from their old addresses, the only way to do it would be for the operators of those domains to continue to offer authenticated SMTP access to former users, which I doubt they would. It would also hugely complicate the user experience. I have several old email addresses of mine forwarded to me, but I can no longer send mail from those domains. That seems reasonable.

The authentication problem is a non-problem. Possession of access to the target mailbox is sufficient: if you want to redirect mail for account X, a confirmatory piece of mail containing a URL is send to account X prior to the update, which is confirmed by clicking on the link. You'd have to set the forward up before you lost access to the last known contact address. That's not unreasonable. Part of the setup of such a scheme (note that I'm not advocating it, quite the contrary, just kicking ideas around) would be a two week grace period on cessation of contract during which you can continue to access your email for such purposes.