I have an inbound Email action setup in a ServiceNow instance, however not all Emails sent by users to that Email address should be handled by that ServiceNow instance.
Is it possible to create an inbound Email action for the same Email address on a separate ServiceNow instance while keeping the original inbound Email action on the other instance? I would take care of adding the necessary filters to avoid duplicate tickets.
Related
I have two AWS accounts, we'll call them A and B.
Account A hosts a rabbitMQ broker in AmazonMQ.
Account B has a lambda function that performs some actions and ultimately needs to send some messages to the queues in account A.
Currently, some consoles outside of AWS are sending messages to the queues, for security reasons Account A uses a subnet with specific ACL rules allowing only traffic from these consoles to reach the queues.
I'm unsure how to allow this lambda to send messages to the queues in account A, while this lambda must continue to live in account B. The lambda connects via MassTransit and the amqp endpoint, the same way the non-AWS consoles connect.
If I create a rule allowing all traffic I am able to send messages successfully. so I'm fairly certain the problem lies somewhere in these ACL rules. I've tried putting my lambda into a VPC and whitelisting its CIDR blocks in the ACL inbound rules with no success. I also tried a peering connection between the two accounts to no success.
I want to use AWS SQS for communication between my microservices (and later possibly SNS). Each microservice can have multiple instances up.
Currently I'm trying to implement the Request/Response pattern of message queues.
As I understand it, the normal way is to have one request queue, and pass a unique response queue per service instance.
The consuming service will process the message and send the response to the given response queue. Thus, the response will always be returned to the correct instance of the requesting service.
My problem now comes with Cloudfoundry.
How it should work:
Service A needs to request data from Service B.
There is one queue named A-request-B.
Service A starts with 6 instances.
Every instance creates its own queue: B-response-A-instance[x]
Every request from an instance of A sends their response queue name in the request so response is routed to the correct queue.
This is the only way I know to guarantee that the response from B gets to the correct instance of A.
This doesn't work as Cloudfoundry doesn't allow the "create-queue" call from SQS, even if I can connect to the SQS instance to send and receive messages.
The only way to create a queue is via the command line.
So I would have to create these 6 response-queues manually beforehand.
And if I start a 7th instance of A, it will fail as it doesn't have its own response queue.
I also tried using the SQS temporary queues, but they also work by creating queues dynamically which is not possible in Cloudfoundry.
I'm currently stuck with SQS, so switching to kafka/rabbitmq or something else is not possible.
Is there any other way to pass a response to the matching service instance? Or is there another way to create queues in cloud foundry?
Summary from comments above...
This doesn't work as Cloudfoundry doesn't allow the "create-queue" call from SQS
Cloud Foundry doesn't really care what messaging system you're using, unless you're using a Marketplace service to create it. In that case, Cloud Foundry will work on your behalf to create a service instance. It does this by talking to a service broker, which does the actual creation of the service instance and user credentials.
In your case, Cloud foundry handles creating the credentials to the AWS SQS through the AWS Service Broker. Unfortunately, the credentials the broker gives you don't have the permission to create queues. The creds are only allowed to send and receive messages for the specific queue that was created by the broker.
There's not a lot you can do about this, but there's a couple options:
Don't use the Marketplace service. Instead, just go to AWS directly, create an IAM user, create your SQS resources, and give the IAM user permissions to them.
Then create a user provided service with the credentials and information for the resources you created. You can bind the user provided service to your apps just like a service created by the AWS Service broker. You'd lose the convenience of using the broker, but you won't have to jump through the hoops you listed when scaling up/down your app instances.
You could create a service instance through the broker, then create a service key. The service key is a long-lived set of credentials so you could then go into AWS, look up the IAM user associated with that service key and adjust the permissions so that you can create queues.
You would then need to create a user provided service, like the first option, insert the credentials and information for your service key and bind the user provided service to any apps that you'd like to use that service.
Don't delete the service key, or your modified user will be removed and your user provided service will stop working.
Hope that helps!
I am curious to know why Direct mail doesn't support the incoming emails to the same email address used to trigger the notifications. Why do we need to receive on another email?
Is there any architectural limitation to this in terms of security/functionality etc..
Providing email services that includes receiving emails is a different level of service then sending emails and far more complicated internally. DirectMail is a message sending service, not an email server. Alibaba does offer a full email service for its customers in China.
Hosting and receiving emails is far more complex. If you were to provide a service to send and receive emails you have to have an api waiting for an email to arrive, another to retrieve emails from the storage when the user requests, and another to send out the emails.
On the other hand DirectMail just has one service send out either predefined emails that get set up ahead of time or emails that are sent from Function Compute. This way there is no waiting/server overhead, just send and done.
I need to know what all clients are watching what type of data in my subscription server. How can I do that?
You can log all the queries/schemas that are being sent to the GraphQL server
from there you can check which objects and fields are being selected
as part of the request that was made, you should have an IP address or an API key that can be used to identify the client
I have an application hosted in an Amazon EC2 Server that uses e-mail service from a shared web host. I did this to utilize the shared hosting e-mail server and the available e-mail administration tool and webmail interface.
My application uses amazon SES to send e-mail. I just authorized SES to send mails with my domain name (by adding some entries to my dns records and confirming I'm the domain owner), and this is working ok. When I need to send a mail, I connect to SES SMTP server and send it using PHPMailer.
Everything is working ok, except my mails are getting the DOS_OUTLOOK_TO_MX flag in SpamAsssasin's, making it sometimes be classified as spam.
What this flag means? Is there some way to avoid it?
Spamassassin DOS_OUTLOOK_TO_MX rule is fired when two internal flags are set by processed message: __DOS_DIRECT_TO_MX and __ANY_OUTLOOK_MUA.
__DOS_DIRECT_TO_MX flag means that the message was sent directly from sender email client to recipient MTA server. This is usually true for internal mail but can occur in your case when a recipient also uses Amazon SES for mail processing.
__ANY_OUTLOOK_MUA flag means that the message has X-Mailer =~ /^Microsoft (?:Office )?Outlook\b/ header.
Both internal flags are harmless by themselves but their combination leads to DOS_OUTLOOK_TO_MX with high spam score. You need to check X-Mailer header of messages sent with PHPMailer. This header should be set to PHPMailer, not to Microsoft Outlook or something similar.