Entries tagged with “local users” from Garbage In, Garbage Out

If you maintain an "aliases" file on gigo.com for one or more of your domains, please note the following changes are being made:

The new server to replace vette.gigo.com has arrived from ixSystems. So far, so good. I'm working on a base FreeBSD install on it now. I expect to put this thing live some time late August.

If you're a "local user" on gigo.com, and you're making use of php/mysql/perl/etc, you might want to take stock of what you depend on, and see what gotchas there will be when the latest versions of those tools are used.

POP/IMAP servers are being upgraded. Dovecot has had a 1.0 release out for a while now and no major reports of problems. pop3/imap servers will be bounced to upgrade the apps.
-jason

[This replaces a few earlier posts, as well as a message sent to local users mailboxes]

Several mail server changes this weekend.

SpamAssassin, our spam filter, has been upgraded. Lots of new rules added. 2000+ rules now being checked (at some cost, too - 0.6 to 0.8 CPU seconds for every 1 message). Due to the cost of such rules, we do lots of other things to slow things down before it reaches the spam filtering step.
A reminder, you can tweak spam filter scores at mail.gigo.com.

Greylisting. While this is not new, there is a slight behavior change. Previously, the first time a sender contacted a recipient from a distinct IP addres, we would tell them "try later". Legitimate servers do that, usually 10-20 minutes later. We're only introducing this delay for "new" connections. Reminder, if you don't like greylisting, send me email, and I'll put in a pattern to bypass your mail. (We have been greylisting for 2 years now..).

The actual change to the behavior is thus: If the mail goes to our primary receiver first, then to our backup mail receiver, we'll accept it on the spot. That means the mail application is in general following the rules. We'll reward this by not delaying it any further. (This may increase the spam some, for spam applications that actually follow the rules).

Secondary mail receiver: A second mail receiver is now running. This is running on the same host, and the purpose really is to act as a decoy to the spammers that go after secondary mail receivers. If we don't recognize the sender+recipient+host combination, we'll simply say "try later". Legitimate servers will retry the primary later. Hit and run spammers that try only back up mail receivers when found, will hopefully be decoyed.

Attachments: Spam includes trojans and virii. We are now blocking many types of 'executable' attachments. We are still allowing zip files, image files, and the like. Config files can be perused if you wish at pcre.jimsun.header_checks.txt and pcre.jimsun.body_checks.tx. Regretfully this can only be applied globally (or not) - a few of you who are whitelisted on spam filters is still having this filter applied.

Messages with such attachments will be refused. Legitimately sent mail by people you know with these attachments should still notify them (the sending mail server however is responsible for that).

ZIP files are still allowed. However, they are not 100% safe. Do you have antivirus software installed? Why not? Espcecially those of you running any version of Windows..

For people having "wierd" things with mail.gigo.com and imap, you might try instead mail2.gigo.com. mail.gigo.com has some settings to try and make things just like it was on the old server. mail2.gigo.com does not have that. (If you do switch servers, you should remove the account on your mail software entirely - then add a "new" account and use mail2.gigo.com for the imap server).

.. so if you're an SBC customer, using my mail server, you'll probably need to tell your mail client to use a special SMTP port. Please use port 26. You will still be required to authenticate with a username/password - that won't change.

