As stated in the title, is it required to set up a custom domain on Mailgun? or ok to continue using the "sandbox" domain name?
If optional, what is the downside of using the "sandbox" domain?
It is OK to continue to use the sandbox domain, it will just not have a recognizable domain
Sandboxed domains are quite limited in that you can only send emails to authorized recipients which need to be configured inside the UI manually.
Beyond that, even if you only have a small set of users then you need to also set up SPF and DKIM for best practices (Yahoo will reject all emails without this and DMARC) which means having a domain name anyway.
So for the hassle, you are better off just configuring your own domain and working from there.
Related
I can see that from SendGrid I can send email, where the from field will show any email which the end user will put. With AWS SES how can I achieve this?
As I see in the docs it needs to verify the email/domain before doing this. Is there a way to do this?
In SES you can only send emails from verified domains or verified emails. And in either cases you would need to own them otherwise you cannot verify them and subsequently you cannot use those.
Once you verify a domain it is more liberal in the sense that now you can use any arbitrary id at that domain
So e.g. if you verify xyz.com domain then you can use any id #xyz.com
E.g. myid1#xyz.com or jghdgd#xyz.com
That might be about policy
Not very familiar with send grid.
We use sparkpost as another ESP and there as well you can only use only authenticated domains. And that makes sense as well because otherwise people can just adopt any arbitrary identity for spamming
Have took 2 day, can't find a good method.
1.AWS Linux instance have pre-install sendmail, I only need to send out email. But don't how to configure sendmail and other package.
2.Try to use AWS SES, however it needs to verify domain, which means I need to deal with AWS Router 53. After reading very complicated document and "create hosted zone", the AWS SES domain verification still "pending" after 24 hours. I am guessing maybe the default EIP domain name, like "ec2-***-amazonaws.com" is not a qualified/Registered domainn ?
As a newbie for SMTP setting, really don't know what to do? Since even if using a free mail server, it seems still need to 'verify domain', if aws default domain name "ec2-***-amazonaws.com" is invalid, how can I pass the domain verification?
By the way, since sendmail is pre-install, and this website is very simple, small group used, how to set configuration and other package to do email server on this instance itself?
Any suggestion is appreciated!
Thank you
It's much easier if you configure email from your Django app directly to a third party email provider, effectively by-passing the local sendmail configuration altogether. Trying to set up an email connection to AWS/SES on the server itself is also a pain, it's also much easier to configure the Django app to connect directly to AWS/SES
You have three very popular choices to setup email from Django:
Set up a connection to Gmail/Google apps .- If you'll be sending a lot of email volume I wouldn't recommend this option, because they block you easily if you use it to relay a lot of email.
Set up a connection to AWS/SES.- You mention you already tried this, but now try to set the connection inside Django using the Python packages boto and django-ses, this will make the email setup much easier. In addition, boto is also useful if you plan to use some other AWS service like S3.
Set up a connection to Mandrill.- This is another provider, not as big as Google or AWS, but they provide good service with decent free email volume and you can also set up a connection directly from Django.
Take a look at this article -- which I wrote -- that describes all the set up steps for all three providers in detail:
http://www.webforefront.com/django/setupdjangoemail.html
I am trying to construct a application that will allow a user to reset his domain password and get access to their box while it is off domain and off the corp network. E.G. User is a domain user, is traveling off network and forgets his password. He can of course login using his domain creds because they are cached locally in the HKEY_LOCAL_MACHINE\SECURITY\Cache. Unless of course he has forgotten his password. I have already created a login shell addition that will take the user through web 2.0 style security questions etc. to verify their identity. However the last step, actually updating the local security cache with the new password such that the user can continue to login until they resync with the domain controller eludes me. I have looked through all the API's CredWriteDomainCredentials, CredWrite etc. etc. but there does not seem to be an official way to do this. Does anyone have any idea how to write a new hash to the local store essentially simulating a valid domain logon and cache write event?
I am creating a web service for end users which will have a front-end in the form of an Adobe AIR desktop app but users will be able to access their data through the website too. User's data will be synchronized between the server and the local data store. The problem is that I cannot get an SSL certificate. Is there a way to make this more secure....
I think I can use something like two-legged oAuth or an Amazon S3 like authentication system?
What do you recommend in such a situation?
The first question is: why can you not get an SSL certificate? I can think of two reasons:
SSL certificates are too expensive
You don't want to have a certificate issued by a third party
If your problem is #1, StartSSL provides free certificates with a 1-year validity or charges $50 for unlimited certificates valid for 2 years (including wildcards). They are recognized by both Mozilla and the Microsoft trust store.
If the issue is #2, why not issue a self-signed certificate and hard-code it into your application? That does not compromise the security of the system at all (only your particular cert will be accepted by the app), but eliminates the need to "get" an SSL certificate from somewhere else.
If you really really can't use SSL, look at challenge-response systems such as Kerberos or anonymous key-material generators like Diffie-Hellman (with an asymmetric key for server identity validation). Many methods exist for secure two-party authentication over an insecure line. The key is that the ID verification step must be challenge-response instead of a "send me your secret" scheme.
If I want my account holders to be able to have their own sub-domains and even their own domains altogether. Using NGINX as my proxy server, should I create domains for each one in my NGINX conf and have my clients point their domains there or is there reasons why this would be bad? Also, if I do that, how can I pass account-specific (account in Django DB) information in with the request (ie, request from www.spamfoosaccount.com to my server, so I proxy the request back to Apache, but how does my application know that it came from spamfoo's account unless I look at request.HTTP_HOST (which might be the best way, but I don't know until I ask). Thanks in advance.
To know from which domain a request is coming from, you have to use request.META["HTTP_HOST"].
However, do not rely on this value for authentication, it can be forged easily. Authentication should be done in the usual way with django.contrib.session. A request from a specific domain/subdomain should not have more privileges/rights, even when the request contains an authenticated session. Privileges should be given to users/groups of users, not to domains.
Note that browser sessions cannot cross second-level-domains (e.g. session cookie from foo.com wil not be sent to bar.com), it can however be a *.foo.com cookie for all subdomains (if you explicitly set it so).
Let your users point their DNS records to the IP of your server, let NGINX route the request based on the domain to your backend and do normal authentication in Django.
Your question:
how does my application know that it
came from spamfoo's account
I don't know the specifics of your application, but it shouldn't matter where the request came from, but who issued the request (e.g. an authenticated user). You should have a model/field that links your users to their respective domains. When a user is linked to only one domain, the application should assume the user came from that domain. When a user is connected to more than one domain, you can look at request.META["HTTP_HOST"]. If this value matches any of the domains, the user is linked to, it's alright, the value may be forged, but by a user that is linked to that domain nonetheless.