When sending emails via javamail, the following is always appended to the bottom of each message:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager. This message contains confidential information and
is intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system. If you
are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited.
How does one prevent this?
(NOTE: This problem is extremely frustrating to research on the web due to the fact that a disclaimer of this form is attached to so many indexed documents! :-(
JavaMail is not doing that, it is your outgoing SMTP server appending it to each message, probably set up by IT.
To confirm, you can use gmail's servers (with a personal account) and you will see it does not get added to the messages.
This should work. Pay attention to the form in which email body get parsed. In my case the emailBody string is on one line, so you have to put the "#Your disclaimer Here#" on one line. Answer for who will come in future.
public String deleteDisclaimer(String emailBody) {
String disclaimer = "#Your disclaimer here#";
if (emailBody.contains(disclaimer)) {
System.out.println("Deleting Disclaimer..");
return emailBody.substring(0,emailBody.indexOf(disclaimer));
}
System.out.println("DISCLAIMER NOT FOUND!");
return emailBody;
}
Related
We are using pubsub & a cloud function to process a stream of incoming data. I am setting up a dead letter topic to handle cases where a message cannot be processed, as described at Cloud Pub/Sub > Guides > Handling message failures.
I've configured a subscription on the dead-letter topic to retain messages for 7 days, we're doing this using terraform:
resource "google_pubsub_subscription" "dead_letter_monitoring" {
project = var.project_id
name = "var.dead_letter_sub_name
topic = google_pubsub_topic.dead_letter.name
expiration_policy { ttl = "" }
message_retention_duration = "604800s" # 7 days
retain_acked_messages = true
ack_deadline_seconds = 600
}
We've tested our cloud function robustly and consequently our expectation is that messages will appear on this dead-letter topic very very rarely, perhaps never. Nevertheless we're putting it in place just to make sure that we catch any anomalies.
Given the rarity of which we expect messages to appear on the dead-letter-topic we need to set up an alert to send an email when such a message appears. Is it possible to do this? I've taken a look through the alerts one can create at https://console.cloud.google.com/monitoring/alerting/policies/create however I didn't see anything that could accomplish this.
I know that I could write a cloud function to consume a message from the subscription and act upon it accordingly however I'd rather not have to do that, a monitoring alert feels like a much more elegant way of achieving this.
is this possible?
Yes, you can use Cloud Monitoring for that. Create a new policy and perform that configuration
Select PubSub Topic and Published message. Observe the value every minute and count them (aligner in the advanced option). Now, in the config, when it's above 0 from the most recent value, the alert is raised.
To filter on only your topic you can add a filter by topic_id on your topic name.
Then, configure your alert to send an email. It should work!
Is it possible to change the recipient address when using the reply function in Google Apps Script?
I want to receive an email from a random email account, mark it with a label and when scheduled, run the following code to reply to a desired email address rather than the original sender. The reason I want to reply is to keep it in the same thread. I have tried nearly all variations of the following code and can't get it to work the way I want it to:
thread.reply("This is a message.", {
htmlBody: "This is a message.",
name: "My Name",
recipient: "DESIRED#EMAIL.com",
replyTo: "DESIRED#EMAIL.com",
to: "DESIRED#EMAIL.com"
});
If you're asking to generate a random email address and send a real email from that address... that's not possible.
However... you could set the replyTo optional parameter as a random address - though when users would try to reply to that thread they would get a bounce-back notification that the address could not be reached. However, the original sender (the non-random address) would still be visible in the original message.
If you look at the GmailApp docs (replying)/(sending), you'll notice a few limitations. The sender's address (from) must be a valid Alias, if you're sending mail from MailApp (Google Apps Script).
However, there are plenty of methods in the GmailMessage class such as getFrom() and getReplyTo() that would allow you to get/set the message's from/replyTo parameters and have them be the same value. That way, when you reply to a message you will always be in the same thread.
Before the client sends a new email, he/she specifies one or more (To) destination addresses. Is there any way to check the validity of these emails before sending the message ?
Define "validity".
This JavaMail FAQ entry might help.
The InternetAddress class only checks the syntax of the address. The InternetAddress class is not able to determine whether the address actually exists as a legal address. It is not even possible to verify the host name if the application is running behind a firewall or isn't currently connected to the Internet.
I am trying to connect to rabbitmq-c in centos 5.6 and test its function in c client following the steps of the website: http://www.rabbitmq.com/tutorials/tutorial-one-java.html.
However, it fails when I use the default exchange.
For example, I want to send a message, "Hello world", to a queue named "myqueue" via the default exchange whose name is "(AMQP default)".
In java, here is the code:
channel.basicPublish("", QUEUE_NAME, null, message.getBytes());
But in c, when I run rmq_new_task.c (almost the same as amqp_sendstring.c) as the examples on https://github.com/liuhaobupt/rabbitmq_work_queues_demo-with-rabbit-c-client-lib.
queuename="myqueue";
......
die_on_error(amqp_basic_publish(conn, amqp_cstring_bytes(exchange),
amqp_cstring_bytes(routingkey), &props, amqp_cstring_bytes("Hello world")),
"Publishing");
In the java client, we just set the parameter "exchange" to "" to tell the server that we'd send the message to a specified queue named the same as routingkey via the default exchange.
So what value should I give the second parameter "exchange" in c client (using the default exchange)? I tried to set it to "" or "amq.direct". It didnot show any error while running and seemed working well.
However, when I checked in the rabbitmq-management(http://localhost:55672/#/queues), the queue named "myqueue" did not exist!
Would someone please point me to the right direction? I'd really appreciate!
Take a look at http://www.rabbitmq.com/tutorials/amqp-concepts.html and specifically look for the section entitled Default Exchange.
The usage of the default exchange is very simple.
In java you would do:
channel.basicPublish("", "hello", null, message.getBytes());
By specifying "" in says to use the default exchange. (There should be no need to use amq.direct)
As per the article above it states:
The default exchange is a direct exchange with no name (empty string)
pre-declared by the broker. It has one special property that makes it
very useful for simple applications: every queue that is created is
automatically bound to it with a routing key which is the same as the
queue name.
So that means publishing to the default exchange will only work if you have already created the queue that you want to publish to.
So you will need to create your queue before you can publish to the default exchange. Once you've done that you will start seeing your messages.
I'm using Twilio to send sms's with appengine. Twilio doesn't accept sms's longer than 160 characters so I have to split them. I am splitting the sms's and sending them as follows:
def send_sms_via_twilio(mobile_number, message_text):
client = TwilioRestClient(twilio_account_sid , twilio_auth_token)
message = client.sms.messages.create(to=mobile_number, from_=my_twilio_number, body=message_text)
split_list = split_sms(long_message)
for each_message in split_list:
send_sms_via_twilio(each_message)
However I found that the order of sending varied. For example sometimes I'd recieve message 2/5 then 1/5 then 4/5 etc and other times the order would be correct. The order of the split_list is definately correct. To overcome the incorrect order of the sms's I tried
for each_message in split_list:
deferred.defer(send_sms_via_twilio, each_message, _countdown=1)
However I encountered the same problem. I then tried
for each_message in split_list:
deferred.defer(send_sms_via_twilio, each_message, _countdown=1, _queue="send-text-message")
and defined my queue as
- name: send-text-message
rate: 1/s
bucket_size: 10
max_concurrent_requests: 1
retry_parameters:
task_retry_limit: 5
Thinking that the issue was concurrency (running in python27) and that if I limited max_concurrent_requests this issue would be solved. However the issue is still present i.e. the texts still get sent in the wrong order. I checked the logs but couldnt see any notification of task failure - they just seem to be executing in the wrong order.
Is there something I am missing? How can I fix this issue.
Note that the SMS messaging (specifically the underlying protocols like SMPP) are asynchronous by definition. It means there is no way you can specify the order of distinct SMS messages.
There is a way to specify the order of SMS packets by using the UDH (user defined headers) in the binary body of those messages. But this works only for long SMS messages -- those that are too long to be sent in one message. For example, if your msg exceeds 160 GSM-7 characters or 80 UTF-16 characters it will be send as more than one message with UDH.
In that case the mobile phone won't show message parts as they arrive. It will collect them in memory until the last one comes and then assembles them in the right order. For the end user this is just a message longer than usual and you don't have to write "1/3", "2/3", ... in the message.
Disclaimer: I work for a company that enables you to send and receive both multiple binary messages with user-specified headers (UDH) and/or standard long messages.
If you are not tied to Twilio try using SMSified. They automatically split the message for you, insure it is in the correct order, and add "1/2, 2/2..." to the end of the message. In other words you just send the complete message to their REST API, no matter the length, and they handle the rest. Since they also use a REST API you can continue to use Python.