Linux_Agent
My feedback
6 results found
-
1016th ranked
-
480th ranked
An error occurred while saving the comment -
6th ranked
An error occurred while saving the comment I agree. The important distinction is that these messages should not simply be moved to the Spam folder after delivery. I would like AOL to offer an optional server-level “Reject/Bounce Sender” feature so users can choose specific persistent senders or entire domains that should be refused before they reach the mailbox.
This would be stronger than ordinary filtering while still allowing legitimate email to reach the account normally. It could be especially useful for persistent spam campaigns that keep changing sender addresses but continue using related domains.An error occurred while saving the comment I submitted a separate feature request asking AOL to add an optional server-level “Reject/Bounce Sender” rule for persistent spam, including sender- and domain-level rejection. This would let selected senders receive a genuine delivery failure while the AOL address remains active for everyone else. I hope AOL will consider this as an additional anti-spam option.
-
480th ranked
An error occurred while saving the comment AOL Mail Team,
Please investigate persistent unsolicited spam being delivered to AOL users from Alibaba Cloud / Aliyun infrastructure and take server-side enforcement action where appropriate.
I have documented repeated unsolicited spam campaigns originating from multiple Aliyun IP addresses, including examples in the 8.219.x.x network. The messages frequently rotate sender domains and addresses, so blocking individual senders or creating one domain filter at a time does not solve the underlying problem.
I have repeatedly reported the offending messages directly to Alibaba Cloud's abuse department and supplied full raw email headers. Their responses have largely been automated acknowledgments, while new spam continues to arrive from additional Aliyun-hosted IP addresses and domains.
Please consider:
• Investigating the Aliyun sending IPs, IP ranges, and customer resources generating repeated complaints from AOL users.
• Applying stronger AOL server-side reputation penalties, throttling, temporary blocks, or permanent blocks to infrastructure that demonstrates sustained abusive behavior.
• Correlating spam reports across AOL users so repeatedly reported infrastructure can be stopped upstream rather than requiring every AOL user to block each new sender individually.
• Providing users with an advanced option to block mail originating from a specific sending network/provider when there is persistent abuse.I am not asking AOL to indiscriminately block legitimate Alibaba Cloud customers. I am asking AOL to take enforcement action against Aliyun infrastructure that your telemetry and user spam reports confirm is repeatedly being used for unsolicited or abusive mail.
AOL already has visibility into sending IP addresses and server reputation that individual users do not. Please use that capability to stop persistent abusive infrastructure before these messages reach AOL customers.
Thank you.
An error occurred while saving the comment Please add a secure, permission-based integration/API that would let users authorize trusted AI assistants such as ChatGPT to manage specific AOL Mail tasks on their behalf, including blocking senders, deleting existing spam, creating domain filters, and reporting messages as spam. Access should be limited to actions the user explicitly approves and should never require sharing the AOL password with the assistant. This would greatly reduce repetitive manual spam-management work while keeping the user in control.
-
11th ranked
An error occurred while saving the comment Please add a “Block this entire domain” option directly to the Block Senders menu.
When a spammer repeatedly changes only the address before the @ while continuing to use the same domain, blocking individual senders becomes repetitive and ineffective.
AOL already exposes the sender domain in the message and raw-message information. Please allow users to select:
Block this entire domain
This should automatically block future messages from any address using that domain, without requiring users to manually create a separate filter.Ideally, AOL could also offer this option after a user repeatedly marks messages from the same domain as spam.
This would make spam management much faster, reduce redundant blocked-sender entries, and give users better control over persistent spam campaigns.
-
714th ranked
An error occurred while saving the comment Please increase AOL Mail’s current 500-filter limit, ideally to 1,000 or more, or provide a separate domain-blocking list that does not consume filter slots. Users dealing with persistent spam may need to block many changing senders and domains over time. Thank you for considering this improvement.
I would like to suggest stronger pre-delivery filtering for messages that already exhibit multiple independent signs of coordinated spam or spoofing.
I am not suggesting that every message with one failed SPF, DKIM, or DMARC result should automatically be rejected. Legitimate forwarding, mailing lists, and configuration mistakes can sometimes interfere with authentication.
Instead, I suggest using a layered pre-delivery rejection model in which several high-risk signals together can trigger rejection at the SMTP edge before the message is accepted into a user's mailbox at all.
Examples of signals that could be combined:
• SPF hard failure, DKIM failure/absence, or DMARC failure
• A sending IP or small IP range suddenly producing many similar messages
• Rapid rotation of unrelated visible From domains
• Nearly identical HTML layouts, wording, image placement, subjects, or campaign structure
• Multiple suspicious redirect or short-link URLs
• A sender/domain with no prior relationship to the recipient
• Poor or newly deteriorating IP/domain reputation
• Repeated user spam complaints tied to the same campaign fingerprint
A recent spam burst I encountered illustrates the problem. Multiple messages arrived within minutes of each other from the same small network range. The visible sender domains changed repeatedly, authentication frequently failed or was incomplete, and the messages used nearly identical photo/romance-style templates and redirect links.
The system correctly placed the messages in Spam, but by that point they had already been accepted into the mailbox.
My suggestion is:
1. Use campaign-level fingerprinting across messages, not just sender-address blocking.
2. When multiple strong indicators agree, reject the message during SMTP rather than depositing it into the Spam folder.
3. For uncertain cases, use temporary SMTP deferral/greylisting while additional reputation and URL checks are performed.
4. Safely inspect and expand redirect URLs before delivery, including URLs hosted on otherwise reputable services that may be abused as redirectors.
5. Escalate filtering automatically when a narrow IP range begins sending repeated, structurally similar spam using rotating domains.
6. Preserve the Spam folder primarily for genuinely uncertain messages rather than messages already classified with very high confidence as abusive.
The goal would not be to make SPF/DKIM/DMARC individually mandatory for every legitimate message. The goal would be to combine authentication, reputation, campaign fingerprints, URL analysis, and recipient history into a stronger pre-delivery decision.
If several independent signals all point to the same coordinated spam campaign, I believe the receiving provider should increasingly reject subsequent copies before they ever appear in users' Spam folders.
Thank you for considering stronger campaign-level and pre-delivery spam enforcement.