Frog's Technical Page

Frog/Frog2's History


Trends for changes

I wanted to keep my operations as simple as possible, for reasons exposed in my Introduction.
On the other hand, there was a pressure from real life environment which pushed for slight modifications.
In short make FrogRemailer able to survive a few unpleasant events, like:
---a provider kicking you out
---connexion dropouts
---failures while operator is abroad
I also found out that Reliable had a hard time to handle connexions and mail itself: it is using .ocx which have their own weaknesses.
By design, Reliable is sequencing the reception, processing and sending processes instead of multitheading them: it is saturating one resource after the other (network IN, processor, network OUT) instead of trying to saturate them all simultaneously. Hence the trend to use specialized tools for receiving and sending mail, and interfacing them with Reliable.


Initial configuration: Basic

FrogRemailer started bearing an address from a free POP provider.
I had tested Reliable while it was under development, using a dial-up line and some free POP account.
One year later, I got a cable link and I performed a few 'power tests':
---my initial POP was unable to sustain the load (too slow)
---the POP supplied by my ISP was 10Mb, far too small, and I did not want to use it anyways
---I shopped for a bigger and faster box and I found a 20Mb free, fast box.
On the other end, my ISP's SMTP was delivering properly.
That is how I got public, 1999/10/30, with native Reliable and 3rd party, carefully-tested POP and SMTP.
Basic Sending and Basic Receiving
That was the Frog@mageos.com era, and it lasted until December 1999.


Slapped two times: decision to use a forwarder

FrogRemailer got some popularity.
But I found out my connection to be unstable:
I had 2-3 hours dropouts, and my mailbox started filling, and I started worrying for the mail.
But I also found that my POP3 had problems of its own:
From time to time it would be unreachable, and go on filling, and I started worrying for the mail.
Ultimately, the POP server would not delete messages after I read them, provider's technical staff was unreachavle and mailbox exploded.
I declared Frog@mageos.com dead, and resurrected it as Frog@free.fr.
But, thanks to complaints from French 'friends', that new POP3 provider kicked me out days later, and I made the decision I did not want to ever depend on a POP3 provider any more.
That is how I started looking for a decent forwarder, it would somehow hide my POP3 from remailer-haters, and allow me to remotely change POP3 within minutes in case anything unpleasant happened.
I chose Bigfoot, the address for Frog became FrogRemailer@bigfoot.com.
Basic Sending and Basic Receiving, with a Forwarder
became the organisation which lasted until Summer 1999 shutdown.
It looked stable to users, but behind the scenes I experimented with various POP providers.
In the end, I kept only 3 free POP providers (1Gb, 50Mb, 50Mb), 5 boxes at each, under different nicks.


The Azerty Experiment

Frog was working smoothly, I was regularly changing my POP3 boxes behind Bigfoot.
But I had noticed that Reliable would sometimes choke under some conditions. Also, it was slow at downloading from POP3, an downloading operations would not overlap with Processing operations.
I started Azerty to experiment that:
Basic Sending and Receiving with Pegasus.
(It needed a tiny extra VB program to handle the asynchronicity between Pegasus and Reliable.
(And MD5 detection + message count could be handled there too.)
Pegasus would be faster than Reliable by a 1:5 or 1:10 ratio, receive and process operations overlapped, it was a succes whose lessons would be used later.
In addition, Pegasus' MultiPOP function started feeding applications like Thesaurus..


The new Frog

The lessons from the Azerty experiment were used at Autumn 2000, with the new season.
But I used the "distribution" function instead of mere 'forwarding', for additional reliability in case my favorite POP3 provider gets down.
Actually, I was so happy with the way Pegasus and Reliable overlapped, and how faster Pegasus was at receiving than Reliable, that I decided to do the same thing at the other end: run my own MTA so that process would overlap sending.
I chose Mercury/32, the Mercury/C module so that I would use my ISP's SMTP as 'smart host'.
Hence the configuration in Autumn 2000:
Sending with SMTP + smart host and Receiving, Frog Final.


Wanadoo's miseries

Wanadoo (my ISP) is the biggest in France: looks serious, huh?
Unfortunately, it is not up to the near-monopoly it has on ADSL: news server has been down for 4 weeks, POP is shaky....
I found out that their SMTP server, the one I was using as 'smart host' to my Mercury/C, was quietly losing thousands of mails:
--it would not found the DNS for the receiver, because of bad DNS servers at Wanadoo
--it would send back a bounce, with the message body truncated
>>>>it was not possible to recycle the bounces and resend: mail was lost.
After contemplating changing ISP for a more competent one, I decided to install Mercury/E, the end-to-end version of Mercury, and it worked.
Hence the configuration I had to switch to very rapidly:
Sending with SMTP End-To-End and Receiving, Frog Final


Frog2 starts

Encouraged by my succes with Mercury, and my being able to directly deliver mail (Mercury/E), I decided to try the direct reception too, using Mercury/S and signaling my dynamic IP on the net with YI (I was already using it for WWW static redirection).
And it worked after some fiddling with my firewall:
Sending with SMTP End-To-End and Direct Receiving, Frog2.


Fine-Tuning Frog and Frog2 sending

End-to-End management of mail is not so CPU-intensive, actually it is just as cheap as using a not-so-good ISP's SMTP.
But there care cases where it would just kill your machine, because apparently you cannot cope with the receiving end.
In such a case, the trick is to alias the offending @ with another route: see Why Aliasing.
The final configurations for Frog an,d Frog2 are then:
Frog: Optimized Sending and Receiving, Frog Final
Frog2: Optimized Sending and Direct Receiving, Frog2.


Quotas hit Frog: aliasing suggested

BigFoot changed its policy to limit throughput: I noticed the change when the quota was 3000 messages/day.
That was a good indication for Aliasing.
Immediately, I created half a dozen new BigFoot addresses to allow Frog being aliased to a brother Frog address.
Actually, it could be aliased to the Frog2 address because FRog and FRog2 run on the same machine, the same program.
That is the final configuration for Frog before it dies; the quota is dommed to 25 messages/day:
Optimized Sending and Receiving, Frog Aliased


Back to Tek's Index or Root Index or Root Main Pages