Postmaster

This page is for postmasters, abuse desks, blocklist operators, and anyone who received a message from an IP address we operate and wants to know who is behind it. Every IP address we send mail from answers on port 80 and redirects here, so if you followed the reverse DNS name of a sending IP, you are in the right place.

If you are dealing with something urgent, you do not need to read the rest of this page: write to [email protected] with the full headers of the message. It is a monitored mailbox, and a real person answers it.

1. Who operates these systems

Mumara LLC operates the mail servers behind these IP addresses. Mumara is an email delivery platform: businesses use our infrastructure to send newsletters, notifications, and transactional messages to their own recipients. Every message that leaves these IPs belongs to an identified customer account that authenticated to send it, and any single message can be traced back to that account from its headers.

The person responsible for mail sent from these systems, and the point of contact for anything on this page:

Company	Mumara LLC
Responsible person	Mohammad Wakeel
Abuse reports	[email protected]
Postmaster / technical	[email protected]
Postal address	708 3rd Avenue, New York, NY 10017, United States

2. Contact

Two mailboxes, both monitored by people rather than a ticket robot:

• [email protected] — spam complaints, abuse reports, requests to stop mail to an address, anything a recipient is unhappy about.
• [email protected] — delivery and technical matters: blocklistings, reputation resets, rate and connection behaviour toward your systems, feedback loop setup, authentication questions.

We aim to answer within one business day. Please include the full headers of at least one message — they identify the sending account immediately, where a forwarded body alone often cannot be traced at all.

3. What is sent from these IPs

Two kinds of mail leave these systems:

• Permission-based marketing mail — newsletters, announcements, and similar campaigns our customers send to people who asked to hear from them.
• Transactional mail — password resets, receipts, order updates, and account notifications, relayed through our SMTP service and API.

We do not operate an open relay: every connection is authenticated against a customer account, rate-limited, and logged. We do not sell, rent, or supply recipient lists, and unsolicited bulk email is a terminable breach of the contract every customer signs.

4. How recipients are collected

Our Acceptable Use Policy requires that customers mail only people who gave them explicit, verifiable consent — a signup, a purchase, an account, a form the recipient filled in knowing what they would receive. Specifically prohibited:

• purchased, rented, traded, or otherwise third-party lists;
• addresses harvested or scraped from websites, directories, or social networks;
• appended addresses — matching a name or phone number to an email address obtained elsewhere;
• role and abuse addresses mailed as marketing recipients.

Customers must be able to show where and when consent was given for any address they mail, and we ask for that evidence when a complaint suggests it does not exist. When it cannot be produced, sending stops.

5. Reporting abuse or spam

Send the message to [email protected], with full headers. If your mail client can "forward as attachment", that is the cleanest way to preserve them. Useful to include, if you have it:

• the sending IP address and the date and time (with time zone) of the delivery;
• the rejection or bounce text, if your system generated one;
• whether you are reporting on behalf of one mailbox or a whole domain or network.

What happens next: we identify the sending account from the headers, suppress the complaining address so it receives nothing further, review the account's consent records and complaint history, and act on the account — warning, throttling, suspension, or termination, depending on what we find. You do not need a Mumara account and there is nothing to sign up for; we will reply to you either way.

6. Stopping mail to an address

Every campaign carries an unsubscribe link in its footer and List-Unsubscribe headers, including one-click unsubscribe (RFC 8058) — so the "unsubscribe" button in Gmail, Outlook, Apple Mail, and Yahoo works, takes effect immediately, and needs no confirmation step or login.

If that link did not work, or mail kept arriving after you used it, that is a breach of our policy and we want to know. Send the message to [email protected] and we will suppress the address for that sender and look into why it was not honoured. Blocklist and mailbox operators: we will also suppress an entire domain on request from someone who administers it.

7. Complaints, bounces, unsubscribes

These are processed automatically, within minutes, and they are not advisory:

• Complaints — we are registered with the feedback loops of the major mailbox providers and process the reports they send. A complaint flags the recipient in the sending account so it receives no further mail, and counts against that account's complaint rate.
• Unsubscribes — honoured on receipt, both from the footer link and from one-click headers, and applied before the next send.
• Bounces — every customer sends with its own return path, so bounces come back to us and are parsed here. Addresses that hard-bounce stop being mailed.
• Rate thresholds — accounts whose complaint or bounce rates cross our thresholds are throttled or suspended automatically, before a receiver has to do it for us.

8. Technical configuration

What you can expect from a well-behaved sender, and what you will find if you check us:

Reverse DNS	Every sending IP has a PTR record, and that name resolves back to the same IP — forward-confirmed in both directions. Our PTR names sit under mumara.net.
This page	Served from every sending IP on port 80, which is how you arrived here. The redirect carries the IP you reached so we can answer about that machine specifically.
Authentication	Messages are DKIM-signed per sending domain, sending domains publish SPF, and we support DMARC alignment. Customer domains are verified before they can be used.
Transport security	Opportunistic TLS on outbound delivery.
Identity	Each customer sends from its own domains with its own return path, so one sender's behaviour is visible and attributable rather than blended into a pool.
Volume behaviour	New IPs and new senders are ramped, and per-IP reputation and rejection patterns are monitored continuously.

If you operate a receiving system and want us to change how we connect to you — concurrency, rate, retry behaviour, or a different contact for automated notices — write to [email protected] and we will set it up. We would rather you tell us than block us.

9. Blocklisting and reputation resets

If you have blocked one of our IP addresses or ranges, or you are reviewing one for a reset, write to [email protected] with:

• the IP address or range in question;
• the timeframe of the traffic you are looking at;
• the rejection text your systems returned, or sample headers, if you have them.

We will identify what was sent from that IP in that window, tell you what we found, and tell you what we did about it. Where the cause is a single account, we act on the account rather than asking you to accept the same traffic again. Mohammad Wakeel, named above, is the contact for review processes that require a named person.

10. Legal requests

Legal notices, subpoenas, and law-enforcement requests: send them to the postal address above, and copy [email protected] so the right people see them without waiting on the mail. Data protection questions — including requests about personal data one of our customers holds — are covered by our Privacy Policy, which explains where we act as processor and where you should approach the customer directly.