SMTP seems to have duplicate security settings? - security

I'm new to setting up smtp, and I'm trying to figure out how to secure my server, but I'm getting a little turned around with all the security options - hopefully someone can help me clear this up. I'm using Windows 2008 R2 sp1 with IIS 7.5 if that makes any difference.
So what I'm seeing is, in the properties of the smtp virtual server I have an Access tab with an Authentication button. Seems to make sense, I pick Integrated Windows User, but then on the Delivery tab, I see an Outbound Security button which presents the same set of options again. I select Integrated Windows User.
Then, following the instructions I found online to setup smtp, I created a new domain under the smtp virtual server which then gave me ANOTHER Outbound Security tab with the same set of options. What are all these settings for? I've scoured google and couldn't find anything differentiating the 3 (maybe more?). I've found various sites that will tell me what one does or another, but they all seem to be doing the same thing and no site addresses that. Does one override another? Like a default for the server, but then specific ones for the domains or something like that? What's the difference between the Authentication and Outbound Security? What's the difference between the Outbound Security for the domain and for the main smtp server?
Oh, and one more question while we're semi on the topic - is the setup for domains mainly used for remote access? Like, it would be unnecessary for localhost use?

You have two sets of authentications: inbound and outbound.
The Access tab lets you limit who and from where are allowed to access your SMTP server (i.e inbound), while the Outbound Security in turn lets you provide credentials that the SMTP service will use when delivering mails to another SMTP server (e.g. if relaying all outgoing emails to a smarthost that requires authentication).
You can furthermore set up remote domains, i.e. have emails for a specific domain be delivered to a specific server using specific credentials.
It is highly recommended to have all your outgoing emails forwarded to a smarthost that acts as an official email server for your sending domain, otherwise you risk your emails being classified as spam because they are sent from an unknown server.

Related

Sendgrid Integration / DNS Setup

I am having some difficulty setting up my SendGrid account to connect to my DNS on Cloudflare and enable custom domain whitelisting for two domains.
My plan is to deploy emails from my Clickfunnels' Actionetics account. Currently, my integration into Clickfunnels is a success and I was able to receive an automated test e-mail (from my custom domain) to my personal email address. I understand that I should be able to send emails from any e-mail address I need (support#domain.com, hamid#domain.com, info#domain.com) without needing to physically needing to go through any setup process to get these emails up and running. Initially when I went through the SendGrid setup, I needed to add 3 CNAMES to my Cloudflare DNS. Everything successfully installed without any issues from Cloudflare. After speaking with Support, I was told that I might need to retry the whitelabel wizard with automatic security off. Going through this wizard should give 2 txt's and one MX (mail exchanger) record instead of 3 CNAMES.
"Automating security allows the system to redirect ISPs to SendGrid to check DNS records that follow strict security protocols and are custom to your account. Due to a character limit on TXT records, we are only able to create a custom SPF (sender policy framework) record for users with up to 11 IP addresses. This will not affect deliverability. You would have to go through the whitelabel process again."
If you have experience in this type of issue, please let me know what you think.
This is one method the I recommended.
“white-label the domains again but this time completing it with automatic security turned off. Going through this wizard should give 2 txt's and one MX record instead of 3 CNAMES.”
"Automating security allows the system to redirect ISPs to SendGrid to check DNS records that follow strict security protocols and are custom to your account.
Due to a character limit on TXT records, we are only able to create a custom SPF record for users with up to 11 IP addresses. This will not affect deliverability. You would have to go through the white-label process again."
Thanks, I hope you can resolve this.
I can't understand your question.
SPF is kind of TXT record, it can help receiver know email comes from right ip address.
Whitelabeled Domains help receiver know email really comes from the right server.
Sendgrid need a subdomain and two well-know subdomain to verify your identity.

Docusign connect service not posting data to specified url

Docusign connect service is not posting data to the url specified in the connect service option. Actually if i resend the data from log it works but it do not works on its own.
Please help me
Thanks
Usually when DocuSign Connect is not publishing to a URL it is caused by one of a few things:
Your server is not listening on the correct port(s).
You are not testing for the correct events.
You do not have the user (sender) configured for Connect.
Your server is not publicly accessible.
Your firewall or network security is not letting the requests going through.
Your server has crashed.
A potential bug with DocuSign Connect.
Possible resolutions:
If testing in DocuSign demo environment (demo.docusign.net) ports 80 (http) and 443 (https) are allowed. If testing in production environment (www.docusign.net) only 443 - https is allowed.
Make sure you are testing for the correct event triggers - this can be confirmed on your Connect settings page. Login to the Console and go to Preferences -> Connect -> (select one of your Connect configurations). On the following page you'll see how to select events that you want Connect to push on, as well as for which users.
Followup answer to 2 - you need to also make sure you have the correct account members enabled for Connect on the Console -> Preferences -> Connect page.
You can not use a localhost address for the Connect URL - it must be a publicly accessible URL.
Your network administrator might have a firewall (physical or virtual) or other security software setup that is stopping the requests from going through. Check your security settings and test that the proper ports are enabled, etc.
Ensure that your server is still up and running and that it hasn't crashed.
Although DocuSign Connect has been around for some time it still occasionally exhibits a bug or two. If not one of the other potential reasons then provide the failure log in your post and someone from DocuSign will follow up.
If you are running into issues with DocuSign Connect hopefully one of the above remedies resolve your issue.

