As it turns out, according to Support, it's a regression of an older issue. They have now installed the hotfix in our instance and that solved the issue without having to change our code and workflow on my end.
Perhaps, if the regex can't be simple (if your IT service denies putting simple rule but wants to put full URL), or if anything else such as character mistype, I suggest asking them for setting debugTrace mode to true; and if not enough, temporarily they can't put "ignore" value for action attribute, so it comes back to previous situation before 8857 build (July 2017), less secure but acceptable for temporary tests, in order to check that the issue comes from urlPermission rule and not from anything else.
action : Default action if the URL is not in the authorized list. Values: deny (default), warn, ignore
debugTrace : Debugging trace of the URL selection mechanism Default: false -->
Please may you explain your real goal, not the issue you cope with?
In the meanwhile, a short reminder/explanation:
An included file, whatever being a file on the server or a html file given by URL (only syntax differs but the principle is the same), must be:
a valid html code to include in your html delivery message (not only portion of html adapted in the logic of inclusion placeholder, but also compliant with email deliverability rules (no div element but table, etc etc). But perhaps the URL resource file is the full email body content, in your case? please confirm
beeing accessible from the Adobe Campaign applicative server (not the MTA server, because inclusion is done during the preparation phase); as you can see in your own logs, it can depend on port (http/https), so check if there are firewall rules blocking your URL resource file to be acceded.
Thanks, Jean-Serge. Yes, you are correct: we don't have Content Manager, unfortunately.
As for the urlPermission, we're actually using http only. The https test I mentioned in the original post was just a curiosity on my part, to see if it resolves anything. The base URL that I provided to Support was also http, so I wouldn't be surprised if they hard-coded only http, which is fine. That said, I've asked Support to provide the exact URL that they added to our serverConf.xml file. I'll update once I hear back.
In the meantime, do you have other thoughts as to how to fix this?
So, let's try to resolve your issue in your current situation!
To my mind, the urlPermission regex are probably too strongly defined; can you check again on your applicative server (not MTA) the urlPermission for your domain URL?
I don't fully understand what the code does, but it looks like it's grabbing whatever is in the URL (which in this case contains the web version of a daily newsletter) and writes the full HTML code of that web page into the email template during execution.
Here is the code that's in the email template:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<% document.startBuffering(); %>
<%@ include file='(sample newsletter content URL here)'%>
var dte= formatDate(new Date(), "%ail, %bil %2D, %4Y");
var html = document.stopBuffering();
html = html.replace(/(\r\n|\n|\r)/gm, "");
html = html.replace(/<\$\$ RECIPIENT \$\$>/g, recipient.id);
html = html.replace('Sample Newsletter', dte);
// Get body style
var bodyTmp = /<body[^>]+style=\".*?\"/.exec(html)
var bodyStyle = /style=\".*?\"/.exec(bodyTmp)
// Get title
var title = /<title>[^<]+<\/title>/.exec(html)
// Get body
var body = html.replace(/.*<body.*?>(.+)<\/body>.*/ig, '$1');
<%= title %>
<% document.write(body); %>
I suspect that something has changed after v6 8795 (our last build before upgrading to 8883 this week). The base URL of the link referenced in the include file has already been added by Support/TechOps to our serverConf.xml due to the enhanced security around using URLs, but we're not sure why this particular issue persists.