I am trying to access my website using both its domain name and static ip address via https protocol.
When I use just domain it works as expected, but when I add ip address as following:
my.domain.com {
respond "Hello from domain"
}
10.20.30.40 {
tls internal
respond "Hello"
}
it does not work. Moreover if I use tls internal for different port:
my.domain.com {
respond "Hello from domain"
}
:8080 { <----------- Here I use port
tls internal <------------- and tls internal
respond "Hello"
}
accessing by domain name in browser now warns that certs are not publicly trusted. I assume that tls internal in second block affected first block. Is it right? Why so?
Anyway, my main question is how to access my website both via domain name and ip address even if I need to use different ports with caddy over https. I know, that for some historical reason ip addresses cannot have publicly trusted certs so it is ok if ip address will use self signed certs.
pls help!
Caddy version: v2.3.0
Does anyone know what the IP range is for https://account-d.docusign.com? They cycle IPs every few minutes.
Our security team is constantly having to update our firewall.
The IP addresses will change and continue to change as DocuSign add servers, locations, etc.
Is there no way to have the firewall use the URL instead of IP Address?
You cannot expect IP addresses to be static
This page - https://www.docusign.com/trust/security/esignature list the IP Address range as:
North America-based and demo accounts (current and continuing):
**NEW 209.112.104.1 through 209.112.104.254
64.207.216.1 through 64.207.219.254
162.248.184.1 through 162.248.187.254
European Union-based accounts (current and continuing):
185.81.100.1 through 185.81.103.254
Australian-based accounts (current and continuing):
13.72.248.93
13.72.249.142
13.70.141.103
13.70.136.159
Based on the below reference link in configuring Haproxy with TLS:
Do i need to have the certificates generated with common SAN(Subject ALternate name) on all the target nodes (or)
Having the individual certs without any common SAN would work ?
https://serversforhackers.com/c/using-ssl-certificates-with-haproxy
Look at https://security.stackexchange.com/questions/172626/chrome-requires-san-names-in-certificate-when-will-other-browsers-ie-follow : some browsers (Chrome) require names to be in the SAN part as they disregard now completely the CN field
So even for a one domain certificate you need the domain both in the CN (as this is not optional) and in the SAN part.
It is also in the CAB Forum requirements, section 7.1.4.2.1 :
Certificate Field: extensions:subjectAltName
Required/Optional: Required
Contents: This extension MUST contain at least one entry.
Each entry MUST be either a dNSName containing the Fully-Qualified
Domain Name or an iPAddress containing the IP address of a server.
The CA MUST confirm that the Applicant controls the Fully-Qualified
Domain Name or IP address or has been granted the right to use it by
the Domain Name Registrant or IP address assignee, as appropriate.
Wildcard FQDNs are permitted.
Note that some other browsers, like Firefox, fallback to the CN instead, see https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 and see beginning of patch at https://hg.mozilla.org/mozilla-central/rev/dc40f46fae48 for the security.pki.name_matching_mode configuration option.
Mailgun recommends creating DNS (TXT, MX,..) records for a subdomain, but states sending and receiving with the root domain is possible by later configuration. I created all necessary steps for mail.example.com at my registrar and at Mailgun (adding a domain, setting up routes, etc.).
I can now receive and send emails to the configured example#mail.example.com.
What do I have to change now to be able to send and receive at example#example.com?
What are the necessary changes at the registrar, in mailgun, and in my smtp settings at gmail (for sending from gmail via mailgun)?
Thank you very much!
If you configure Mailgun for a subdomain, you can send emails from your main domain passing a proper to variable. For instance, using Node.js + nodemailer + nodemailer-mailgun-transport:
var nodemailer = require('nodemailer'),
mg = require('nodemailer-mailgun-transport'),
auth = { api_key: 'foobar', domain: 'mail.example.com' },
nodemailerMailgun = nodemailer.createTransport(mg({ auth: auth }));
nodemailerMailgun.sendMail({
from: 'helloworld#example.com',
to: 'recipient#domain.com',
subject: 'Hey you, awesome!',
text: 'Mailgun rocks, pow pow!'
}, someCallback);
Or you can read about other methods of sending through an API in their docs. Anyway, even if your Mailgun is configured for a subdomain, you can send email from your main domain.
However (!) your MX records are configured for your subdomain, and hence you can only receive emails there. To be able to receive email to your main domain, add your main domain in Mailgun's control panel, e.g. not mail.example.com, but example.com, and make an according configuration in your DNS control panel for this main domain, example configuration for DigitalOcean's DNS for example.com (not subdomain):
TXT # v=spf1 include:mailgun.org ~all
TXT krs._domainkey k=rsa; p=MIGfM...blablabla
CNAME email mailgun.org.
MX 10 mxa.mailgun.org.
MX 10 mxb.mailgun.org.
Keep in mind, that Mailgun does not have mailbox functionality, it can only forward incoming emails, if you have an appropriate rule set. Most people delegate their main domain's MX records to a more manageable ESP, like Gmail. You can only have one set of MX records for a domain, so you have to choose, either Gmail, or Mailgun.
You need to use mailgun-js for this
Require mailgun-js from npm
var Mailgun = require('mailgun-js');
2.Set options for mailgun. i.e. apiKey and domain.
var options = {
apiKey: 'YOUR_API_KEY',
domain: 'YOUR_DOMAIN'
};
Instantiate mailgun with these options.
var mailgun = new Mailgun(options);
Send email after setting required parameter for it.
var data = {
//From email
from: '',
// Email to contact
to: 'To Email address',
// CC email
ccTo: 'CC address if any'
// Subject
subject: 'Mail subject',
// Email msg
html: 'email message or html'
};
// Send email
mailGun.messages().send(data, callbackFunction() {
});
I've only been using Mailgun a short time, but I can help with what I've learned so far.
Your DNS records can be setup for Mailgun or a third party like Gmail. I don't think they will use both. I'm not sure what that would do to the routing, because it would not know where to go.
For your Mailgun subdomain, you used mail.example.com with email address example1#mail.example.com. Mine is running, but I did not create email addresses like that at all. My email formats are still example1#example.com.
I am going to paste this in from an email I received, and edit it to match your provided example:
It looks like you have set the MX records for the root domain, example.com, however the domain you are using with Mailgun is mail.example.com. You will need to change the hostname from example.com to mail.example.com for these to route correctly.
As Mailgun does not have mailboxes, receiving email with Mailgun requires using a subdomain with MX records pointing to Mailgun as well as using our Routes functionality. A good way to understand Routes is as a sophisticated filtering and forwarding mechanism. With Routes, you can either:
forward the incoming email to another environment for storage (such as an email address or an endpoint on your server
store a message temporarily (for up to 3 days) and retrieve it using the Messages API
stop a message from being processed (i.e. dropping certain messages instead of forwarding or storing them)
If you're trying to use Django's Anymail package to send Mailgun email from a subdomain, you need to send the email using the EmailMultiAlternatives object and specify the Email Sender Domain like so:
from django.core.mail import EmailMultiAlternatives
msg = EmailMultiAlternatives("Subject", "text body",
"contact#example.com", ["to#somedomain.com"])
msg.esp_extra = {"sender_domain": "mg.example.com"}
msg.send()
sometimes, erratically, when my server sends an email to an "internal" address managed by google apps as a distribution list I get those errors
Received: from ovhprod.diveboard.com ([2607:5300:60:1d85::1])
by mx.google.com with ESMTPS id e4si6519596qas.128.2013.08.14.00.28.57
for <logs#diveboard.com>
(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
Wed, 14 Aug 2013 00:28:57 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning plugin#diveboard.com does not designate 2607:5300:60:1d85::1 as permitted sender) client-ip=2607:5300:60:1d85::1;
Authentication-Results: mx.google.com;
spf=softfail (google.com: domain of transitioning plugin#diveboard.com does not designate 2607:5300:60:1d85::1 as permitted sender)
I did add SPF records but it looks like I did it wrong - any hint !?
# 10800 IN SPF "v=spf1 a mx include:smtp1.uservoice.com ~all"
# 10800 IN SPF "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
# 10800 IN SPF "v=spf1 ip4:192.95.11.34/30 ptr ?all"
# 10800 IN SPF "v=spf1 ip4:198.27.68.133/32 ip6:2607:5300:60:1d85::1/64 ptr ?all"
# 10800 IN TXT "v=spf1 a mx include:smtp1.uservoice.com ~all"
# 10800 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
# 10800 IN TXT "v=spf1 ip4:192.95.11.34/30 ptr ?all"
# 10800 IN TXT "v=spf1 ip4:198.27.68.133/32 ip6:2607:5300:60:1d85::1/64 ptr ?all"
You can only have one 1 SPF string per host. A SPF record can be specified as TXT or SPF record. The best practice is to have 1 TXT and 1 SPF record.
Check your domain here:
http://spf.myisp.ch
I suggest you read the whole SPF page on Wikipedia: http://en.wikipedia.org/wiki/Sender_Policy_Framework#FAIL_and_forwarding
Your SPF record is not well written. You can have only one SPF record.
You could replace all of them with
"v=spf1 a mx ptr ip4:192.95.11.34/30 ip4:198.27.68.133/32 ip6:2607:5300:60:1d85::1/64 include:smtp1.uservoice.com include:_spf.google.com include:sendgrid.net ~all"
However the last SPF specification recommends avoiding PTR mechanism.