« June 2004 | Main | August 2004 »
Simple solution to the issue I was talking about earlier. Disabled outgoing scanning of SMTP mail and re-enabled TLS. No more mail is moved to sentitems which has not been sent via SMTP unlike the previous anti-virus software I was using was doing.
Running php 4.3.8 with the hardened-php patch 0.2.2 and ZendOptimizer 2.5.3 one gets the following:
Not very nice :/
Update:
It turns out that Zend Optimizer directly access the LLists instead of using the Zend Engine API. Busy waiting for feedback from Zend as to when they are going to fix this. Dmitry Stogov who works for Zend wrote Turck MMCache prior to joining Zend. Turck MMCache works when Zend Optimizer does not. IONCube is reported to also work.
PING www.saix.net (196.25.1.200): 56 data bytes
64 bytes from 196.25.1.200: icmp_seq=7 ttl=242 time=33079.287 ms
64 bytes from 196.25.1.200: icmp_seq=15 ttl=242 time=35420.450 ms
64 bytes from 196.25.1.200: icmp_seq=16 ttl=242 time=35814.133 ms
64 bytes from 196.25.1.200: icmp_seq=23 ttl=242 time=38676.151 ms
64 bytes from 196.25.1.200: icmp_seq=38 ttl=242 time=43415.460 ms
64 bytes from 196.25.1.200: icmp_seq=39 ttl=242 time=43708.732 ms
64 bytes from 196.25.1.200: icmp_seq=43 ttl=242 time=44843.092 ms
64 bytes from 196.25.1.200: icmp_seq=50 ttl=242 time=44320.490 ms
64 bytes from 196.25.1.200: icmp_seq=56 ttl=242 time=44848.026 ms
64 bytes from 196.25.1.200: icmp_seq=66 ttl=242 time=44604.587 ms
64 bytes from 196.25.1.200: icmp_seq=70 ttl=242 time=45431.179 ms
64 bytes from 196.25.1.200: icmp_seq=75 ttl=242 time=44682.764 ms
64 bytes from 196.25.1.200: icmp_seq=80 ttl=242 time=44235.269 ms
64 bytes from 196.25.1.200: icmp_seq=93 ttl=242 time=42992.421 ms
64 bytes from 196.25.1.200: icmp_seq=96 ttl=242 time=41787.554 ms
64 bytes from 196.25.1.200: icmp_seq=110 ttl=242 time=40343.490 ms
64 bytes from 196.25.1.200: icmp_seq=121 ttl=242 time=37508.918 ms
64 bytes from 196.25.1.200: icmp_seq=150 ttl=242 time=28525.819 ms
64 bytes from 196.25.1.200: icmp_seq=151 ttl=242 time=28004.440 ms
64 bytes from 196.25.1.200: icmp_seq=159 ttl=242 time=26036.399 ms
64 bytes from 196.25.1.200: icmp_seq=162 ttl=242 time=25197.906 ms
64 bytes from 196.25.1.200: icmp_seq=164 ttl=242 time=25355.435 ms
64 bytes from 196.25.1.200: icmp_seq=187 ttl=242 time=18765.632 ms
64 bytes from 196.25.1.200: icmp_seq=194 ttl=242 time=17100.235 ms
64 bytes from 196.25.1.200: icmp_seq=201 ttl=242 time=16379.506 ms
64 bytes from 196.25.1.200: icmp_seq=203 ttl=242 time=16041.146 ms
64 bytes from 196.25.1.200: icmp_seq=204 ttl=242 time=15780.467 ms
64 bytes from 196.25.1.200: icmp_seq=207 ttl=242 time=15319.449 ms
64 bytes from 196.25.1.200: icmp_seq=209 ttl=242 time=15178.826 ms
64 bytes from 196.25.1.200: icmp_seq=212 ttl=242 time=13225.197 ms
64 bytes from 196.25.1.200: icmp_seq=213 ttl=242 time=12468.821 ms
64 bytes from 196.25.1.200: icmp_seq=221 ttl=242 time=7500.034 ms
64 bytes from 196.25.1.200: icmp_seq=223 ttl=242 time=6518.530 ms
64 bytes from 196.25.1.200: icmp_seq=224 ttl=242 time=5744.437 ms
64 bytes from 196.25.1.200: icmp_seq=225 ttl=242 time=5543.010 ms
64 bytes from 196.25.1.200: icmp_seq=230 ttl=242 time=5273.073 ms
64 bytes from 196.25.1.200: icmp_seq=233 ttl=242 time=4790.298 ms
64 bytes from 196.25.1.200: icmp_seq=234 ttl=242 time=5080.640 ms
64 bytes from 196.25.1.200: icmp_seq=235 ttl=242 time=5161.465 ms
64 bytes from 196.25.1.200: icmp_seq=237 ttl=242 time=5155.991 ms
64 bytes from 196.25.1.200: icmp_seq=238 ttl=242 time=5530.894 ms
64 bytes from 196.25.1.200: icmp_seq=240 ttl=242 time=6077.924 ms
^C
--- www.saix.net ping statistics ---
248 packets transmitted, 42 packets received, 83% packet loss
round-trip min/avg/max/stddev = 4790.298/24796.847/45431.179/15312.784 ms
Typical SAIX performance over the weekend which happens as regular as clockwork. *sigh* I wish Hellkom would get their act together and sort out their routing and connectivity issues and get us some speed and a more reliable ADSL service.
I've picked up a weird case of MyDNS running away and not resolving queries on a FreeBSD server. It works well for a couple of hours and then requires a svc -k /service/mydns to kill it and svscan to restart it again automatically.
Quite annoying as my c coding skills are non existant seeing that I don't use c much any more, and bind is buggy.
IOL's advertising a position in their Cape Town office, which I would have been extremely interested in a few months ago while working in "hell". Seeing that I'm no longer associated with "hell" or the people there, and am happily doing my own thing currently the particular job still looks interesting enough.
The position is for a Senior/Lead Developer within their Cape Town offices.
The successful candidate will form part of a small team reporting to the Technical Manager. This team develops and maintain the technical solutions for IOL, including the IOL website, and the Independent Newspaper websites.
The ideal candidate will have:
Email your CV to techjobs AT iol DOT co DOT za. No telephone enquiries will be accepted.
Yes thanks to the various people who've been pointing to me that I should look into this job.
Yesterday I noticed when I was chatting to a client that told me that he did not receive a email which I had sent him earlier during the day, and I checked my sent items and noticed that the email in question was in my sent items.
Running exigrep through the mailserver logs I noticed that infact it had not been delivered. The anti-virus software which I use seems to have issues with using Authenticated SMTP for outgoing messages when you are sending more than four messages in a sitting.
Today, two seperate users asked on the php internals mailing list what does BFN and MFH stand for.
BFN stands for 'Bug Fixing News'. This is essentially when someone fixes a bug in php. Normally this relates to a bug filed on the PHP bugs website.
MFH stands for 'Merged From HEAD'. HEAD is the main development branch and when features / bug fixes get applied or merged to other branches it's called MFH.
The shock and horror of Alex's changes to the php4 port essentially now makes it mandatory if you used to build php4 (cli and apache module) with the various extensions built in, you now have to manually compile it yourself, seeing that php4 requires php4-extensions to have extensions you used to compile in added, and then your php.ini is polluted with unnecessary lines:
su-2.05b# grep extension php.ini extension=bcmath.so extension=bz2.so extension=calendar.so extension=crack.so extension=ctype.so extension=curl.so ...
It is really silliness if you ask me to change a ports default behaviour that has been in place for years, just because you feel like it.
SAIX's International Bandwidth is up the creek again.
When you start seeing things like 64 bytes from *snip*: icmp_seq=122 ttl=49 time=10034.261 ms you know SAIX's International routing is screwed yet again. Since last night latency with the boxes in the states are bad. Maybe it's about time Hellkom actually fix their SAIX network routing issues.
--- *snip*.co.za ping statistics --- 245 packets transmitted, 151 packets received, 38% packet loss round-trip min/avg/max/stddev = 446.626/5822.911/10034.261/2087.363 ms
In PHP we have some weirdly named things. For example there is Paamayim Nekudotayim which at first looks like an extremely weird choice for calling a double colon. At the time of writing Zend Engine 0.5 Andi and Zeev decided to call the double colon the Paamayim Nekudotayim and the name has never changed. Paamayim Nekudotayim actually means double colon in Hebrew.
Just imagine if when I code if I named everything in Afrikaans we might end up with things variables and functions like $_naam, $_tyd etc. A scarey thought, although I prefer coding with names in English as it makes it alot easier for others to read variable names, etc. and normally English is the bulk of people's second language if not first.
Maybe it's just me, but I don't speak Hebrew and just imagine I have to maintain a codebase where all the variables are in another language.
The shock and horror of getting a codebase where all the variables were named after characters and places in Spiderman was bad enough. I've also seen code where they are named after shows like Barney and Flintstone Characters. How do you determine what $_barney or $_fred or $_wilma contain without reading through the source code?
I talked a little about my Zend Optimizer Download Script which currently just downloads the latest version of Zend Optimizer from Zend Technologies website.
I've been thinking about adding some code to basically make it extract and install Zend Optimizer in the normal way I've been manually installing Zend Optimizer for the past couple of years.
I've used Archive_Tar previously for my Horde Webmail Solution installation via command line which works well except for the fact you still have to manually configure certain bits and pieces of the Horde suite.
One of the things which I like about doing open source coding is that we have the ability to distribute patches created using diff and then apply the patches to our source trees, hence we tend to forget about the times where we used to distribute our pascal or even worse basic code by zipping the entire source directory prior to sending the code off.
Lets look a little at the example of where I upgraded Horde Chora to version 1.2.2 from Chora version 1.2.1.
It was really easy to use the patch instead of downloading the entire tarball of Chora and then having to extract the files, rename all the files in the config directory, etc. etc.
I needed to get the patchfile for Chora to do the conversion from Chora version 1.2.1 to 1.2.2 and I used wget to retrieve the file.
root@*snip*:~# wget ftp://ftp.horde.org/pub/chora/patches/patch-chora-1.2.1-1.2.2.gz
--00:18:21-- ftp://ftp.horde.org/pub/chora/patches/patch-chora-1.2.1-1.2.2.gz
=> `patch-chora-1.2.1-1.2.2.gz'
Resolving ftp.horde.org... done.
Connecting to ftp.horde.org[199.175.137.150]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /pub/chora/patches ... done.
==> PASV ... done. ==> RETR patch-chora-1.2.1-1.2.2.gz ... done.
Length: 3,135 (unauthoritative)
100%[====================================>] 3,135 40.82K/s ETA 00:00
00:18:22 (40.82 KB/s) - `patch-chora-1.2.1-1.2.2.gz' saved [3135]
I first renamed my old version of Chora's directory to the version I was planning on patching upto.
root@*snip*:*snip*/horde# mv chora-1.2.1 chora-1.2.2
I then uncompressed the patch file, prior to running the patch command and passing on the filename to patch.
root@*snip*:*snip*/horde# gzcat ~jacques/patch-chora-1.2.1-1.2.2.gz > patch-chora-1.2.1-1.2.2 root@*snip*:*snip*/horde# patch < patch-chora-1.2.1-1.2.2 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/annotate.php chora-1.2.2/annotate.php |--- chora-1.2.1/annotate.php 2003-01-03 13:48:49.000000000 +0100 |+++ chora-1.2.2/annotate.php 2004-03-26 23:43:22.000000000 +0100 -------------------------- Patching file chora-1.2.2/annotate.php using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/co.php chora-1.2.2/co.php |--- chora-1.2.1/co.php 2003-01-03 13:48:49.000000000 +0100 |+++ chora-1.2.2/co.php 2004-03-26 23:43:22.000000000 +0100 -------------------------- Patching file chora-1.2.2/co.php using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/cvs.php chora-1.2.2/cvs.php |--- chora-1.2.1/cvs.php 2003-01-03 13:48:48.000000000 +0100 |+++ chora-1.2.2/cvs.php 2004-03-26 23:43:22.000000000 +0100 -------------------------- Patching file chora-1.2.2/cvs.php using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/diff.php chora-1.2.2/diff.php |--- chora-1.2.1/diff.php 2003-01-03 13:48:48.000000000 +0100 |+++ chora-1.2.2/diff.php 2004-06-12 16:06:20.000000000 +0200 -------------------------- Patching file chora-1.2.2/diff.php using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 23. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/docs/CHANGES chora-1.2.2/docs/CHANGES |--- chora-1.2.1/docs/CHANGES 2004-03-09 00:24:29.000000000 +0100 |+++ chora-1.2.2/docs/CHANGES 2004-06-12 23:25:52.000000000 +0200 -------------------------- Patching file chora-1.2.2/docs/CHANGES using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/docs/RELEASE_NOTES chora-1.2.2/docs/RELEASE_NOTES |--- chora-1.2.1/docs/RELEASE_NOTES 2004-03-14 13:03:53.000000000 +0100 |+++ chora-1.2.2/docs/RELEASE_NOTES 2004-06-12 23:29:50.000000000 +0200 -------------------------- Patching file chora-1.2.2/docs/RELEASE_NOTES using Plan A... Hunk #1 succeeded at 12. Hunk #2 succeeded at 25. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/history.php chora-1.2.2/history.php |--- chora-1.2.1/history.php 2003-01-03 13:48:49.000000000 +0100 |+++ chora-1.2.2/history.php 2004-03-26 23:43:22.000000000 +0100 -------------------------- Patching file chora-1.2.2/history.php using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/index.php chora-1.2.2/index.php |--- chora-1.2.1/index.php 2003-01-03 13:48:50.000000000 +0100 |+++ chora-1.2.2/index.php 2004-03-26 23:43:22.000000000 +0100 -------------------------- Patching file index.php using Plan A... Hunk #1 failed at 1. 1 out of 1 hunks failed--saving rejects to index.php.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/lib/CVSLib/Annotate.php chora-1.2.2/lib/CVSLib/Annotate.php |--- chora-1.2.1/lib/CVSLib/Annotate.php 2002-12-28 19:53:05.000000000 +0100 |+++ chora-1.2.2/lib/CVSLib/Annotate.php 2004-05-17 11:15:41.000000000 +0200 -------------------------- Patching file chora-1.2.2/lib/CVSLib/Annotate.php using Plan A... Hunk #1 succeeded at 4. Hunk #2 succeeded at 93. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/lib/CVSLib/Diff.php chora-1.2.2/lib/CVSLib/Diff.php |--- chora-1.2.1/lib/CVSLib/Diff.php 2002-12-28 19:54:02.000000000 +0100 |+++ chora-1.2.2/lib/CVSLib/Diff.php 2004-06-12 16:06:20.000000000 +0200 -------------------------- Patching file chora-1.2.2/lib/CVSLib/Diff.php using Plan A... Hunk #1 succeeded at 7. Hunk #2 succeeded at 56. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/lib/CVSLib/Directory.php chora-1.2.2/lib/CVSLib/Directory.php |--- chora-1.2.1/lib/CVSLib/Directory.php 2003-02-14 11:55:58.000000000 +0100 |+++ chora-1.2.2/lib/CVSLib/Directory.php 2004-04-15 21:24:12.000000000 +0200 -------------------------- Patching file chora-1.2.2/lib/CVSLib/Directory.php using Plan A... Hunk #1 succeeded at 7. Hunk #2 succeeded at 93. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/lib/version.php chora-1.2.2/lib/version.php |--- chora-1.2.1/lib/version.php 2004-03-14 13:15:17.000000000 +0100 |+++ chora-1.2.2/lib/version.php 2004-06-12 23:30:26.000000000 +0200 -------------------------- Patching file chora-1.2.2/lib/version.php using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Binärdateien chora-1.2.1/locale/es_ES/LC_MESSAGES/chora.mo and chora-1.2.2/locale/es_ES/LC_MESSAGES/chora.mo sind verschieden. |diff -uNr chora-1.2.1/menu.php chora-1.2.2/menu.php |--- chora-1.2.1/menu.php 2003-01-03 13:48:48.000000000 +0100 |+++ chora-1.2.2/menu.php 2004-03-26 23:43:22.000000000 +0100 -------------------------- Patching file menu.php using Plan A... Hunk #1 failed at 2. 1 out of 1 hunks failed--saving rejects to menu.php.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/prefs.php chora-1.2.2/prefs.php |--- chora-1.2.1/prefs.php 2003-01-03 13:48:49.000000000 +0100 |+++ chora-1.2.2/prefs.php 2004-03-26 23:43:22.000000000 +0100 -------------------------- Patching file prefs.php using Plan A... Hunk #1 failed at 2. 1 out of 1 hunks failed--saving rejects to prefs.php.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/status.php chora-1.2.2/status.php |--- chora-1.2.1/status.php 2003-01-03 13:48:50.000000000 +0100 |+++ chora-1.2.2/status.php 2004-03-26 23:43:22.000000000 +0100 -------------------------- Patching file status.php using Plan A... Hunk #1 failed at 1. 1 out of 1 hunks failed--saving rejects to status.php.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uNr chora-1.2.1/templates/common-header.inc chora-1.2.2/templates/common-header.inc |--- chora-1.2.1/templates/common-header.inc 2002-09-25 01:42:14.000000000 +0200 |+++ chora-1.2.2/templates/common-header.inc 2004-03-26 23:43:23.000000000 +0100 -------------------------- Patching file chora-1.2.2/templates/common-header.inc using Plan A... Hunk #1 succeeded at 5. done
All I had to now do was fix my symlink for Chora to point to the correct place so that the web interface of Chora can work the way I was expecting.
root@*snip*:*snip*/horde# rm chora root@*snip*:*snip*/horde# ln -s chora-1.2.2 chora
Automating tarball collection comes in quite handy as I hate having to login download find link copy paste, etc. etc. too time consuming.
MySQL are moving in the right direction with their FLOSS license changes. The latest version of the FLOSS exception has apparently made it's rounds of review by the community as well as the MySQL lawyers and the MySQL team.
The FLOSS Exception is an exception to the terms and conditions of the GPL licensing for the MySQL clients that allows for greater compatibility between the GPL and other common Free Software/Open source licenses.
There are some issues which needs to be addressed with their current licensing policies.
I recently was talking about looking into using Gmail as a backup system, and so far it works well using a script from Ilia.
Congratulations Six Apart on your acquisition of Ublog.
I'm sure Ben and Mena are thrilled at aquiring one of thier partners.
Now the question is can someone at Six Apart add DNS entries for MX records so that my incoming mail servers can accept mail from your @typekey.com mail addresses and that I can stop receiving mail like:
2004-07-03 14:41:31 H=(corp1.sixapart.com) [66.151.149.25] F=
2004-07-03 15:28:53 H=(corp1.sixapart.com) [66.151.149.25] sender verify defer for
2004-07-03 15:28:53 H=(corp1.sixapart.com) [66.151.149.25] F=
...
2004-07-13 16:55:38 H=(corp1.sje.sixapart.com) [66.151.149.25] sender verify defer for
2004-07-13 16:55:38 H=(corp1.sje.sixapart.com) [66.151.149.25] F=
2004-07-13 16:56:28 H=(corp1.sje.sixapart.com) [66.151.149.25] sender verify defer for
2004-07-13 16:56:28 H=(corp1.sje.sixapart.com) [66.151.149.25] F=
2004-07-13 17:49:31 H=(corp1.sje.sixapart.com) [66.151.149.25] sender verify defer for
It would be appreciated as Six Apart are known for their web standards usage, now why can technical people do the right thing and adhere to the normal standards. Also you guys might want to add SPF records while you are at it as well.
I've recently had the opportunity to obtain a Gmail account (
I'm going to start using some code (text version) of Ilia's to store stuff on gmail as a backup mechanisim. I'm thinking of PGP encrypting the files prior to sending them off to Gmail for storage. The nice thing is that Gmail provides one with 1Gig of storage space.
Following up on a previous post about South African Identity Number Validation the gender is specified by the 7th number in the id number.
For females they have a 0 and for males it is 5. For people who have gender changes they keep their original identity number according to information from Home Affairs.
More about this later.
I've been noticing something interesting with regards to the Google and Yahoo! webpage cache systems.
With google I can query and page in the cache, yet with Yahoo! I cannot. Jeremy do you have any suggestions?
It is none the less useful at getting post data from the site and the time of the post etc. etc. esp. after the Hetzner incident, my blog's content is slowly coming back online.
I've started using PHPDOC tags a few months back and never really did get round to generating documenation for various software codebases which I maintain.
I've started to generate some documentation for complex applications which I maintain and haven't maintained / coded on in ages, it makes things quicker to coding rather than reading code.
After the saga with Heztner, I've re-rolled the SMS::Clicaktell 0.4 tarball again and it's available online for downloading. Apologies for any inconvienced caused by the tarballs not being available.
PHP version 5.0.0 has finally been released after a process of more than a year of waiting and a couple of release candidates and release candidates of release candidates, the PHP Team have released PHP 5 to the public!
Some of the key features of PHP 5 include:
Update: It looks like the bug reports are coming in like the sleuth gates have been opened. Here is a serious bug: HTTP authentication is broken. We should be on the lookout for a patch level 1 or version 5.0.1 to be released in the next couple of days.
Google's page rank seems to be dead in the water still. One site where I'm involved in their development and a tiny bit of their search engine optimisation strategy seem to be seeing strange results when focusing on key word targeting.
According to Craig Silverstein a.k.a their Chief Janitor, said the following:
"The point of view that PageRank is dead is kind of a very static view of the world. It will always continue to be a part of our ranking scheme but, over time, as we develop new ideas on how to do ranking, as we tweak existing ideas, as we think about new ways to have them play together--the role of any one of the techniques that we use will obviously change."
I was hoping that Hetzner would have my files but they've deleted the contents of the HDD and I don't have my blog files, various other files relating to a few sites that were hosted on that particular drive, backup files for some software I've written, tarballs, etc. etc.
Anyway the blog is backup minus all my content. Hetzner you okes suck. :/ It's always nice to know that you guys don't do backups either.
I'll be remaking the tarball for SMS_Clickatell version 0.4 when I have time.
[Update:]
Disclaimer: I hereby give notice that I am merely exercising my right to freedom of speech and freedom of expression, that the above is my opinion and that I am protected by the constitution from any legal action that may occur as a direct or indirect result of my opinion. This constitutes an opinion on the current status quo and not an attack on a person/s or company.
Also I've found a tarball of SMS_Clickatell 0.3 which is online.
Anyway busy importing blog entries I'm gathering from Yahoo! Cache and Google Cache.
The SPF Addoption Roll which generates the graph you can see here shows a couple of interesting facts about sites that have submitted their domains which contain SPF records (dns TXT records which look something like the following:
Which basically says something like SAIX's SMTP servers on SAIX's Cape Town Belville Services LAN, UUnet's smtp.uunet.co.za and three IP's on our San Jose box can send from @ataris.co.za and in the interim allow softfail mode. We are migrating as many users over to using authenticated SMTP so that we can start flagging domains as -all and only allow relaying via specified SMTP servers on our network.
I've changed various aspects of my SPAM filtering capabilities on the mailserver to start using SPF which rejects forged emails from @freebsd.org for example at SMTP time. Also I've started requiring that the mailhubs start using SMTP callouts to verify sender email addresses. This also helps get rid of excess SPAM prior to Spam Assassin which is resource intensive from having to handle the mail. We will see how things shape up with the changes.
