World: r3wp

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 ?

greylisting is when you temp fail an incoming message so that they 
are forced to wait eg. 5 mins or 30 mins before you accept their 
email.

Yes, some SMTP servers apply such restrictive rules, but not the 
big ones (AFAICT). But the more important is to have a reverse dns 
that matches your servers domain.

spammers don't retry .. or retry immediately

they don't delay for 5 mins and retry .. as it is too expensive

Cheyenne's MTA waits for 5mn before raising a timeout as per RFC.

It's not a timeout, it's a temp failure.

Never encountered that so far while testing with the big ones (Yahoo, 
Gmail, Hotmail, French ISPs)

http://www.compkarori.com/vanilla/display/Smtpd.r

This is my teergrubbing greylisting mail server for Uniserve

I tried sendind from home computers connected through either cable 
or ADSL connections. Only Yahoo!Mail rejected emails sent from ADSL 
network.

I was quite surprised to see that Gmail and others accepted emails 
sent directly from a MTA on home computer...(I thought that I would 
need to make all testing from remote servers).

I also would now drop that restriction ...

and analyse the email instead ...

but in 2005 I rejected all broadband based mtas

Yeah, I studied your smtpd.r implementation. I thought I would need 
to support greylisting, but it seems not to be required to deliver 
emails to the big ones.

Good to know ...

Thanks Dock for this new release 8)

You really are creating one of the flagship applications with cheyenne. 
 Something that should be broadcast a bit more outside of the REBOL 
fanbase IMHO.

Many servers do use greylisting, many spammer bots do retry after 
a delay

build better armor, they build better weapons  ;-)

might as well wear none and dodge things instead  ;-D

This was how the Mongul army defeated all the armies of Europe.

Update cheyenne via Svn, ran it .. and it locks up consistently.

Windows 7 RC1

Port 7900

Max: I want the web control panel and the one-click webapp deployement 
feature for Cheyenne to make it more attractive to non-rebol users. 
Still a lot of work to make it close to what I have in mind.

Graham: did you run it from sources or did you encap it?

source

I should create a fresh checkout

try from console : do/args %cheyenne.r "-vvvvv"