Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Let's say my users have accounts on some mail server mail.example.com. I currently have my mx record set to mail.example.com and all is good. Now let's say I want to have mails initially delivered to an external service (e.g. Postini. Note that this is not a postini-specific question though).

In the normal situation where my mx is set directly to my mail server mail.example.com, sending MTAs will of course look up my MX and send to mail.example.com. In my new situation I'd have my mx set to mx.othermailservice.com and emails would be received there. OtherEmailService.com will then relay the emails (while keeping the return-path header the same) to mail.example.com. Do the emails that are received at mail.example.com after be relayed from the other service "look" any different than emails that go directly to it as would be the case where the mx was set to mail.example.com?

share|improve this question

2 Answers 2

It depends on how you define "look". If you are talking about if they look any different from a client perspective, like outlook, the answer is no, they look the same.

The main thing you will notice is that the headers are different in these emails, obviously they are flowing through a new system and you may also see new spam headers. In some cases mails may look different as they may add a tag at the bottom saying "scanned by service name here".

So it depends on the service, but specifically with postini the end user will not notice the change.

share|improve this answer
    
good point, the headers will show traces of the intermediate system. Based on this, do you think it's theoretically possible that the ultimate email server could reject these mails? I think not, since I can't see a distinction between a normal email being relayed through some mailer somewhere (e.g. if the sender is gmail it'll go through google's mta) vs. an email relayed through the intermediate server in my case. In other words the ultimate destination mta can't distinguish one external mta vs. another. But this is what I wanted to verify... Thanks so much –  Matt Feb 19 '11 at 22:17
    
it depends on your configuration. If the final mailhop is configured to always allow the relay then it wont be rejected. If you mean your outbound mail being rejected because you are using a relay, then just send your outbound mail through it too. In this scenario "the internet" sees your inbound and outbound mail from 1 source. –  pablo Feb 20 '11 at 0:28

There are two key differences such routed mails have over directly received mails:

  1. The IP address of the incoming mailer connection will not match the mailer information of the domain listed on the MAIL FROM: line in the SMTP conversation.
  2. The mail itself will have an additional Received-By: header in it from the relaying mailer.

The first point is critical when it comes to anti-spam, since a lot of AS technologies focus around discarding email not coming from where it should (see also, SPF) or coming from IP addresses that are funny looking (IP reputation). If you are receiving relayed, your AS systems must not consider IP address as part of their checking.

It works like this:

  1. The internet-facing mailer at example.client sends a message to example.yourcorp via the MX record.
  2. The server listed in your MX record, which is off of your network, receives the connection from mailer.example.client. It looks like it comes from example.client, doesn't smell overly processed, and forwards it on to mailer.example.yourcorp.
  3. Your mailer.example.yourcorp receives an incoming message from example.client, but sent from example.antispam instead.

If this were the Internet circa 1992, that wouldn't be a problem. It was a more trusting time back then, and in that case mailer.example.yourcorp would merrily accept the message and no one would be the wiser.

Spam throws the monkey-wrench in here. At this point, an anti-spam service running directly on mailer.example.yourcorp could throw a fit. Since example.client's SPF record (for example) doesn't state that example.antispam is an authorized mailer, it could drop the message on the floor never to be seen from again.

Anti-spam services work best when they're running on the mailer that directly receives mail from the general internet. This is in large part due to the fact that IP reputation services have been one of the best anti-spam technologies, and to utilize it you need to see those TCP connections. Hide behind a mail relay, and you lose that advantage.

The second point is a by-protocol addition to the mail headers required by the SMTP standards. The client should never notice.

share|improve this answer
    
Can you please explain #1 in more detail, maybe a specific example? I'm kind of getting it but not sure... –  Matt Feb 19 '11 at 22:32
    
@Matt I added more detail. –  sysadmin1138 Feb 19 '11 at 22:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.