I have two Ruby on Rails applications, and two virtual domains (mydomain1.com and mydomain2.com)(using Apache+REE+mod_rails).
I use Postfix as mail server.
So I have myhostname = mail.mydomain1.com in main.cf
And that's because why the sender is always mail.mydomain1.com, no matter from which application I send emails.
I need all emails sent from application on virtual domain mydomain1.com have Received: from mydomain1.com, and from second Rails app on mydomain2.com — Received: from mydomain2.com
Is that possible?
Thanks!
Received: headers are added by the receiving server, which is simply doing a reverse DNS lookup on the connecting (sender) IP address. You won't be able to get the result you desire unless you can force Postfix to make its outgoing connections on a specific IP, and then bind an IP per domain to your server.
I guess there is a way to configure Postifx for using virtual accounts for seperate domains. Using this, you should be able to have both of your apps using different settings.
Maybe this helps:
http://howtoforge.org/virtual-users-and-domains-postfix-courier-mysql-centos5.1
or this
http://www.akadia.com/services/postfix_separate_mailboxes.html
Matt
That's a good question, but I don't believe there is an easy answer.
At one point in the past, the author of postfix stated "postfix makes delivery decisions on the basis of the recipient
address only. There is no logic for sender-dependent routing." That was years ago but it may still be true.
Some people have tried using two separate instances of Postfix. There's an article here that might help, although I have not examined it that closely.
Related
I'm trying to figure out how these all work together, and there are bits and pieces of information all over the internet.
Here's what I (think) I know:
1) When you enter a url into your browser that gets looked up in a domain name server (DNS), and you are sent an IP address.
2) Your computer then follows this IP address to a server somewhere.
3) On the server there are nameservers, which direct you to the specific content you want within the server. -> This step is unclear to me.
4) With this information, your request is received and the server relays site content back to you.
Is this correct? What do I have wrong? I've done a lot of searching over the past week, and the thing I think I'm missing is the big picture explanation of how all these details tie together.
Smaller questions:
a) How does the nameserver know which site I want directions to?
b) How can a site like GoDaddy own urls? Why do I have to pay them yearly fees, and why can't I buy a url outright?
I'm looking for a cohesive explanation of how all this stuff works together. Thanks!
How contents get loaded when I put a URL in a browser ?
Well there some very well docs available on this topic each step has its own logic and algorithms attached with it, here I am giving you a walk through.
Step 1: DNS Lookup : Domain name get converted into IP address, in this process domain name from the URL is used to find IP address of the associated server machine by looking up records on multiple servers called name servers.
Step 2: Service Request : Once the IP address is known, as service request depending on protocol is created in form of packets and sent to the server machine using IP address. In case of a browser normally it will be a HTTP request; in other cases it can be something else.
Step 3: Request handling: Depending on the service request and underlying protocol, request is handled by a software program which lives normally on the server machine whose address was discovered in previous step. As per the logic programmed on the server program it will return a appropriate response in case of HTTP its called HTTP Response.
Step 4: Response handling: In this step the requesting program in your case a browser receives the response as mentioned in the previous step and renders it and display it as per defined in the protocol, in case of HTTP a HTTP body is extracted and rendered, which is written in HTML.
How does the nameserver know which site I want directions to
URL has a very well defined format, using which a browser find out a hostname/domain name which is used in turn to find out the associated IP address; there are different algorithms that name-servers runs to find out the correct server machine IP.
Find more about DNS resolution here.
How can a site like GoDaddy own urls? Why do I have to pay them yearly fees, and why can't I buy a url outright?
Domain name are resources which needed management and regulation which is done ICANN they have something called registries from which registrar(like GoDaddy) get domains and book them for you; the cost you pay is split up between ICANN and registrar.
Registrar does a lot of work for you, eg setup name server provide hosting etc.
Technically you can create you own domain name but it won't be free off course because you will need to create a name server, need to replicate it other servers and that way you can have whatever name you want (has too be unique); a simple way to do that is by editing your local hosts files in linux it is located at /etc/hosts and in windows it is located at C:\Windows\System32\drivers\etc\hosts but its no good on internet, since it won't be accepted by other servers.
(Precise and detailed description of this process would probably take too much space and time to write, I am sure you can google it somewhere). So, although very simplified, you have pretty good picture of what is going on, but some clarifications are needed (again, I will be somewhat imprecise) :
Step 2: Your computer does follow the IP address received in step 1, but the request set to that IP address usually contains one important piece of information called 'Host header', that is the actual name as you typed in your browser.
Step 3: There is no nameserver involved here, the software(/hardware) is usually called 'webserver' (for example Apache, IIS, nginx etc...). One webserver can serve one or many different sites. In case there are more than one, webserver will use the 'Host header' to direct you to the specific content you want.
ICAAN 'owns' the domain names, and the registration process involves technical and administrative effort, so you pay registrars to handle that.
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).
When I visit my Rails 2.2 app on my remote server I receive the following value as my REMOTE_ADDR.
request.env['REMOTE_ADDR']: "75.184.124.93, 10.194.95.79"
What has me stumped is why there are two IPs. A quick check of my currently leased public IP confirms that my IP is 75.184.124.93.
So where is 10.194.95.79 coming from?
Is there something about how remote addresses are collected and reported in the HTTP headers spec that I'm missing? Is this expected, normal behavior?
It's definitely because of a reverse proxy.
Reverse proxies (I use BigIPs and Apache mod_proxy mode often) usually append all the intervening IPs to the list so you can pick out the right ones in your code.
For example, you might want to find the public one to log to your webstats application, so there it is right in the REMOTE_ADDR. But you also have the internal IP(s) so you know which loadbalancer it came from, which internal server its on for some kind of internal network tracking, etc
Is there a way to determine POP or IMAP server given the email address? I am building an application for non-technical users and I dont really want to bother them with asking their IMAP/POP servers. mail2web.com does this, but I am not sure how.
This is how Thunderbird does it
/**
18 * Try to guess the config, by:
19 * - guessing hostnames (pop3.<domain>, pop.<domain>, imap.<domain>,
20 * mail.<domain> etc.)
21 * - probing known ports (for IMAP, POP3 etc., with SSL, STARTTLS etc.)
22 * - opening a connection via the right protocol and checking the
23 * protocol-specific CAPABILITIES like that the server returns.
24 */
http://mxr.mozilla.org/comm-central/source/mailnews/base/prefs/content/accountcreation/guessConfig.js
Thunderbird 3 does it too.. I'd take a look at the source code.
I think it's just a lookup table though..
There is nothing in a standard that dictates a POP/IMAP server for a given domain. Only convention or, as Joril suggests, lookup tables can be used. SMTP servers are different as there is a functional requirement to send the mail onto the next stop. Pick up (via POP/IMAP) is an entirely local domain admin issue. Sorry.
I guess you could take the domain and build a server name such that fred#mymail.com becomes pop.mymail.com and imap.mymail.com. Or perhaps take it further and interrogate the MX records and perform similar substitutions. Then you could run through your list of candidate servers looking for a POP/IMAP response. Might be a bit dodgy on the security front though.
Cheers,
Dan
There's absolutely no way to do this correctly in general.
However, you can use tables of common mail providers to fill in defaults, and you could fill in smtp.example.com etc... but that will still fail in some simple cases, though, like my work system where everything is on mail.wherever.com on unusual port numbers. So in the end, the user must be able to override whatever you do.
If you really want it to be general, you're going to have to deal with certificates and EAP as well.
Thunderbird does a good job. It's method is described here https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration. Below is a excerpt of the documentation.
All the lookup mechanisms use the email address domain as base for the lookup. For example, for the email address fred#example.com , the lookup is performed as (in this order):
tb-install-dir/isp/example.com.xml on the harddisk
check for autoconfig.example.com
look up of "example.com" in the ISPDB
look up "MX example.com" in DNS, and for mx1.mail.hoster.com, look up "hoster.com" in the ISPDB
try to guess (imap.example.com, smtp.example.com etc.)
We may in the future add DNS SRV records as supported mechanism in the future, but we currently do not.
I have google apps for receiving email. I get inquiries from people on info#[my-domain.com], which email is hosted on google.
Sometimes, I want my rails set-up to send emails from my own server, and that works fine. But when I want to send to an email address on my own domain, such as info#my-domain.com, postfix sees the my-domain.com and tries to deliver locally.
I understand that's normal, but I'd like to have those emails go to google apps rather than try to be delivered locally.
I know there's a postfix config file for aliases, but here, the email addresses are the same, just need to tell postfix not to try to deliver locally.
Any way to do this?
It sounds like you have two mail servers set up to act as the primary destination for email to your domain: Google Apps and your postfix server. You can't do that because, as you've found, mail sometimes gets delivered to one server and sometimes the other.
Presumably you want Google Apps to be the primary destination. That is, mail for your domain should go to the Google servers, not yours. You will need to re-configure postfix so that it is not the mail server for your domain.
Edit the /etc/postfix/main.cf file and look for the mydestination line. Remove your domain from that line.
I don't normally use postfix, but I think if the line looks like this, you'll be good:
mydestination = $myhostname localhost.$mydomain localhost
Let's say your server name is "test1" and your domain is "example.com." The following addresses would be delivered locally:
info#test1
info#localhost.example.com
info#localhost
But mail to info#example.com would go to Google Apps because postfix is not configured to accept mail for simply "example.com."
I get around it by doing this http://souptonuts.sourceforge.net/postfix_tutorial.html. Basically have that mail sent through one of your google domain accounts instead of locally.
Either, as Barry Brown suggested, tell postfix that my-domain.com is not local by removing it from $mydestination on the postfix box, or if that's not practical, use virtual aliases in Postfix to rewrite that specific address (info#my-domain.com) to the google-hosted address you want to deliver it to.
Virtual aliases in Postfix are not just for the virtual alias address class; they are a general-purpose pre-queue address rewriting mechanism. Sendmail-style aliases (depending on your distribution, either /etc/aliases or /etc/postfix/aliases) are used by the local delivery agent and only apply to the local address class. You could, of course, use sendmail-style aliases to forward mail for "info" to some-address#your-google-hosted-domain.
The documentation at postfix.org is pretty good. Try
http://www.postfix.org/STANDARD_CONFIGURATION_README.html
http://www.postfix.org/ADDRESS_CLASS_README.html
http://www.postfix.org/ADDRESS_REWRITING_README.html
http://www.postfix.org/VIRTUAL_README.html