Default logon-Domain for Sharepoint

When running Sharepoint (WSS 3.0) with Windows Authentication (NTLM), external users must supply their usernames in the form of DOMAIN\username. This makes sense, because you could have multiple domains, trusts between them, etc. However in my case, I only have one domain, and I want my users to be able to logon with their pure username only. Is there any way to configure Sharepoint with a default logon-Domain to get this to work?
Changing the authentication to basic or forms is not an option for me.
That's a windows/IIS issue rather than something specific to sharepoint.
You can find a more detailed explanation at http://forums.iis.net/t/1151401.aspx but basically it's impossible due to the the design of integrated authentication - the client has to know the domain before the server is contacted.
The closest you get to a default domain is local logins on the server - potentially a solution if users are truly external.
Realize that some browsers can be configured to automatically provide NTLM credentials. For example, IE can do this. I believe by default it will for sites in the Local Intranet and maybe even for Trusted sites (if not, you can change it so it will).
There is software out there for pushing these settings (policies) out to users if their computer is a part of your domain.

Setting up Alerts in SharePoint

I am running MOSS 2007 on a Windows 2003 box. I need to know what configuration must be done to get Alerts to work. SMTP settings, etc.... When I create my alert, it is created but it does not send the email to show me that something changed in my document library or on any particular document. What am I missing?
I did install the Email Services under Windows Components and the SMTP under IIS.
In my SharePoint Central Admin, I did change my settings for outgoing and incoming email (Under the Topology and Services section).
What else am I missing?
Did you setup the Web Application Outgoing E-mail Settings in your Central Administration? Y
Has the SMTP server been configured to allow the MOSS server to relay mail to it?
Ensure that you have configured the SMTP server properly by configuring an account and associating to a mail client Outlook. Check the Servers outgoing and incoming capabilites from the mail client first.
Ensure that you have subscribed to the alerts properly in a list
I don't think this question is really appropriate for StackOverflow - its not a programming question, see the FAQ.
But anyway - could be anti-virus or smtp relay rules stopping sharepoint sending smtp to your mail server. Try this tool to diagnose.
http://www.simplecomtools.com/smtptesttool.html
If that doesn't work then its MS support - the newsgroups are littered with the carcasses of people trying to resolve alert email problems!

Can I configure SMTP in IIS, so it relays to a remote SMTP server?

I want to configure SMTP on my web server, so that any email sent through the SMTP server is relayed to a remote SMTP Server. The IIS SMTP server would have to use SMTP authentication, and use the host name, username and password (as if configuring a normal email client).
Does anybody know if this is possible?
Yes, it' completely possible, and relatively easy to configure.
I've got a couple of articles about SmartHosting on my web site that will probably help:
http://www.christopherlewis.com/SmartHosting/SMTPSmartHosting.htm
and
http://www.christopherlewis.com/SmartHosting/SMTPSmartHostingPt2.htm
They're written towards Exchange 2003, but Exchange 2003 used IIS's SMTP engine, so the settings are the same.
Bascially, you right click the SMTP site, select properties, Delivery tab, Outbound security, and enter your credientials in the Basic Authentication fields. Back on the Delivery tab, you then click Advanced and enter the remote SMTP server name in the SmartHost field.
Editing
The links above are no longer available.
Try http://intellitect.com/configuring-windows-smtp-server-on-windows-2008-for-relay/.
HTH and answers your needs
http://www.cmsconnect.com/praetor/webhelpg2/Chapter_2_-_Pre-installation_considerations/Configuring_the_SMTP_Server.htm
I think you can only set outbound relays for specific domains, not blanket coverage.
http://www.isaserver.org/articles/smtprelayinboundoutbound.html
EDIT:
I've not done this before, buy maybe worth a try:
From the Server properties, you could try selelcting the 'Delivery' Tab, then advanced. In the Smart Host, type the outgoing SMTP relay IP / domain. Select OK, and then select 'Outboud Security' and enter your username / password in the basic authentication box.

Resources