Web mail now has a "Filters" command. SquirrelMail will let you manage server side filtering. Now, you can easily say "any mail that matches this, put it into this new folder..". You *should* do this if X-Spam-Status: says "Yes" (I'll try and make this happen automatically for the people I am converting - most everyone did not use procmail for much).

I will be converting most users on my box to Sieve scripts; a few power users on my system I'll leave with procmail. I'll contact you guys individually to see if you want to convert over to Sieve or not.

[top] [smtp auth] [my networks] [bounces] [whitelists and blacklists] [realtime blacklists] [dns resolution] [smtp greetings] [unauth pipelining] [greylisting] [dialup users] [isp sanity check] [Get off the filter]

All gigo.com mail is scrutinized at the SMTP level. We do not look at message contents (unless the end user specifically sets up content filters). gigo.com looks at the *envelope* of the delivery (much like how postal mail uses envelopes but the contents may be totally different of what was represented).

When looking at the envelope we look for several signs that the mail is less than genuine. Some of the common checks we use are listed below:

• Is the sender authenticated? If the sender has successfully logged in with SMTP AUTH (a way of doing logins over SMTP), then we will implicitly trust the mail. The other paranoia goes away. If you are a user that wants to send mail out via me, enable SMTP AUTH in your mail program, and life is much, much better. (Todo: How-to docs for common applications)
• Is the sender from one of the gigo.com networks? I do from time to time consider adding specific static IP's to the list of "my network", which also bypasses most checks and will allow you to relay, if it is appropriate.
• Is it a "bounce" message, but to several recipients? Quite simply, bounces never legimately do this.
• Is the sender or recipient in any of the gigo.com whitelists? Sometimes we pre-approve specific senders to send us mail from any location. Some recipients prefer we pre-approve all mail going to them, and leave any spam fighting (if any) left up to them. We're happy to comply, even if there is a twang of pity.
• Is the connecting host on any blacklists? We make use of several blacklists. If mail is rejected for any reason from those lists, the details will be in the refusal. Also in the refusal is who to contact (the postmaster, which is always whitelisted). As of the time of this writing, those RBL servers are: relays.ordb.org, sbl.spamhaus.org, proxies.relays.monkeys.com, opm.blitzed.org, dnsbl.njabl.org, blackholes.wirehub.net, list.dsbl.org.
• Sender's address, does it resolve? We look at the sender's address and make sure that there is a mail server on the internet that is publicly known to take mail for this address. If the domain is expired, or if the domain name is not configured right, or if there is a typo on the spelling of the domain name, the mail will be delayed (but not totally refused) by our server. If the problem is not corrected, the sender's ISP will ultimately give up trying.
• Sender's greeting, does it follow the specifications? Lots of spammer software doesn't. Sadly, neither does a lot of end-user software (using SMTP AUTH bypasses this rule!, see above..). If the greeting does not follow the spec, it will be rejected.
• Unauthorized pipelining If the sending computer sends commands before we've given them permission to, reject them. Reputable software doesn't do that.
• Greylisting or Tempfailing - the act of giving people who are new to you a temporary failure. Chances are, it is a drive-by spamming. In this case, we will reject *new* contacts for a period of time. http://projects.puremagic.com/greylisting/ describes greylisting; we do use a variation of what is described (with diferent delays).
• Recipient's address, is it our customer? We accept almost all mail that is to our customers, unless it looks to be patently and obviously bogus. If our heurestics are too aggressive, and your mail is being blocked to a gigo.com customer, send email to postmaster@gigo.com, noting the sender address, and approximate time tha the mail was sent. We will gladly make exceptions for anyone who can even read the bounce message since you are obviously genuine.
• Sender's internet address (not email address) - is it a dialup modem? If you are a customer of a large dialup server, we will recognize that you are a modem user. If you are a modem user, you should be sending your mail via your ISP's mail server. If you are trying to send it to us directly, you are 99.99% likely to be a spammer - and we block it until you send mail via your ISP's mail server instead. This is notably true for Earthlink, UUNET, etc customers. We are willing to make exceptions.
• Sender's internet address and email address, are they an appropriate match? An example of this is AOL mail. We will gladly take AOL mail. That isn't a problem. However... we do verify that it is coming from an AOL server. If it is not from an AOL server, we will refuse the mail. AOL members are only supposed to send mail via the AOL service. We have similiar rules for several ISP's that are commonly used as false addresses in spam sent from all around the world. To reitterate: We don't mind mail from AOL, etc. We just enforce that it truely came from the right ISP's mail server.

We have several other tricks up our sleeves as well, which are in our best interest to not publish.. But ultimately, we check only the envelope, so the privacy of the message is preserved. Users are responsible for their own content filtering, if any. Users do have the option of having SpamAssassin prescreen their mail. If you are one of my users, and want to enable SA, then go here.

On request, we can and will put a filter on a user's account so that they will have html, RTF, and attachments stripped entirely. If you are one of the gigo.com users who store mail locally at gigo, and would like this, mail postmaster@gigo.com with your request.

We'll be the first to say that our rules might accidentically refuse something that is legitimate. We do our best to avoid that. However, the dynamics of the internet do change. Sites that used to be blocked change ownership and purpose; internet addresses get owned by new people; new sites that appear to be mail relays are legimitate (blue mountain is an example).

If you had a message you sent get refused by gigo.com, and the message refered you to this page, we will be more than happy to make an exception for you. What we need to know is who you are, who you were sending to, and approximately when you sent it (down to the nearest day is fine). We'll verify the logs and figure out the best way to change our rules, whether it is a one-off case or a complete policy change.

If you are a gigo.com user, and you do not want any filtering done at all at this level, also send email. We can easily not filter mail for anyone who asks. If you want this to happen, we suggest a technique called whitelisting to keep your main inbox spam-free.

Whitelisting is the act of looking for the mail you *expect* to get and sending it to your main mailbox - and defering all other mail to a different mailbox so that it doesn't interrupt you with the same immediacy as your inbox. A sample script would be find-email-in-sentmail. This script is available for download but no tech support for it is available.

Requests should go to postmaster@gigo.com.
Requests to the postmaster are never filtered by gigo.com. However, it may take up to a day to respond, depending on circumstances. gigo.com is a hobby system providing free services to various individuals and hobby groups; it provides no income. As such the postmaster has a paying job that has to come first.