- 1 UOL Anti-Spam
- 1.1 Frequently Asked Questions
- 1.1.1 What are these email messages I get from uol.com.br after sending to a mailing list?
- 1.1.2 Why not remove the subscriber(s) that trigger these messages?
- 1.1.3 What can I do about these annoying messages?
- 1.1.4 Are these messages spam?
- 1.1.5 Why won't UOL fix their system?
- 1.1.6 What can I do to get this fixed?
- 1.2 Preparing Filters
- 1.1 Frequently Asked Questions
UOL, the owners of uol.com.br, use a very broken anti-spam system that tends to annoy a lot of mailing list users. Here are the answers to some common questions regarding this nuisance.
Frequently Asked Questions
What are these email messages I get from uol.com.br after sending to a mailing list?
uol.com.br uses a very broken method of anti-spam. Everytime someone sends an email message to one of their members, they send back a verification message, asking the original sender to click a link before they will allow the message through.
These messages are themselves a form of spam, and the resulting back-scatter of these messages is altogether bad for the Internet, the UOL member, and all of the UOL member's contacts. UOL is aware of the complaints against them, and they refuse to correct the issue, claiming that their members love the service.
Why not remove the subscriber(s) that trigger these messages?
We have been unable to determine which subscriber triggers these messages. The email reaches UOL through an alias, which we have been unable to figure out. The verification messages from UOL do not contain any information about the intended recipient. They only include the subject of the original message. This means that no addition to the body of the message or to the headers (except for the subject) can be used to track the subscriber. The only way to locate this person would be to send a message with a unique subject to each and every subscriber.
Why not send out such unique messages? There are a number of reasons why this hasn't been done.
- Somebody would have to write a tool to do this using the list of subscribers.
- The mailing list managers would have to find the return message and verify its contents, which might require reconfiguration of the lists in order to avoid automatic discarding. This could actually take quite a bit of effort, thanks to the size of the lists and assorted traffic they generate.
- Using the monthly password reminders would require a patch to the list software and might not work anyway, since the person may have disabled these messages.
- The offender can always subscribe again with another alias.
Eventually, such an effort might be undertaken. The real risk is that it might all be for nothing if the offender subscribes again with another alias. We cannot flood the list users with otherwise pointless messages on a regular basis, nor should we have to.
Several efforts have been made to contact the UOL recipient, but they have gone unanswered. UOL is unwilling to assist us with this issue.
Unfortunately, even if we locate and remove the offending account, they are likely to re-subscribe, perhaps using a different alias. If we were able to conclusively end this, we would. Unfortunately, without drastic measures, we cannot.
What can I do about these annoying messages?
Set up filters. If you have control of your mail server, have it reject all messages from the UOL domain. If you only have client filtering available to you, configure your mail client to drop all messages from that domain.
It is more effective to reject these messages as spam than to silently drop them. Rejecting the messages will at least show up statistically on the UOL servers, and they might eventually realize that a bunch of people are rejecting their messages because of their broken system. If you drop the message silently, then it appears to them that the message got through.
Note that you should never send a bounce message out after you have accepted a message. This results in back-scatter that is ultimately harmful to the Internet as a whole. Configure your server to reject messages as they come in, rather than sending bounce messages afterwards. This will nearly always allow legitimate senders to get legitimate errors, but will avoid sending bounce messages to forged addresses that shouldn't get an error or illegitimate senders that would disregard the message anyway.
Many modern mail servers can be configured to use delayed transactions, which give your mail server the opportunity to scan messages for spam or viruses before accepting the message for delivery. This will allow you to effective reject such messages from the sending server without the risk of creating back-scatter. If you manage a mail server, this is something you may want to look into.
Are these messages spam?
Under many definitions, yes. UOL doesn't see it that way, but these messages are:
- Unsolicited - They are automatic and unintended results of the original message.
- Bulk - They are sent out to any number of people as a result of mailing lists and aliases.
- Uncontrolled - No effort is made to protect senders from faulty messages, and requests for action are ignored.
- Pointless - They are self-defeating, in that senders do not wish to go through this process.
- Foolish - Thanks to forgery and back-scatter, these messages can do more harm than good, easily by factors of thousands.
- Offensive - The method by which these messages are handled makes them a nuisance, and they offend legitimate senders. This kind of interception is undesirable to email users.
Why won't UOL fix their system?
UOL doesn't care about the collateral damage. Their subscribers don't get much spam (in spite of all of the lost legitimate email). They think their system is good and don't see it the way everyone else does.
What can I do to get this fixed?
- Blacklist UOL, and tell them that you're doing it.
- Complain to UOL about the problem.
- If you know UOL users, tell them why what UOL does is wrong.
- NEVER obey the directions in one of these messages.
This section is to provide instructions for setting up filters to deal with this problem.
Sendmail and Postfix
Sendmail and Postfix allow very simple domain blacklisting through their
access files in
/etc/postfix/access, respectively. A simple entry that matches and rejects all uol.com.br mail might look like this:
uol.com.br REJECT uol.com.br blacklisted for broken anti-spam.
Note that you will have to rebuild the
access database for either MTA.
For Sendmail, Fedora includes a
Makefile in the
/etc/mail path, so the following should work:
make -C /etc/mail access.db
For Postfix, you will need to use the
These commands should work properly under the default configurations in Fedora. Your configuration may vary.
Exim has very flexible ACLs which allow you to perform extensive filtering. A simple entry which matches and rejects all uol.com.br mail might look like this:
deny sender_domains = uol.com.br message = UOL blacklisted for idiotic and abusive 'anti-spam' policies
Note that in general you should not apply blacklists like this to mail destined for your postmaster address -- people should be able to communicate with your postmaster in order to discuss any problems they have, and get their systems fixed. In the default Exim configuration shipped with Fedora, you should put the above ACL clause after the part in the RCPT ACL (acl_check_rcpt) which accepts mail to postmaster.
If you don't manage your own mail server, you can still configure your email client to drop the annoying messages without bothering you.
Following these directions will set up your Thunderbird 1.5 client to silently delete messages from uol.com.br.
- Click the 'Tools' menu.
- Click on 'Message Filters'.
- Click 'New...'.
- For 'Filter name', enter something like 'uol.com.br' - the exact name is up to you.
- Click the box that reads 'Subject' and select 'From' from the drop-down list.
- Leave the box reading 'contains' as-is.
- In the following text box, enter '@uol.com.br'
- Click the box that reads 'Move Message to' and select 'Delete Message' from the drop-down list.
- Click 'OK' and close the Message Filters dialog. You are done.
The author of this page, PatrickBarnes, has released this document to the public domain. You are free to copy, alter and redistribute it. This does not include the Fedora trademark, which should be removed from redistributed versions.
The author encourages you to spread the word about this broken anti-spam system and others of its kind, to bring attention to the problem and hopefully lead to its resolution.