Im trying to send an html email with attachment to list of users. Our client also requires the track of undelivered email ids, so we thought of using sp_send_dbmail feature available in SQL server, which has logs for email sent using it. Our client also mandate to DKIM sign the emails. Im not able to find how to DKIM sign the emails sent through sp_send_dbmail.
Please help!..
Normally DKIM signing is a SMTP server business, not SQL. You want to talk to postmaster. There are several steps involved in enabling DKIM signing outgoing email:
Generation of RSA crypto key pair
Publication of public key in DNS (so receiving server is able to verify the signature)
Setting up signing service
Modifying your SMTP server configuration to use this signing service for all or specific outgoing emails
There are third party controls that enable signing from within SQL, but not using sp_send_dbmail. See here for example: http://www.example-code.com/sql/dkim_sendDkimSigned.asp
However they don't eliminate the 1 and 2 above.
Related
Assume you have a Gmail account and want to send an E-mail to an account on yahoo mail server from Gmail account, here are the steps:
Client mail manager (say outlook) connects to gmail server and authenticates your account(using username/password that you have already)
after the authentication is done, your mail is sent to gmail server
so here is the question: how gmail proves itself to yahoo? has
gmail any username/password or some sort of things? is authentication needed for this?
In general there is no authentication from one SMTP server to another. The only authentication is from you to gmail.
This is one reason why spam is such a problem. The basic SMTP protocol just assumes there is no spam. You open a connection to a mail server and just send the headers like
from: mehrdad#gmail.com
to: gman#yahoo.com
Hello
And yahoo.com (the receiver) will happy except the email regardless of what computer it came from.
Because of those issues things have been added but they are optional.
One is DKIM. It works by signing your email with a digital signature. The signed email can be verified by the receiver (in your case by yahoo). Yahoo can check for gmail's public key in gmail's DNS records and check that the mail's signature cryptographically matches. It's up to the receiver (yahoo) to decide if it wants to check that or not. If the sender (Google or a spammer) does not add the signature then again, it's up to the receiver to decide what to do with the message. It could assume it's okay and pass it on. It could check if there is a public key available and if it is and the email has no signature then may not pass it on? Or mark it as "possibly spam"
There's also SPF. SPF is designed so that the receiver (yahoo) can verify that only the sender (Google) is allowed to send mail from gmail.com.
Then there is DMARC. DMARC lets Google (the sender) tell Yahoo (the receiver) what to do when when the stuff above fails. For example wither or not to forward messages who's signatures don't match the key. It's up to the receiver to decide to use this info.
Along with the linked wikipedia articles here's a pretty good overview of what happens and the problems involved.
I have read a lot of articles saying that in WCF you have two types of security one is transport level and other is message level. Transport level security must be used when you have intranet connection as it provides point to point security and underlying protocol should be SSL....
But if I search on how to secure public websites they all say use HTTPS(SSL) again SSL.
These two statements are contradictory.
Questions:
What exactly is the meaning of point to point security here?
If SSL is only point to point(and not end to end) then why people use it for public websites?
HTTPS encrypts data from point-to-point, and once the data reaches one of the points and is decrypted, no security guarantee is made from that point onwards. Intermediary nodes, however, cannot read the information.
Message security, on the other hand, can encrypt data to be decrypted only by a certain recipient, which can be a separate entity from the receiving end. The receiving end might eventually forward the encrypted message to the intended recipient who will be able to decrypt the message.
An analogy would be email. If you establish a connection with your mail server using transport security (e.g. HTTPS), any information is guaranteed to be secured from your machine to the mail server. However, anyone with access to the mail server (e.g. server administrators) will be able to read the content of the email.
On the other hand, if you use message security to encrypt the message so only a specified recipient can decrypt it, the actual email message is encrypted (and not simply the communication between you and the server), so that even once the message is received by the server, it is still encrypted. Only when the email server forwards your message to your intended recipient, the recipient can decrypt the message using his own private key, thereby keeping the email private across a whole path of delivery while not requiring direct communication by the sender and that recipient, as is required by transport-level security.
Of course, some parts of the message must remain visible to the email server, for example the recipients address, and so you may want to use both levels of security: message security will ensure the mail server (or any party except the recipient) can't read the content of your email, and transport security will additionally ensure that a third party listening in to the communications between you and your mail server can't find out who you're sending an email to (unless the mail server divulges that information to that third party
Taken from WCF Transport security weakness
Read more here https://msdn.microsoft.com/en-us/library/hh273109(v=vs.100).aspx
Answer to question 2 :
Because once it reached to the IIS Server which is hosted by the company itself/or in Data center which has all firewalls and other security measures which is hard to bypass which means no one can read your message from that server unless is can hack everywhere it saves oecerhead of tcp security.
How can i make my email as verified like PayPal, even though my URL and exchange server is having SSL certificate its still going to spam folder.
From https://support.google.com/mail/answer/3070163?hl=en
...who match the following criteria:
Send a high volume of messages over time that most Gmail users think are not spam.
Publish a DMARC reject policy, which means that the domain only sends authenticated mail and any unauthenticated mail sent by the domain should be rejected.
Which means in effect that
You have to be important for lots of users, so that they need to be protected from phishing mails claiming to be you.
And you have to properly controlled the delivery of your email, that is have published DKIM, SPF policies to control who should be able to send email with your domain and how to proof that these emails where delivered by your domain. See http://en.wikipedia.org/wiki/DMARC.
I'm coding an SMTP Server here and wondering an issue which I don't know how to proceed.
You know that when you using Outlook, ThunderBird or any email client to send email, we need (the most of times) username and password to authenticate with the SMTP Server. In this case, SMTP Server requires an "AUTH LOGIN" before other commands such as MAIL, DATA...
I completed this stub in my project. But I'm wondering about a case, when another SMTP Client send directly to my SMTP Server. I mean our server is the final destination of the email. In this case, the authentication with AUTH LOGIN should not be required.
How can I organize my code for 2 cases above. How does the professional MTA such as Postfix, PowerMTA, Exim organize for these.
I hope you will help me
Most outgoing SMTP servers do one of the following:
1) Require SMTP Authentication
2) Alllow relaying without SMTP Authentication only from clients within a certain IP range
If you are doing neither of the above, then that means that your SMTP server is basically operating as an 'open relay', meaning that spammers can abuse your server to send outgoing spam mail.
Many ISP-hosted SMTP servers do #2 above, to allow their clients (and only their clients) to send mail through their SMTP server - as long as the client is on their network.
On 2nd edition of "Programming WCF Services" By Lowy, ch 10, page 512.
Lowy said about Transport security: Its main downside is that it can only guarantee transfer security point-point, meaning when the client connects directly to the service. Having multiple intermediaries between the client and the service renders Transport security questionable, as those intermediaries may not be secure. Consequently, Transport security is typically used only by intranet applications.
HTTPS is one of Transport security options, How previous paragraph applies to HTTPS ?!!, HTTPS encrypts every thing all the way from start to end points. Also every e-commerce application in the world is using HTTPS, how you can limit it to intranet applications!!
Thanks
HTTPS encrypts data from point-to-point, and once the data reaches one of the points and is decrypted, no security guarantee is made from that point onwards. Intermediary nodes, however, cannot read the information.
Message security, on the other hand, can encrypt data to be decrypted only by a certain recipient, which can be a separate entity from the receiving end. The receiving end might eventually forward the encrypted message to the intended recipient who will be able to decrypt the message.
An analogy would be email. If you establish a connection with your mail server using transport security (e.g. HTTPS), any information is guaranteed to be secured from your machine to the mail server. However, anyone with access to the mail server (e.g. server administrators) will be able to read the content of the email.
On the other hand, if you use message security to encrypt the message so only a specified recipient can decrypt it, the actual email message is encrypted (and not simply the communication between you and the server), so that even once the message is received by the server, it is still encrypted. Only when the email server forwards your message to your intended recipient, the recipient can decrypt the message using his own private key, thereby keeping the email private across a whole path of delivery while not requiring direct communication by the sender and that recipient, as is required by transport-level security.
Of course, some parts of the message must remain visible to the email server, for example the recipients address, and so you may want to use both levels of security: message security will ensure the mail server (or any party except the recipient) can't read the content of your email, and transport security will additionally ensure that a third party listening in to the communications between you and your mail server can't find out who you're sending an email to (unless the mail server divulges that information to that third party).