Crypting mail addresses - funny design problem - database

In my web project, I am storing mail addresses. These addresses may be used by the system to throw mails to the recipients. It is also important to say that these mail addresses have expiration time.
But the critical point is trustness: for this very service, people must be sure that the mail addresses wil not be given to somebody else (especially to authorities, for example).
To resume:
the system has to "know" the mail address.
the webmaster (or somebody else) has to be unable to find the true mail addresses.
By doing this, the webmaster will not be able to give information (even by force :)).
Intermediate solution: I already know how to do this as soon as the information has expired. E.g. The mail address is encrypted with gnupg (GPG / PGP algorithms). The system (or anybody) can decrypt if he/it has the password. But as soon as the mail address has expired, let's revoke the secret key :arrow: one cannot decrypt the mail address anymore.
But this raises a performance problem (to create the private key)...
Any help would be most appreciated !

What you're asking for is impossible. Even supposing you could devise a system whereby the system can send emails without being able to reveal them to an administrator (and you can't), an attacker could simply start a mail run and capture the outgoing emails and extract the addresses before they're sent.
If you want to 'expire' email addresses, you should simply delete the records, then (if you're paranoid), compact the database and erase the free space on the disk.

Related

HLR LOOKUP service building

Newbie here. Can someone teach me like im 6 years old?
How can I do my own hlr lookup without paying a companies?
I see some people send some company links who offer hlr lookup.Thats not what I'm looking for...
I made some research and couldn't find much about how can I build a hot lookup.
Any help would be great.
Hi sdaassadasdasd asdasdsad,
TL;DR you can't perform your own free HLR lookup against telephone numbers on the public telephone service (formally called the PSTN), which is why you can find online providers who provide it as a paid service. There is always a charge, even to the HLR lookup providers.
It also depends what do you want to achieve. A HLR Lookup will let you know if a mobile phone number is assigned to a subscriber of a mobile network operator (MNO), and which MNO it is assigned to.
HLR lookups don't provide location (aside from some rudimentary country-wide location based on the Mobile Switching Centre that the telephone handset is being controlled from). They also don't usually provide an IMSI if that's what you are looking for, because these days most MNOs will implement home-routing which gives a temporary IMSI matched on their router so that they can conceal the real IMSI (to avoid fraud).
So, if you do want to perform a HLR lookup to check if a mobile phone number is "real" and assigned to a subscriber on a public network then I'm presuming you want to send a HLR request to query an external MNO - i.e. a public telephone number, not a local one running on your own equipment.
To query an external MNO then you will need to send a request, usually over the SS7 network, to the mobile network operator who was originally assigned the telephone number you want to know about. Eventually, if you have done everything correctly and the MNO wants to respond, you receive a response back which gives you the details you need to then ascertain if the telephone number is assigned to a subscriber, and if the subscriber is active on the network or not.
To send the HLR request, without going through an online provider, you will need at least:
equipment that talks the SS7 protocol (specifically to include MAP requests because a HLR is a type of MAP request)
somewhere to host your equipment
an SS7 interconnection from an SS7 backbone provider
point codes allocated from the SS7 backbone provider
someone to setup program the equipment
your own telephone prefix range for the far-end MNO to be able to respond back to your original request. You may be able to lease someone else's telephone number range if you don't have your own.
Once everything is setup then there's an additional per MSU (message signalling unit) cost. You can think of an MSU a bit like an IP packet, you send "one" and you get a response. You are charged by the SS7 backbone provider for every MSU you send that transits their network, regardless of if you get a response back from the MNO you want the message forwarded to.
I'm happy to answer any other questions on it, but I can't think of a way you can perform your own HLR lookup without incurring charges somewhere along the line.

windows desktop notification

we want to build an application (c#/.Net) for the following Scenario:
internal "alert System". Users should be informed about it-system outage, planned downtime for Services and so on.
only one-way : central Service will push Messages to user
we also Need the possibility to enable/disable a message, for example:
The message "there a Problems with mail System" should be removed from every Computer after the Problem is solved
we want to shedule Messages for planned maintanance
about 1000 windows Clients, we also want to "group" this Clients, so we can control which Client will get a message
First thought was writing small application which will query every X seconds a central database for new and existing Messages.
Maybe somebody has already worked on similar Project?
Is a Client with database query a way to go? Better to use other Technology, like WCF Service?
Thanks for your help
Marc
Sounds like you need an enhanced version of push notifications.
I'd suggest using push for all the messaging, it's delivered faster and I find it more reliable. Simply make the client connect to a message server and maintain the connection open. Whenever a message is supposed to be displayed to the client, have the server push it trough the connection (that's where the name comes from).
To group and manage the clients you could use a database, it's probably the best way to go, but the server needs to handle all the open connections, and databases can only store DATA, not virtual objects representing a connection, so the server software need to manage them in a different way.
My suggestion: Whenever the server receives an incoming client connection, it will accept and query the client computer for a ID number that will also be used to find that client's information in the database.
Then it will create a dictionary using that ID as key, and the connection as the value.
This way at the time of sending a message to a determined group, you can do in two ways:
1) You can load from the database the IDs that belong to that group, and then send the messages to them. You will have to check whether that ID exists in the dictionary's KEYS array, because it is possible that a determined client is not yet connected.
2) You can iterate of the KEYS array of dictionary, check to which group that ID is part of, and if it is the desires group, send it.
If you're dealing with a big number of clients, I suggest you use method 1.
To disable/remove a message from the client's computer, simply have the server send a special Command message that the client software interprets as "remove that message". To make this possible every non-command message must have unique IDs, so that command messages can tell the client software which message that command applies to.
Your project sounds very interesting.
I would be glad to help you by writing a library you could use, or just help you figure it out on your own if you prefer. (Free of charge, just for the experience).

Is it a good idea to use Database Mail as an email relay server?

One of our problems is that our outbound email server sucks sometimes. Users will trigger an email in our application, and the application can take on the order of 30 seconds to actually send it. Let's make it even worse and admit that we're not even doing this on a background thread, so the user is completely blocked during this time. SQL Server Database Mail has been proposed as a solution to this problem, since it basically implements a message queue and is physically closer and far more responsive than our third party email host. It's also admittedly really easy to implement for us, since it's just replacing one call to SmtpClient.Send with the execution of a stored procedure. Most of our application email contains PDFs, XLSs, and so forth, and I've seen the size of these attachments reach as high as 20MB.
Using Database Mail to handle all of our application email smells bad to me, but I'm having a hard time talking anyone out of it given the extremely low cost of implementation. Our production database server is way too powerful, so I'm not sure that it couldn't handle the load, either. Any ideas or safer alternatives?
All you have to do is run it through an SMTP server and if you're planning on sending large amounts of mail out then you'll have to not only load balance the servers (and DNS servers if you're planning on sending out 100K + mails at a time) but make sure your outbound Email servers have the proper A records registered in DNS to prevent bounce backs.
It's a cheap solution (minus the load balancer costs).
Yes, dual home the server for your internal lan and the internet and make sure it's an outbound only server. Start out with one SMTP server and if you get bottle necks right off the bat, look to see if it's memory, disk, network, or load related. If its load related then it may be time to look at load balancing. If it's memory related, throw more memory at it. If it's disk related throw a raid 0+1 array at it. If it's network related use a bigger pipe.

Exchange 2010 message tracking log to database

I have Exchange 2010 running and i need to track all the emails. I have made a program to get emails from Exchange and do what i need, but the problem is, that if user deletes email or moves it to archive, i can't access it.
Is there a way to make Exchange to write message tracking log to database? Or at least a way to launch program when email is received?
Is good that you wrote an application to do this, but you shouldn't had. Exchange already has Mailbox Audit Logging features and that what you should use, see Understanding Mailbox Audit Logging. You can configure Journaling which automatically records all incomming and outgoing mails. This is a complex topic and rather than re-invent the wheel, I recommend reading about what is already available.

Restrict number of requests from an IP

I am writing an application wherein its a requirements to restrict the number of logins a user can have from a single IP address (as a way to stop spam).
We can't use captcha for some reason!
The only 2 ways I could think of to make this work was to either store in the database, the number of requests coming in from each IP.
OR
To store a tracking cookie which has the information regarding the same.
Now, the downside of the first mode is that there would be too much of db traffic - the application is going to be used by a ton of people.
The downside of storing this info as a cookie is that users can clear them up ad start fresh again.
I need suggestions, if there could be a way wherein the high db traffic and the loose bond with cookie based tracking can be handled.
You're talking about "logins" and a web-application therefore you have some sort of a session persisted somwhere. When creating those sessions you need to keep track of the number of active sessions per IP and not allocate new sessions when that threshold is reached.
Without more specific information about your framework / environment, that's about the best answer anyone can provide.
Also be aware that this approach fails in numerous ways because of NAT (network address translation). For example, our office has exactly one public IP address for X hundred people. The internal network is on private IP space.
if you want to get the IP and store somewhere, you could use $_SERVER['REMOTE_ADDR'] to get the IP of the user, make a field like "ip" in your database and you make a query in your SQL to check if the IP was used.
There are also other ways of tracking, like Flash Cookie, people usually don't know the existance of it, so most people wouldn't know how to clear it.

Resources