Could someone correct me 1

[APOC9109]

I am wondering if someone could correct and concepts i have that are incorrect about exchange!


sender Policy framework records are a step further than PTR records because the specify authorized mail servers that accept inbound mail for a domain. This would be the front end server in an FE/BE architecture?


In order for you to enforce other mail servers must have a SPF records is in your sender ID tab in the global message delivery dialog box.

In order for you to enforce mail servers sending mail to you have a PTR record is through the advance button on the SMTP virtual server tab that has a check box specifing to perfom reverse look up and there is nothing else you need to do.

in the smtp virtual server the authenication type is for other mail servers making a connection to our front end server for the purpose of sending email to us. this is Not authenitaction for email clients such as outlook.

An smtp domain is a domain where there is a mail server so would also be the same name as a companies domain.


---https and CA server

You have to request a certificate for you web server before it will allow you to reuqire a SSL connection for OWA or rpc-https?

although you must request a certificate for the web server before you can require a sercure channel (SSL), you can leave the option on the properties tab of the IIS website to not require the client to have a certificate. This would mean the websites access uses https but no certificates for the clients and server are required.





you can use the windows built in CA only if the computers and users accessing you exchange OWA website are from you company and or have had the opportunity to request a certificate from your internal windows ca server becuase they have computers and user account within the companies domain.

If you wish for the general public to access your website(any website) using a certificate your company must employ a third party internet Certificate Server like Verisign.






to use https you must open port 443 on the firewall and forward any https traffic to the private ip address of your front end server.


the fqdn the user types into their browser to use owa is not you private fqdn of your front end server, its the fqdn associated with the mx record followed by /exchange


using prc-https outlook users can also have access to their personal folders (this cannot be correct becuase they are on mapped drive and how would outlook know where their are with a vpn - less connection)


thanks for any corrections!

 

[APOC9109]

I will be super appreciative if someone can give some input

 

[ShackDaddy]

Oh dear... so many questions. I'm going to number them to help keep track. There are 12.

1. Nope. SPF records are records for a domain that list the IPs of servers authorized to SEND mail that uses that domain's sending address. It counters source domain spoofing. An FE server's public IP would be used if mail was sent from that server. But commonly FE servers are used for inbound mail, but not for outbound, so in that case, the SPF record would need to have the BE server's public IP.

2. For SPF to work, you need a hotfix:

http://www.microsoft.com/technet/prodtechnol/exchange/2003/sp2security.mspx

To enable it, you do as you described, and that will cause your server to test each incoming message envelope against published SPF records.

To create SPF records for your own domain, see Daniel Petri's article:

http://www.petri.co.il/sender_policy_framework.htm

3. No. All the "Perform Reverse DNS Lookup" does is do the lookup and add the resolved FQDN to the message header with the IP. It doesn't apply any sort of filtering rules. Exchange 2003 does not support blocking hosts that fail RDNS.

4. This is true.

5. There are exceptions, but that's mainly correct.

6. Yes. These sorts of SSL connections are always encrypted with some sort of certificate. You can either set up a Certicate Authority in your domain and issue a cert that your clients will use, or you can get a 3rd party like GoDaddy to issue you one for pretty cheap.

7. No. Leaving the "Require client to have a cert" just means that you aren't making the client prove their identity. You always should expect to be having to prove the server's identity. There's no HTTPS without it. Anytime you log onto a bank's website, you are using SSL: even though it didn't prompt you about certs, the server showed you that it had one and then encrypted the session using it. It's supposed to be transparent to the user.

8. You don't have to be in the domain to use an internal-CA issued cert. There are several ways that you can provide an external user with an internally issued cert and then allow them to use that cert to access resources. The user still usually has to authenticate to access protected resources, and the whole cert export/import process can be a pain in the neck. RPC-over-HTTP and Exchange ActiveSync are in the difficult camp, OWA is easier with internally issued certs.

9. If you use an internally supplied cert, the public will be prompted with a cert error when they access your site, but will usually be able to access your site. You should always use a 3rd-party trusted authority like GoDaddy or Thawte for public SSL access.

10. Yes.

11. Not quite right. More accurately, users would point to the public FQDN of your FE server like this: publicname.publicdomain.com/exchange. Your MX record may or may not point to your FE server, depending on your setup. MX tells the world where to go with mail on port 25. OWA a web service running on 443. The services could technically be running on separate servers, so keep OWA and MX in different conversations.

12. Users can't access personal folders on mapped drives using RPC-over-HTTP unless they can map the drives from their external computers via VPN.

Hope that helps

ShackDaddy

 

[APOC9109]

super super reposne I will read in more detail!!