jj4375
asked on
SMTP outbound IP address reference on multihomed, multi-NIC card machine
No matter what we do we cannot get our virtual SMTP servers in IIS to not reference the IP used by the primary SMTP instance. Even if the other IP is on a physically seperate NIC card. Even if the other IP is in a different subnet. When the email comes through, it has BOTH IP's on it!!?
I see that through socket-programming I can FORCE a bind to a specific IP. However, is there ANY way to do this in IIS SMTP server alone so I can have NO references to my primary IP address when the mail is sent? If socket programming can allow it to happen why can't IIS?
Thanks!
I see that through socket-programming I can FORCE a bind to a specific IP. However, is there ANY way to do this in IIS SMTP server alone so I can have NO references to my primary IP address when the mail is sent? If socket programming can allow it to happen why can't IIS?
Thanks!
ASKER
Sorry--didn't clarify. Headers at recipient end, and yes, we already bound the specific IP we wanted. So, no dice on your suggestion, thanks though!
can you show us the headers? who is adding those headers source or destination?
cheers.
cheers.
ASKER
Here is a sample header. See the <-- notes on the lines where there is something noteworthy.
Received: from mail1.themailbox.com ([212.155.114.4]) <--- NOTE: THIS IS THE WRONG IP WITH THE RIGHT DOMAIN
by realemail.com (EMAIL SRVU) with ESMTP id GKA37866
for <jon@realemail.com>; Wed, 13 Oct 2004 20:32:31 -0500
Received: from mail1.themailbox.com ([62.2.4.7]) by mail1.themailbox.com with Microsoft SMTPSVC(5.0.2195.6713); <-- THIS IS THE RIGHT IP WITH THE RIGHT DOMAIN
Wed, 13 Oct 2004 21:42:52 -0400
from: jon@test.com
to: jon@realemail.com
subject: test subject
Return-Path: jon@test.com
Message-ID: <MAIL1wFutJLtosJ3Ih0090000 7@mail1.th emailbox.c om>
X-OriginalArrivalTime: 14 Oct 2004 01:42:53.0254 (UTC) FILETIME=[1F0C0E60:01C4B18 F]
Date: 13 Oct 2004 21:42:53 -0400
Received: from mail1.themailbox.com ([212.155.114.4]) <--- NOTE: THIS IS THE WRONG IP WITH THE RIGHT DOMAIN
by realemail.com (EMAIL SRVU) with ESMTP id GKA37866
for <jon@realemail.com>; Wed, 13 Oct 2004 20:32:31 -0500
Received: from mail1.themailbox.com ([62.2.4.7]) by mail1.themailbox.com with Microsoft SMTPSVC(5.0.2195.6713); <-- THIS IS THE RIGHT IP WITH THE RIGHT DOMAIN
Wed, 13 Oct 2004 21:42:52 -0400
from: jon@test.com
to: jon@realemail.com
subject: test subject
Return-Path: jon@test.com
Message-ID: <MAIL1wFutJLtosJ3Ih0090000
X-OriginalArrivalTime: 14 Oct 2004 01:42:53.0254 (UTC) FILETIME=[1F0C0E60:01C4B18
Date: 13 Oct 2004 21:42:53 -0400
OK, just to make sure I understand correctly:
mail1.themailbox.com has the ip address 212.155.114.4 configured, but also some other address that you want to see it identified as?
what is the ip address of the one you *do* want to see, and what are the subnet masks for each?
for example, 212.155.114.4/255.255.255. 0 and (say) 212.155.114.5/255.255.255. 0?
the reason i suggest that you consider this is because it is possible that if the /other/ address is on a different subnet, then possibly the server is set up to use a default gateway that is on the subnet that the address shown is on.?
Cheers, Mike.
mail1.themailbox.com has the ip address 212.155.114.4 configured, but also some other address that you want to see it identified as?
what is the ip address of the one you *do* want to see, and what are the subnet masks for each?
for example, 212.155.114.4/255.255.255.
the reason i suggest that you consider this is because it is possible that if the /other/ address is on a different subnet, then possibly the server is set up to use a default gateway that is on the subnet that the address shown is on.?
Cheers, Mike.
ASKER
If you look at the header, here is what I outline:
mail1.themailbox.com ([212.155.114.4]) <--- NOTE: THIS IS THE WRONG IP WITH THE RIGHT DOMAIN
mail1.themailbox.com ([62.2.4.7]) <-- THIS IS THE RIGHT IP WITH THE RIGHT DOMAIN
You have a valid point regarding the gateway. Let me explain further though.
Whatever the machine has for the primary IP and gateway dictates what is "stamped" at the top (hence, the wrong IP as I mentioned above). Here's where it gets difficult: this occurs even though the CORRECT IP, that is, 62.2.4.7 is bound to a completely different NIC card with the CORRECT gateway for that IP address. It doesn't matter. The primary IP + gateway still get associated. To clarify, this particular virtual SMTP server ONLY has 62.2.4.7 as its IP.
Now, as I mentioned, if I create a VB.NET socket-level program to communicate directly with the remote SMTP server and I BIND the 62.2.4.7 IP address to my socket program, THEN the email arrives with NO mention of the WRONG IP address, that is, 212.155.114.4. But I am trying to avoid writing my own SMTP server. It seems my socket programming can attain a "lower-level" on the machine than SMTP can.
In short, even with a seperate NIC card per IP subnet range, it still seems to stamp the INCORRECT IP (212.155.115.4) at the top of the email no matter what I do. Keep in mind I HAVE to run multiple SMTP instances on the one machine. We cannot just have one SMTP on the machine, otherwise, this wouldn't be an issue... I could just do what you suggested and get the problem to go away. The true rub of the situation comes from the fact that we have additional virtual SMTP servers in IIS beyond the primary, and have little to no alternative for this... we can't afford to buy a seperate server per SMTP IP.
It seems like Microsoft should have some mechanism to force each virtual SMTP server to bind exclusively to the IP address that the SMTP server was created with. My VB.NET programming shows that it is entirely possible... I had hoped it was maybe just a routing setting for IIS SMTP that I was unaware of, etc. Nevertheless, as long as it allows the other IP to slip through, we look like we are spoofing and when it confuses remote mailservers, we get rated more highly as SPAM... a bad thing.
Thoughts now?
mail1.themailbox.com ([212.155.114.4]) <--- NOTE: THIS IS THE WRONG IP WITH THE RIGHT DOMAIN
mail1.themailbox.com ([62.2.4.7]) <-- THIS IS THE RIGHT IP WITH THE RIGHT DOMAIN
You have a valid point regarding the gateway. Let me explain further though.
Whatever the machine has for the primary IP and gateway dictates what is "stamped" at the top (hence, the wrong IP as I mentioned above). Here's where it gets difficult: this occurs even though the CORRECT IP, that is, 62.2.4.7 is bound to a completely different NIC card with the CORRECT gateway for that IP address. It doesn't matter. The primary IP + gateway still get associated. To clarify, this particular virtual SMTP server ONLY has 62.2.4.7 as its IP.
Now, as I mentioned, if I create a VB.NET socket-level program to communicate directly with the remote SMTP server and I BIND the 62.2.4.7 IP address to my socket program, THEN the email arrives with NO mention of the WRONG IP address, that is, 212.155.114.4. But I am trying to avoid writing my own SMTP server. It seems my socket programming can attain a "lower-level" on the machine than SMTP can.
In short, even with a seperate NIC card per IP subnet range, it still seems to stamp the INCORRECT IP (212.155.115.4) at the top of the email no matter what I do. Keep in mind I HAVE to run multiple SMTP instances on the one machine. We cannot just have one SMTP on the machine, otherwise, this wouldn't be an issue... I could just do what you suggested and get the problem to go away. The true rub of the situation comes from the fact that we have additional virtual SMTP servers in IIS beyond the primary, and have little to no alternative for this... we can't afford to buy a seperate server per SMTP IP.
It seems like Microsoft should have some mechanism to force each virtual SMTP server to bind exclusively to the IP address that the SMTP server was created with. My VB.NET programming shows that it is entirely possible... I had hoped it was maybe just a routing setting for IIS SMTP that I was unaware of, etc. Nevertheless, as long as it allows the other IP to slip through, we look like we are spoofing and when it confuses remote mailservers, we get rated more highly as SPAM... a bad thing.
Thoughts now?
ASKER
As a final point, to be sure, in my example, the DNS configuration for mail1.themailbox.com ONLY points to: 62.2.4.7
It has absolutely no ties to: 212.155.114.4... as I mentioned that is the WRONG IP address being pulled in by IIS's SMTP.
It has absolutely no ties to: 212.155.114.4... as I mentioned that is the WRONG IP address being pulled in by IIS's SMTP.
ASKER
A potential lead, using SMTP/CDO "Sinks":
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cdosys/html/_cdosys_event_components.asp
If anyone has insight into how to use these to control/bind the outbound SMTP connection to a set IP address (or at least force the header to seem like that), let me know.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cdosys/html/_cdosys_event_components.asp
If anyone has insight into how to use these to control/bind the outbound SMTP connection to a set IP address (or at least force the header to seem like that), let me know.
OK,
yes, I think i understand your issue now.
it certainly appears that IIS smtp server blindly uses the primary IP address for the source socket when sending mail out. apparently MS have not bothered to pay attention to the potential issues that may cause.
I don't think that anything you do with CDO will make any difference because the CDO only passes the message to the local smtp server instance which then deals with the message in the best manner it knows how.
Having said that, I still don't quite understand how your network is set up because the addresses you show are not likley to be on the same subnet:
212.155.114.4 - 62.2.4.7 ? do you have more than one gateway on this network?
If I can understand that a bit better, i can post a msg on MS private (MVP) newsgroup to see if someone on the product team can shed any light.
Regards, Mike.
yes, I think i understand your issue now.
it certainly appears that IIS smtp server blindly uses the primary IP address for the source socket when sending mail out. apparently MS have not bothered to pay attention to the potential issues that may cause.
I don't think that anything you do with CDO will make any difference because the CDO only passes the message to the local smtp server instance which then deals with the message in the best manner it knows how.
Having said that, I still don't quite understand how your network is set up because the addresses you show are not likley to be on the same subnet:
212.155.114.4 - 62.2.4.7 ? do you have more than one gateway on this network?
If I can understand that a bit better, i can post a msg on MS private (MVP) newsgroup to see if someone on the product team can shed any light.
Regards, Mike.
ASKER
Yes, in this case we have multiple gateways (one for each subnet). This problems seems to rear its head whether we are using the same NIC card (OK, this is not ideal, if we did this one IP gets the wrong gateway) but also with multiple NIC cards (1 gateway per IP subnet which should be fine)... essentially, the problem occurs regardless of what we have for NIC cards and gateways... it binds to the primary NIC card's primary IP address.
ASKER
PS-Thanks for researching on MVP, it would be a big help!
OK,
I'll post a q and see if we get any response.
Cheers.
I'll post a q and see if we get any response.
Cheers.
ASKER
Final update for you...
Just tested:
Even if I have 2 IP's in the SAME subnet, on the same NIC card with the matching gateway for that subnet, it still happens.
For instance, supposing my network card looks like this:
Primary IP: 211.1.1.2
Gateway: 211.1.1.1
Subnet mask: 255.255.255.240
And then I add an additional IP to that NIC card as follows:
Secondary IP: 211.1.1.3
Subnet mask: 255.255.255.240
And if I have a seperate SMTP server/virtual server set up with a valid DNS record and MX record for each IP address: when I send email to the SMTP server for 211.1.1.3, the resulting header I get still has the erroneous stamp at the top for 211.1.1.2 as with my previous example where I actually showed you the header!
The only point here is that this has nothing to do with subnets being different... it still happens even when they are the same. Thanks for all your help.
Just tested:
Even if I have 2 IP's in the SAME subnet, on the same NIC card with the matching gateway for that subnet, it still happens.
For instance, supposing my network card looks like this:
Primary IP: 211.1.1.2
Gateway: 211.1.1.1
Subnet mask: 255.255.255.240
And then I add an additional IP to that NIC card as follows:
Secondary IP: 211.1.1.3
Subnet mask: 255.255.255.240
And if I have a seperate SMTP server/virtual server set up with a valid DNS record and MX record for each IP address: when I send email to the SMTP server for 211.1.1.3, the resulting header I get still has the erroneous stamp at the top for 211.1.1.2 as with my previous example where I actually showed you the header!
The only point here is that this has nothing to do with subnets being different... it still happens even when they are the same. Thanks for all your help.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Well I added the DisableSocketPooling as the article suggested. Even with an IP in the same subnet, and even testing both the same & a different NIC card, it still stamps the header with the wrong IP. It cannot be done I guess, and I will award you the points for helping me arrive at this conclusion.
I plan to write my own basic SMTP server to combat this problem. Email me if you are intereted, it will take around 3-6 mos to produce, and will be designed as a basic way to correct this issue.
I plan to write my own basic SMTP server to combat this problem. Email me if you are intereted, it will take around 3-6 mos to produce, and will be designed as a basic way to correct this issue.
Are the headers inserted by smtp server or the recipient end?
Normally you would just set the default smtp server to bind to the specified address in properties instead of 'all unassigned'
Cheers.