rerouting thirdparty email through our ironport

Unanswered Question
Oct 1st, 2009

Hello,

I had something out of the ordinary come up and was wondering if the IronPort would be able to handle something like this.

Receive messages from partner smtp server destined to public email domains. However, we want the sender (from: ) to be an address with our domain name. Of course if they were to send the message from their smtp server out directly the customer with our domain name, the security on their end should pick it up as a spoofed sender address because the domain name doesn't match the sending email server via dns and mx lookups.

Is there way I can instruct the partner to send directly to my ironport and I setup a content filter/listener or something that will grab the message from their specific IP.

My ironport would then ignore any RAT inspection but send the message out it's external interface to the recipient as if were coming from my environment?

Thanks in advance, kind of a time sensitive issue.

Chris

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
SPAMHater_ironport Thu, 10/01/2009 - 16:13

Sometimes I tend to read to quickly and miss the point!! But it sounds to me like you want them to relay off your IronPort.

chmeehan0421 Thu, 10/01/2009 - 16:15

Yes, but I need to make sure the recipients email security doesn't reject it because of non matching IP to email domain name during reverse lookups.

SPAMHater_ironport Thu, 10/01/2009 - 21:23

Do you know what types of checks the recipients mails servers will be performing? There are quite a few checks that can be done, I have not seen anything standard out there. I think the most common ones would be a reverse and forward look up from the connecting box (A) (PTR). As long as the box where mail is being relayed from is configured properly in DNS you should not have a problem. Unless you deal with some quirky recipient mail servers that want the sender domain to match the domain of the sending server and perform MX record look up on the sending domain to match with the box etc :? crazy stuff, I know at one point some people tried to implement that but did not go so well. Only thing I can tell you is TEST TEST TEST. You might want to look into SPF records, that might help in what you are trying to do.

tcamp_ironport Sat, 10/03/2009 - 22:22

Hi Chris,
if I understand you correctly, allowing this partner to send messages out through your system is simply a matter of

  • create a new Relay mail flow policy with the appropriate settings & acceptance levels on the Public Listener
  • create a new Sendergroup which uses the new Policy, add the partner's connecting IP address
  • you may want to enable spam scanning outbound and investigate any hits that occur

Your partner company should format the messages to say that they are coming From (all envelope addresses as well as mail-from) your domain, and for the return address you could create a mail policy + content filter to rewrite the recipient to where they want bounces/replies to go.

As mentioned in a previous post, test thoroughly to ensure no problems with any SPF, DKIM, or replies going to the appropriate location.

Donald Nash Wed, 10/14/2009 - 21:58

If your partner company is for some reason unable to masquerade themselves as you in the mail they send, then you can also configure your IronPort to do the masquerading for them. You can do this either statically or via LDAP lookups. The feature you want to use is (unsurprisingly) called "masquerading", and it's all documented in the Advanced User Guide.

chmeehan0421 Tue, 10/20/2009 - 18:46

Thanks for the replies. I was able to relay the mail from the vendor by creating a new mail policy and adding the sending IP to a new sender group.

I then tried to require authentication in the mail flow policy but the relay was still allowed to go through? Would this be because the default policy parameters are set to smtp authentication (off)?

Thanks.

Chris

Donald Nash Tue, 10/20/2009 - 19:59

If the sender group already has a RELAY policy, then SMTP authentication is meaningless because relaying is allowed regardless. You'd need to assign them to a sender group with an ACCEPT policy, which doesn't allow relaying by default. A successful authentication effectively upgrades the policy to RELAY.

Actions

This Discussion