This article has 408 words.

How does okKoala send emails?

Three modules need to be distinguished, the analogy will be gastronomic:

Scheduler receives the order through the campaign creation mechanism. By selecting the target group, time of sending, template, etc. the administrator orders a given phishing campaign. At this stage, an initial validation takes place, which checks the permissions of the of the person who submits the need for the campaign. Hence: if the administrator schedules a campaign and then loses the permissions, the scheduled campaign will normally take place.

CRON is performed as late as possible, but even before the scheduled campaign. About 15 minutes before the scheduled launch, it starts by locking the campaign edit. It then recalculates the campaign order into a specific set of emails. Why? Because a request like “send to everyone in the HR group in a week” is tied to a particular group and for a week there may there will be some castling in the allocation of employees. Theoretically speaking, you can submit a campaign to a newly created group of employees, and only then assign specific addresses to it - however, this is living on the edge.

Sender is the only one that has the ability to send emails from all addresses - the rest of the okKoala system has no such mechanism. It selects a prepared queue of emails to send and starts iterating them. Every 3 minutes, for each sending account, the calculation of the queue and dispatch according to the set dispatch limit (usually 1/s). Sender does not see the current actual employee data, but what CRON has calculated. It follows that a change in employee data during/after dispatch will not affect the on the status of the dispatch. This runs from easier management of consistency, isolation of the data actually sent from the actual ones in the system (backdating, backward overwriting, etc.).

Summary of special accidents: