World: r3wp

sqlab... I used nginx in front of cheyenne to have SSL  .. here http://www.cebelca.biz

it was quite simple , I just joined two examples from their tutorials 
.. the SSL and the reverse proxy one .. I can give you the config 
file

(using the above test RSP script)

>> read http://localhost/set-msg.rsp
connecting to: localhost

** User Error: Error.  Target url: http://localhost/set-msg.rspcould 
not be retrieved.  Server
 response: HTTP/1.1 404 Person not found
** Near: read http://localhost/set-msg.rsp

SSL: It can only be supported by using a third-party front-end like 
stunnel or nginx.

Janko, can you post your config etc

Best way to redirect domain.com to www.domain.com: correctly setup 
the DNS records.
Best way to do it in Cheyenne: (untested)

domain.com [
	root-dir %/...
	redirect 301 "/*" "http://www.domain.com"
]

www.domain.com [
	root-dir ...
]

An alternative way could be to defined a default /index.rsp script 
with <% response/redirect/last http://www.domain.com%> (use /last 
refinement only with v0.9.20+)

For my web sites, I always achieve domain aliasing using CNAME DNS 
records.

ok, clear now.

In httpd.cfg was the default on-status-code 404 activated. I had 
just removed the custom error page.

I will give nginx a try

nginx+cheyenne is a great combination! 8)

how I use it: nginx get all the requests, if a file is not found 
it will proxy-reverse the request to cheyenne wich is configured 
with a on-status-code [404 trap.r] . trap.r check the url request 
and either load and respond with an rsp or send a 404

nginx has nice things like you can pre gzip your static content so 
it wont have to compress for each request

thanks for the info. But I will also check stunnel.

No way yet of encapping a webapp with Cheyenne?

That requires a virtual filesystem and deep patching Cheyenne to 
use it. I've tried to make one a few months ago, but hadn't enough 
time to finish it. It's a feature I need too (but low pri currently).

SVN r17 : big update, lot of code added mostly for the new embedded 
async Mail Transfer Agent (MTA)

FEAT: email async sending sub-system (MTA) added . 

FEAT: added two new functions for email support in RSP/CGI scripts: 
'send-email and 'email-info?
FEAT: added email sending demo form %www/email.rsp.

FEAT: Cheyenne's main process ID is now exported in /tmp/cheyenne.pid 
on start and deleted on quit. (All platforms except Windows).

FIX: fixed broken global words protection in RSP.r.
FIX: HTTP Date headers are now in UTC format.

FIX: "Reset Workers" menu wasn't working in service mode. Fixed now. 
(Thanks Will)

FIX: SVNr4 regression bug on system port for UNIX fixed. (Thanks 
Will)

FIX: multipart file uploading code refactored. Fixes many bugs in 
file uploading.

A few words about the new MTA and email capabilities :


- Emails are written to disk before sending in async mode. Upper 
email size limit is 2GB. Concurrent emails sending supported (limited 
only by machine resources).

- Only the higher priority MX is used (fallback on others MX should 
be added soon).

- The MTA currently supports only 8BITMIME compliant SMTP servers 
(fallback to 7bit mode will be added if it still make sense to support 
it).

- MTA will  try to send an email once. If the server is busy, it 
will report a failure. Deferred retries will be added using the scheduler 
module (if MX fallback is not enough).

- Emails queue saving should be added in next update (the queue will 
survive to server restart, but not server crash).

- Automatic failure reports are sent back to emitter (From: field).
- Reports can be fully customized.

- Still needs a lot of testing for tracking small errors or issues 
that can trigger antispam filters (e.g. gmail is very picky about 
correct emails format).


You can test it using the provided test script : http://localhost/email.rsp

In addition :

- custom charset can also be set (default to ISO-8859-1").
- attached files are supported.

SVN r18: 

DOC: added quick syntax overview for email API in %www/email.rsp

Btw, in order to forge emails to be sent, I've tried to rely on REBOL's 
builtin email support functions (big mistake!). You should know that 
they *are not* RFC compliant, the biggest issues being :


- emails produces by REBOL are using LF as EOL instead of CRLF (RFC 
2822). See http://cr.yp.to/docs/smtplf.html

- headers are not encoded for non ASCII-7bits characters (RFC 2047)


So, I've deeply patched the builtin code at runtime to workaround 
this, but, I should have better rewrote it all from scratch (that's 
what I intend to do when I'll have enough free time).

Write up your patches and we can see about getting them integrated 
into the next version of R2 :)

I didn't though that Carl would still support R2 by providing new 
versions...(surprising but) good news. :-)

We need it for R3 too, so it would be wonderful if they could be 
written simultanoeusly.

nice on the mta ... maybe I should get back to work on my mail server

I'd probably use Amazon for email.

stick the email in a SQS queue ... and remove from the queue when 
the send is successful.

so that way the cheyenne mta can keep trying over 4 days to send 
the mail.

If my cheyenne server goes down .. I can resume from another instance.

Cheyenne can be configured to work that way too, but is it desirable? 
I remember the way email was handled 15 years ago, when having failure 
reports after one or 2 days wasn't bothering anyone, but today, we're 
in a world of fast communication (often realtime). When I send a 
mail from gmail, if there's an issue, I get a report in less than 
a minute or two.

I had an email that took 2 days to get a report back from gmail that 
it could not be delivered.

That was last month too.

I was also thinking of how scaleable it could be made ...

Were you satisfied by that or would have you prefered that gmail 
gives you a failure report 5 minutes max after posting your email?

I'd prefer instant failure report ...

yeah cause we'll try another communication channel right away  :-)

but that's not detemined by gmail ... the recipient server might 
be the cause.

If you use SQS then you could have a farm of Cheyenne servers sending 
the mail :)

Me too, that's why I'm reluctant to implement it in the old fashion 
way (retrying every 8 or 12 hours seems way too long now). I would 
support trying without delays alternative MX servers and if all fail, 
try 1 or 2 minutes after that. That would be by default, but could 
be extended by user if required.

of course it could be your own isp that is the issue ... sometimes 
we have lost interrnational traffic, but local traffic is okay.

Emails sending and MX querying are all fully async. Emails are streamed 
from disk, no memory overhead whatever the email size. You could 
send hundred (maybe even thousands on fastest machines) of email 
per second using Cheyenne if needed.

so failing every email ... would not be good.

Guess we need to field test .. and see how it works

Anyone got a list of 1,000,000 valid email addresses for sale??

Yes, it needs heavy testing, but works quite well so far.

:-)

If you're not using your ISP's smtp server, won't the recipient notice 
your domain and the email from address don't match and flag your 
email as spam??

Unless your smtp server is a trusted or whitelisted server

Well, I used to use that criteria when I had my own mail server ... 
I grey listed all such messages.

So, the question is also, does the mta handle greylisting ?