*Suspect* [Oberon] mail & uidl & etc.....

[W B Hacker]

Aubrey.McIntosh at Alumni.UTexas.Net wrote:
> On Sat, Nov 22, 2008 at 9:26 AM, W B Hacker <wbh at conducive.org> wrote:
> 
>> JM2CW, but I haven't seen any work done *yet* on Oberon/AoS smtp by anyone
>> who seemed to have the least understanding of the current state of smtp and
>> friends.
>>
> 
> That depends on what the definition of "current state" is.  In
> particular, is "current state" defined by the RFCs or by some patched
> C code on some ISP's system.
> 
> I ran an SMTP receiver under BlueBottle for about 2 years 24x7.  This
> received all my incoming email.  This was hand crafted from the
> relevant RFCs circa 2003.  It ran successfully until a cable became
> detached while I was working out of state.  I decomissioned it as the
> spam problem increased and gmail became available.
> 
> The RFCs have some requirements, such as the name a machine gives in
> the handshake must match the inverse lookup for that address.  This
> requirement has largely been removed from SMTP receivers so that they
> will receive mail from improperly configured multiport machines.  In
> my opinion, this deviation from SMTP is the single largest entry point
> for spam.  Later versions of my code do accept this variation from
> SMTP.
> 

Would that they not - as you are correct in HELO not matchng FQDN *and* 
the reverse-lookup not finding a PTR RR even *before* HELO is entered 
are indded the largest 'holes' thru which zombified WinBoxen storm.

Fortunately, more and more operators are restoring these tests, along 
with blocking from dynamic IP sources. Simply put - they are too 
powerfully effective to ignore.

And they never give a 'false positive', though they do not discriminate 
between fools and charlatans.


;-)

> The source name is something similar to AlmSmtpReceiver.  An early
> version made its way into the distribution, but the distribution never
> seemed to reflect any updates that I submitted.
> 

But the manner in which an Oberon/AoS/*bottle *receiver* operates was 
not what raised my comment. Good, bad, or indifferent, those are visible 
only to their own end-user.

It is the *other* rules - applicable to the *sending* on which an 
Oberon/AoS et al smtp critter is visible and judged.

Having proper DNS entries, a PTR record, not operating from a dynamic IP 
are 'choices' independent of the design of either an MUA or MTA.

What is visibly lacking is not so much those - but rather that too 
little cognizance has been taken of the required encoding, formating, 
mandatory & optional headers, their lengths, terminators, et al.

Ex: 'In theory' a Message-ID is not mandatory. Some widely used and 
notoriously 'broken' MUA (Outlook) don't necesarily supply one. The 
'wise' MTA detects that, and adds one on its behalf.

If neither critter does that, the message runs a risk of rejection, or 
at least elevated spam score. Either way, that one is deadeasy to do right.

But back to other 'triggers'..

Encoding and mime-types are NOT as easy when only a small pool of 
worker-=bees is involved - most with other priorities.

I suspect Chris' note went into quarentine here because it claimed 
'quoted-printable' as encoding for the *body*, which the scanner views 
askance.

As wil become apparent with my sig, we would have been just as happy 
with UTF8 .. but that is a 'wished for' (and looooong overdue) standards 
change.

And as to cross-platform MUA that JF *work*  - we rate the one built 
into the Seamonkey suite head and shoulders above tha pack. So long as 
properly configured, of course. Eg: NOT composing in html.. etc.

It also slows down hardly at all, nor loses stuff, when handling locally 
synced folders for a quarter of a million IMAP messages under a dozen or 
so identities and mailing lists. Full message sync for offline - not 
just headers.

Open source last time I looked, so fair game to have a peek and see how 
and why it works as well as it does.

Though one would have to be a masochist to code new work in C in this 
day and age, anyone who can actually understand all of its legacy 
baggage [1] should be able to cut it in half for Oberon. Or Ocaml.

Best,

Bill
韓家標

[1] C. Why would I want to hire a dog if I had to tell it to 'include' 
all the usual stuff we expect dogs to JF know, then start the day by 
telling it to allocate memory so I could teach it how to bark?

A C coder might respond that if only dogs had been coded in C, they 
would NOT lick their own a**holes, as they would not know how.

Stack overflows excepted of course. You know dogs....