Rilato Autoresponder

$127.00 Version 1.1 · PHP + MariaDB

A complete mailing list and follow-up sequence system that runs on your own hosting. Write the sequence once and it keeps sending, to every new subscriber, on the schedule you set, for as long as the server is up.

You are paying monthly for a list you already own

The standard email service charges by how many people are on your list. Not by how many messages you send, not by how much work it does — by the size of an asset you built yourself. Your list grows, the bill grows, and you are renting access to your own contacts.

Then there is what happens when you stop paying, or they decide your business is not one they want. The list is exportable, usually. The sequences, the tags, the open history, the years of behaviour data that made the list worth something — those are not.

Stop paying monthly for subscribers you already have.

What it does

It is the classic follow-up autoresponder, rebuilt properly. Someone subscribes, confirms, and starts receiving your sequence: message one immediately, message two three days later, message three on day eight, for as long as the sequence runs. Meanwhile you can broadcast to the whole list whenever you want.

The structure follows the old Perl mailing-list scripts — register, broadcaster, sender, bounce handler — but everything is written from scratch in modern PHP, with prepared statements throughout, no eval anywhere, and an SMTP client with no dependencies. The schema is defined in PHP and installed by a web wizard, so there is no .sql file to import by hand.

What you get out of it

• No per-subscriber pricing, ever. Ten thousand subscribers cost the same as ten: what your hosting costs.
• The behaviour data stays yours. Opens, clicks, tags and history live in your database, queryable however you like.
• You will not be shut off. No account review, no sudden policy change about your industry.
• Deliverability handled properly — not as an afterthought. See below; this is where self-hosted email usually falls down, and it is the part that got the most work.

Lists and subscribers

• Multiple lists, each separately branded with its own from-name, from-address, redirect URLs and opt-in policy.
• Always double opt-in on public signups. Unconfirmed signups are deleted after 72 hours rather than lingering forever.
• First name, last name, IP and custom fields — define any field you want and it appears on the signup form, the manual-add form, and as an optional column in the admin.
• Copy-paste signup forms. The admin generates an HTML form styled by your own CSS, plus a zero-config iframe version.
• Subscribe by email. Each list can have its own inbox, so anything arriving there is unambiguously a request to join that list. Lists without one fall back to a shared mailbox routed by subject code or plus addressing.
• QR codes for any signup form or survey, for table cards, receipts and posters.

Sending

• Autoresponder sequences driven by a day offset from the moment a subscriber confirms. Sending is idempotent — a unique constraint on message and subscriber means overlapping cron runs cannot double-send.
• Broadcast campaigns queued to a whole list and sent in throttled batches.
• Multiple SMTP accounts with rotation: add as many as you like and pick which ones a broadcast rotates through, sending a random number through each before switching.
• Real concurrency. Configurable delay between sends and true multi-process sending via proc_open(), coordinated so no subscriber is ever emailed twice.
• Open and click tracking injected automatically into HTML mail.

Automation that reacts to behaviour

• Tags — labels that cut across lists, applied individually or in bulk, usable to narrow a broadcast.
• Triggers — act on what someone actually did. Opened a message whose subject matches a keyword, or clicked a link matching a URL: add them to another list, or just tag them.
• Conditional branching — any sequence message can depend on whether the subscriber opened or clicked an earlier one. If they opened A send B, otherwise send C.
• Dynamic content blocks — [[if tag:vip]]…[[else]]…[[endif]] inside any message, resolved fresh per subscriber at send time.
• Deep segmentation — saved, reusable groups combining several tag and custom-field conditions with ALL or ANY logic.
• Surveys with several question types, shareable by link or QR code, with response analytics.
• A/B tests on subject lines and content.

Deliverability and compliance

This is the part that decides whether self-hosted email is a good idea or a disaster, so it is worth reading even if you skip the rest.

• One-click unsubscribe, RFC 8058. Every message carries List-Unsubscribe and List-Unsubscribe-Post, which is what puts the native Unsubscribe button next to your name in Gmail and Outlook instead of making people hunt for a footer link. It is also required by Gmail's and Yahoo's bulk sender rules above roughly 5,000 messages a day.
• Bounce processing. A cron job scans an IMAP mailbox, classifies hard and soft bounces from DSN status codes, and automatically unsubscribes addresses after repeated hard bounces.
• Spam complaint (FBL) processing. A registered feedback-loop mailbox is scanned for ARF reports, and a complaint is treated more urgently than a bounce: that address is unsubscribed from every list and permanently blocked the moment the report arrives, so it can never be re-added through any channel.
• Inactive subscriber handling. Find confirmed subscribers who have not opened or clicked in N days and pause or remove them deliberately. A low engagement rate is itself a spam signal, even with no complaints. Pausing is reversible.
• DKIM signing and a suppression list, spam-word checking before you send, and GDPR tooling for data requests.

Running it without babysitting it

• Cron heartbeats. Every cron script reports when it finishes, and the settings page flags any that have gone quiet longer than expected — so a broken crontab line or a silent PHP error surfaces in a day instead of a month.
• Structured logs you can filter and search: PHP errors, uncaught exceptions, cron runs, mailbox connections, send outcomes. The flat log file at the project root keeps working too if you would rather tail -f it.
• Two-factor authentication on the admin.

System requirements

• PHP 8.3 or 8.4, with PDO, IMAP and OpenSSL.
• MariaDB or MySQL. Installed by the web wizard on first run.
• Cron access — the sequences, broadcasts, bounce and complaint processing all run from cron. Without it, nothing sends.
• An SMTP account to send through, and a mailbox for bounces.
• Control over your domain's DNS, for SPF, DKIM and DMARC records.