A digital certificate issuer says that:
- an email will be sent to "registered owners" of the domain (ex. croraf.com).
How does he know who the "registered owners" of the domain are? (and how can I tell in general who the registered owners of some domain are)
NOTE: Below that it gives the option to "send an email to admin#croraf.com, webmaster#croraf.com, hostmaster#croraf.com". So by registered owners it is meant something else (perhaps names in whois lookup of the domain).
The convention is to use hostmaster, postmaster or some other "well-known" email address at a domain which is likely to be held by an entity enabled to act on behalf of that domain.
They may also pull from the whois data. e.g. for stackoverflow.com it would be reasonable to allow the email to be sent to sysadmin-team. The whois data is fairly indicative of someone who is responsible for the domain, because anyone who can cause the domain's whois data to change has the ability to repoint their DNS authority to another service (where they presumably have the ability to modify things), making someone who has "whois-edit" permissions capable of completely subsuming the domain. Therefore, whoever they say is trustworthy is as good as anything else.
Related
I am building an application using Ruby on Rails. I want to do something that I am not even sure is possible;
I have a mailer that is working, however I want to enable users to send emails using their own email address in the FROM parameter. Its almost as if the ":from" parameter has no effect on the email sent.
I'm a bit of a noob when dealing with email servers so please be as detailed as possible. I doubt there is a smtp mail server set up on my hosting account, so if I need to do something like install smtp on my hosting account please be as descriptive as possible.
You are able to set the From: field to whatever you want, theoretically, but in practice you are often limited as to what you can put in there. Many email providers will automatically replace the From address with your own regardless so that you can't masquerade as someone else.
You're probably intending to do something like this:
From: Example Customer Name <name#example.com>
Also keep in mind that sending email from arbitrary domains will result in a very high chance of being flagged as spam since you are most likely not listed as as a host authorized to send for those domains which is typically implemented with SPF.
The best practice is to set the address to be something like this:
From: Example Customer Name <you#yourdomain.name>
That way you're not spoofing your actual email address, only the associated label, which is not typically verified.
I need to check email accounts whether exists or not, I need to do that using Delphi and Indy (if possible)
I have a windows database for ERP system and I need to make sure that the customer enter valid email into the system so I can send to my customer the quotes they request.
I tried to test on yahoo and google using send commands HELO, MAIL and RCPT but no success.
Mail servers have to protect themselves against spammers and others with malicious intent. They are not going to give up their secrets easily. It is common for mail servers to be configured to black hole messages sent to non-existent recipients. They don't respond to the sender saying, "sorry, that user doesn't exist, please try again."
So, if you want to verify whether or not an e-mail address has a human behind it I think the only way to be sure is to send an e-mail requesting a response.
You have to ask your customers to confirm their email address, i.e. entering it twice to reduce misspellings, asking to register and sending an activation link and so on. State explicitly they need a valid email address: if they're asking you a quote why should they enter an invalid address? But be aware some people may use disposable email addresses to protect their real ones.
You have no way to check if an address really exists just asking its server. Due to the large amount of spam and techniques implemented by spammer to harvest and clean their addresses lists, most servers are setup to defend themselves.
That's why I suggested to "be polite". I am sorry if you got it the wrong way, I was just telling you that if your application shows a "spammer-like" behaviour (and your previous version of the question was much unclearer about your aims), it can lead to your IPs being blacklisted. Then you can have much more troubles to send quotes to customers.
You may try ICS components, an open source library with good examples (see SMTPClient).
So this library or another one will not tell you if an email account exists or not because it's depending on the way the host answer to the commands about a non existent account.
In ICS, when the command have been sent you may have to manage an event : SmtpRequestDone(Sender: TObject; RqType: TSmtpRequest;ErrorCode: Word);
Where ErrorCode is the Error code (ie 550).
I have built several applications in delphi using the indy components suite(version 10.5.2 i think) and they all are working. I have just finished setting up the POP3server and it works locally. I can see mail sent locally on there. I have been using "localhost" as my hostname. However, i want to graduate to a higher level of function. I want to be able to receive email from the internet such from msn, gmail, yahoo ... The problem is I don't know how to do this. What address should I be using inorder to do this? So far "myhouse#localhost" has been working but only internally; can't seem to get external mail in there. Is it possible to receive mail like this? Thanks.
You need to register a domain, and then setup its DNS records (in particular, its MX records) to point to your server machine. That way, when an email is destined for any "#yourdomain" address by any sending service, it will be routed to your server machine (which needs to run an SMTP server to receive emails - POP3 is for downloading emails from your mailbox, not for putting emails into it). If your server does not have a static IP, then you need to use a service like DynDNS to mange the DNS records for you so they can account for your dynamic IP whenever it changes.
"The Internet" doesn't use POP3 to send and receive email, it uses SMTP. Here's how email "flows" from the sending computer to the receiving computer:
Server needs to send email to address: myhome#localhost. The first thing it does is isolate the server name, that's the part after "#". Next it uses DNS to lookup the SERVER IP for the computer that's supposed to receive email for the given domain. DNS contains a special record for this purpose, it's called the "MX" record. You can use command line tools like dig on Linux or nslookup on Windows to find this address, or you can use an online tool like the one found at http://www.mxtoolbox.com/ (google found this site, I assume there are many others!).
If you try to locate the MX record for your "localhost" domain you'll obviously discover it's not possible, because it's not a fully-qualified name. You first need to get yourself an domain name, so you can register a MX record!
Things you need in order to RECEIVE email
Need an "real" IP address. Servers outside your local network need to contact your server, and they obviously need a way to do it. Make sure no routers along the way block SMTP ports.
You need to register an domain name, add a MX record and point it to your "real" IP address.
Need to run SMTP server software on your box. You can use Indy components to write one.
Things you need in order to SEND email
Theoretically sending email with SMTP is the easy part. You just contact the responsible server using SMTP and send email, that's the way the protocol works: any computer in the world may send email to any SMTP server.
Practically sending email is the most difficult thing you'd have to do, mostly because foreign SMTP servers don't trust you (ever heard of SPAM?). Here are some of the things you might need to do so foreign SMTP servers accept email from you. There's no definitive list because the protocol itself doesn't include a clear authentication mechanism, so every big SMTP server out there uses it's own heuristics to decide rather to accept email from you or not. You'll find yahoo especially fun!
You need to have REVERSE DNS for the IP you're using to send email.
You need to send from one of the SMTP servers listed in DNS as your MX servers.
Your DNS records need to have long TTL (this rules out Dynamic DNS services)
Many other things...
What people usually do?
eMail is hard, there's a surprisingly small number of full SMTP servers available for your own server: Exchange, Notes, Postfix, QMail, Sendmail. They're all notoriously difficult to configure. Most people would use hosted mail services, some people would use the SMTP services provided by the ISP, and very few would install one of the mentioned services.
If you really want to write your own SMTP server go ahead, but you might want to install one of the ready-made ones before, to get a bit of eMail and DNS experience. The Linux ones are cheap to install and may also help with development (you don't want to send too much bad email to your free yahoo address, you might get blacklisted!)
POP3 is a protocol to read email from a mailbox. The TidPOP3Server component implements a POP3 server (and AFAIK it has no host property to set...), while TidPOP3 implements a POP3 client. To read mail from GMail or any POP3 server you need a TidPOP3 component. The hostname to set is the DNS name the service instructs you to use (i.e. pop3.mydomain.com).
I have a web app that requires a user to have an account. This user can then vote 'once' on a specific item. However, some users are signing up for lots of accounts to 'game' the system.
Does anyone have any ideas how you can restrict this type of thing?
Could I restrict number of signups per day per IP address? (what are problems with this?)
Any other suggestions???
You would do yourself one better by restricting the sign-ups to just a single IP address per user. This may not be good if you plan on having families all living under the same roof to have their own accounts, but in most cases this is practical.
Yes, restricting signups per IP is reasonable. I'd probably go with signups per rolling time period (say, a maximum of one new account in any one-hour period per IP). You might also flag suspicious signups (say, more than five per day per IP) for later followup.
You might also restrict users from voting until they've passed some hurdle, similar to SO's reputation system. Prevent poll voting until they've been a user for a week, have posted at least twice, have one friend request, etc.
I remember when I ran a online RPG I flagged when more than 5 or so accounts logged in with the same IP in the same day.
People mention the NAT issue. Read the header x-forwarded-for and compare that to the standard ip address.
If x-forwarded-for is present use this value. Most properly configured NAT routers will populate this field. The only ones that do not are typically anonymous proxies.
If you really are worried about people gaming the system, using a flash bit that uses sockets to connect, and provide say, session id, to the socket listener. You can then compare that with the ip address and x-forwarded for. If it does not match, they are behind an anonymous proxy. You could feel safe to not allow them to create accounts.
This works because most anonymous proxies out there aren't full Socks proxies where all network traffic goes through it, just HTTP. This worked very well for me in the past where we had a contest with voting and folks were using anonymous proxies to game the system.
Instead of limiting by account, you could set up limitations by email address. If users need to provide their email address, you already create one hurdle for them. Make sure they have to respond to a confirmation email to make sure the email address is real. Also keep track of email address and IP address, marking any count as suspicious where a single IP address has e.g. 5 or more email addresses. (In which case you could check those addresses to see if they are somehow related, like all from the same domain or similar names.)
Sure, people can create dozens of email addresses using GMail or Hotmail or even if they have their own private domain. But for many people this is already a bit too much. Basically, if you see 5 email addresses from gmail.com with the same IP address, it's suspicious.
One potential problem is if your users are behind a NAT such as a home router, ISP proxy, or corporate firewall. You will see the same IP for all of them.
Instead of blocking people I would simply record their IPs, create a report of duplicate IPs that you can run periodically to investigate suspicious activity.
In addition you can take a social approach, post the user's IP somewhere. This will provide a gentle warning and disincentive to people who fake accounts, as well as allow your community of users to potentially identify fakers.
I would recommend implementing a different authentication mechanism such as OpenID, or are Alex said, force the users to specify a valid email and send them confirmation links via email before accounts get created.
My preference is OpenID for sure.
I have figured out all the necessary steps to get DOD CAC card based client certificate authentication working in Apache, but am now struggling to pull a good GUID for the user from the certificate I am receiving. Is there a GUID available on the certificate that will not change when the CAC card is renewed? I was thinking of using the SSL_CLIENT_S_DN which would look something like:
/C=US/O=U.S. Government/OU=DoD/OU=PKI/OU=CONTRACTOR/CN=LAST_NAME.FIRST_NAME.MIDDLE_NAME.0123456789
but I have heard that the number on the end changes when the CAC card is renewed. Is this true? Is there a better piece of information to use for a GUID? I'd also like to get the users email address, but I don’t see it available in the information I am receiving from the certificate. Is the email adress available in some custom extension that I am not seeing?
Thanks!
We have run into plenty of instances where that number on the end changes. We were eventually beaten into using a process where that if a user gets a new CAC, we require that the user re-associate that new card with their user account. That's the process on most DoD systems now, such as DKO (Defense Knowledge Online) and others. If we do not have the supplied CAC certificate's data in our database, the user must log onto the system using a username and password. If the credentials are correct, the identifying information of that CAC is associated with the user's account in the system.
At least that's how we did it.
And, as far as, getting access to the email address, #harningt is correct. It depends on which certificate is supplied to you.
The DOD EDI PIN should NOT change.
I can give you plenty of instances where you can go to the DOD411 site (CAC required) to look up somebody and it will show certificates from when they were a contractor and then show the same person again, now as a DOD civilian (we see this alot with new hires).
I just looked up one of our new hires who has variously been in the Air Force, then a contractor for the Navy, then a contractor for the Army, and now works for us as a DA Civilian.
Same DOD EDI PIN.
The CN (Common Name) can change (e.g. resulting from marriage), but the ten digit DOD EDI should not change.
As to what certificate to authenticate against, most sites are authenticating against the email cert, but some do use the identity cert instead.
Mike
I'm sure you've all figured out your answers by now. But for others coming to this post later just a couple notes:
This is the DISA reference site:
http://iase.disa.mil/pki-pke/
PKI is the infrastructure, PKE is enabling your computers/servers/applications with PKI auth
This is the PKE admin getting started guide:
http://iase.disa.mil/pki-pke/getting_started/Pages/administrators.aspx
First, many PKI-enabled DOD sites should support hardware tokens issued through commercial CAs that participate in the DOD's ECA program (Verisign, IdenTrust, ORC). These ECA-issued certificates don't even include this "number", the DOD EDI PN.
As I understand it, there is supposed to be some effort made to keep the number stable for a particular person. For example even if I quit my civilian job at the DOD and go to work for a contractor, get married and change my name, quit my job and enlist in the Coast Guard, my DOD EDI PN should be the same. However, in practice, I doubt it works like that.
And even if it did, I probably shouldn't have the same access to an application. Each time my employment changes, the certificate on my CAC should be revoked. If an application is only looking at the common name or subject alternative name of the certificate, it will miss changes in the organization that probably affect the authorization of that subject.
Basing authentication on a particular certificate (issuer and serial number) is a pain for users, but it does make sense from a standpoint of security and robustness.
I have heard the argument for using the number on the end as the unique identifier for individuals because the other information (name, organization, etc) are the bits of information that can realistically change over time as opposed to the number. However, I have not seen an official document or any other piece of authoritative information that actually states this as a fact.
Just curious, is there a document that speaks to the step-by-step process of enabling Apache and DOD CAC? That's what actually brought me to this question in the first place :)
The email address is available in the Subject Alternative Name fieldset. This depends on CAC certificate, but that used for SSL login should contain it (it's also the email signing cert).
The subject would not likely change for a given person very often. The number is indeed the unique number identifying a person. This number would also be present in a UPN field in the Subject Alternative Name for windows login (in a form such as NUMBER#MIL)
You could retrieve the owners SSN from the PIV. That will not change