I am using two instances of liferay, means two servers are running with a load balancer on it. Both the servers are pointing to a one common DB. Now the issue is when a announcement is created two emails are received, if we shutdown one of the servers then only one email is received, couldn't find out why this is happening. what i want is running both servers but only single email alert for every announcement.
Are the emails triggered instance wise nothing related to DB except the subscription.
May be there could be any property that we could set in portal-ext.properties of one of the servers, so that mail alerts from one server can be stopped.
Thanks.
Related
I have a basic question about mail servers. Usually any general server (not necessarily mail servers) handle all kinds of related requests i.e. both direction interaction with client (like sending and receiving msg to and from client) but in case of mail servers, there are 2 different servers -- one for outgoing messages called outgoing server following SMTP protocol and another for incoming messages called incoming server following POP3/IMAP protocol. Why so? . For that matter couldn't the 2 protocols be accommodated in one single protocol to handle both direction message flow. Also, typically are these 2 servers hosted on same machine in a general business?
Because the protocols are old. In the old Unix tradition, and ignoring UUCP for now:
SMTP came first, to transfer mail between sites, and mail was read locally on the server/network using a text mode client when logged in. There was no need to fetch mail, you used the 'mail' command, and it accessed your local mail spool (a file containing your mail, sitting on the file system, that the SMTP server appended to).
Later on, came the development that people wanted to read mail on their own hosts so a protocol was invented to serve that. The POP server would read that same spool file, and allow you to download all your messages to your intermittently connected client computer. SMTP was reused for sending mail because it already existed and was easily adapted for that purpose.
These days, there are usually three servers of note: SMTP submission server, SMTP transmission server, and IMAP. The submission server is where end users of the service submit their e-mail to be forwarded onto the final host, for example the Google server a Gmail user submits their email to (on port 465 or port 587, usually, with authentication). The transmission server is responsible for delivering and receiving email between sites (eg. when Yahoo and Gmail exchange mail for their customers with each other, on port 25). And IMAP is used by an end user to fetch their email.
These three services, on large sites, are generally served by separate servers on separate hosts. On very large services, like Gmail, they are separate pools of servers.
On a small business host, they were often just one machine.
There are newer and more integrated protocols. For example, both EAS and EWS have mail fetch and submission contained in the same protocol.
Personally, I regret that almost nobody uses UUCP anymore :)
The separation of shipping, management and collection of mail has a historical, philosophical and design basis.
This is in line with the spirit of the Unix world: "do one thing but do it right" and "make everything as simple as possible".
How complex the issue of e-mail is and how much technology it covers, read here:
https://en.wikipedia.org/wiki/Email
and then see the relevant RFCs in the footnotes for details.
It is difficult to implement a monolithic program that takes into account all the nuances of e-mail and at the same time
keeping it simple (Simple in SMTP). Such a monolith would be a nightmare to develop, maintain and administer,
and the post office has changed many times since the 1970s.
As for the second question, there is no reason to use the same physical machine, but there are also no contraindications other than the amount of resources available.
Our IP address recently got listed on UCEPROTECT-1 as a potential spam address, and we aren't able to figure out how to stop this. According to their website, UCEPROTECT-1 listing happens when: IP's get listed in Level 1 automatically if they either try to deliver e-mails to spamtraps or if they are involved in port scans or probes or any kind of attacks against our servers
Some research online suggests that the only way to ensure it doesn't happen again is to find out what is triggering these spam traps and plug them.
Any idea how we can go about looking for what is triggering these automatic listings? Any help would be appreciated!
Some background:
We use GSuite for our email servers, wix.com for our website, and namecheap.com for our DNS.
We'd originally paid to not be listed in the UCEPROTECT-2 and 3 listings but were automatically removed as soon as we got listed under UCEPROTECT-1.
I don't know how G-Suite works but in general check
logfiles of the outgoing e-mail servers for days with "strange" recipients patterns or for more e-mails than on other days
if your domain is listed on other blacklists, maybe that is giving you other hints
The problem is: if you are using the outgoing e-mail servers from Google and some of them are listed on UCEProtect (because other G-Suite customers are sending spam, mostly without knowing it cause they are hacked), you have little chance of fixing this yourselve. This is not really uncommon, me.com/icloud.com (17.58.63.0/24) is listed at UCEProtect right now too.
I have an ec2 micro instance running Centos on which I deploy my projects for testing purpose. Lately I developed a system which sends users email upon some events using sendmail. As I am the only one who use the system, the amount of emails sent per day is less than 50 and they are typically very simple emails.
After a few days I notice that the emails get delayed a lot after I issue send command, sometimes up to 15 minutes, and when they come, they come in batch (that is, several emails are delayed and then arrive at my inbox at one time). I understand there are reasons why we pay for email services like SES, but does sending email really take that much resources and why so?
Does your server have a fully-qualified domain name? Sendmail injects a delay when the sending host doesn't have a FQDN
To get one
first, in /etc/hostname, change your hostname from whatever to a FQDN like whatever.one-of-your-hosted-domain-names.com
then, in /etc/hosts, add a host entry like:
99.123.45.67 whatever.mysite.com
Reboot and try to send a mail to yourself again. Sendmail wil not delay at all.
I'm using SugarCRM CE version 6.5.8 and I have it installed on a Windows machine. I'm trying to use the feature of SugarCRM where you can assign inbound emails to cases automatically and then assign the cases to users in a round-robin way.
I've set up the scheduler correctly and also set up the emails. The system even processed a couple of mails and correctly created cases out of them. Then, all of a sudden, it stopped working. The scheduler pulls new mails for private mail addresses but not for group email addresses.
I have no idea where to look for the problem or what the cause might be. Anyone facing something similar?
It seems that any new send or receive ports that I create do not display any tracking even if I tick all the tracking boxes. I have an existing application and the receive port and orchestration tracking work, but the send port tracking doesn't.
On the same machine I also tried creating a new application. Created a send and a receive port and no tracking at all. I did the same thing on a fresh install of biztalk on another machine and I got tracking so I'm not crazy.
I've tried ...
ticking every box in tracking for the receive, orch, send ports.
creating a new host specifically for tracking
recreating the original host with a different name
sql service is running
reboot system
reboot host instances
restart biztalk services
nothing shows in event logs
all sql jobs ok except for 'monitor biztalk' which complains about 7 orphaned dta.
can't see anything in particular that stands out from mbv except for the above mentioned oraphaned dta.
In addition to Mike's answer:
You need to ensure that at least one of your hosts is enabled for tracking. In BizTalk Administrator, under Platform Settings, Hosts, Select the host, and enable tracking (the list of hosts also shows which host(s) are current tracking enabled).
You can also verify that the tracking SQL Agent job is running by looking directly at the database
select count(*) from BizTalkMsgBoxDb.dbo.Spool (NOLOCK)
select count(*) from BizTalkDTADb.dbo.Tracking_Parts1 (NOLOCK)
Basically, spool should be a fairly low number (< 10 000), and should come back to a static level after a spike in messages, unless your suspended orchs are growing.
And new messages should be copied across from the MessageBox to DtaDb.TrackingParts every minute, so Tracking_Parts1 should grow a few records every 60-120 seconds after processing new messages, although they will be eventually purged / archived in line with your tracking archiving / purge strategy.
In a Dev environment, the more tracking the merrier, as HAT (the orchestration debugger) will give you more information the more you track. However, in a PROD environment, you would typically want to minimize tracking to improve performance and reduce disk overhead. We just track one copy, viz 'before processing' on the receive and 'after processing' on the send ports to our partners, and nothing at all on internal Ports and Orchs. This allows us to provide sufficient evidence of data received and sent.
This post might help some people: http://learningcenter2.eworldtree.net:7090/Lists/Posts/Post.aspx?ID=78
For message tracking to work, among other factors, make sure that the "Message send and receive events" checkbox in the corresponding pipeline is enabled.
Please take a look at these two articles, What is Message Tracking? and Insight into BizTalk Server message tracking. The first article has an item of interest for you and I'll quote it below and the second should just solidify what you're trying to do.
The SQL Server Agent service must be running on all MessageBox databases. The TrackedMessages_Copy_ job makes message bodies available to tracking queries and WMI. To efficiently copy the message bodies, they remain in the MessageBox database and are periodically copied to the BizTalk Tracking (BizTalkDTADb) database by the TrackedMessages_Copy_ job. Having the SQL Server Agent service running is also a prerequisite for the archiving and purging process to work correctly.
Are you using a default pipeline? Have you checked the tracking check boxes on them? There is some bug where the pipeline tracking is disabled for default pipelines.
More info here:
http://blog.ibiz-solutions.se/integration/biztalk-global-pipeline-tracking-disabled-unexpectedly/
Please ensure that required tracking is enbled in the properties of the send pipeline used by your send port. If message body tracking is disabled on the send pipeline, nothing is tracked on the send port as well.