[Oberon] Re: Refine *Mail*.Mod

W B Hacker wbh at conducive.org
Sun Nov 5 01:33:01 MET 2006


easlab at absamail.co.za wrote:
> --snip--

*snip* (too deeply buried at my end in 'conventional' smtp & auth to have any 
WinWOES, Linux, or N-O exerience to contribute)

> 
> Please explain:  <hostname/domain>.<tld>.

conducive.org

mail.conducive.org

A 'HELO' is supposed to be a fqdn that resolves to the same IP from whenc the 
conenciton has arrived.

Exception: This check is made (or not) for peer MTA exchanging traffic, but NOT 
for clients arriving to AUTH.

> This seems related to the problem described below.
> The rfc seems to assume that no user info is known, before the 
> TxAuthentication starts.
> 
All that is known is the IP from whence arriving and (usually) the protocol of 
the service requested/in use.

>> Try: "ehlo crglur at absamail.co.za" 
>>
> Well no, this is related to the problem described below.
> BTW I think much of ETH-N-O's problem is the "try"
> [suck it and see method] vs a more theoretical approach ?
> 
>>> 250-absamail.co.za Pleased to meet you
>>> 250-HELP
>>> 250-EXPN
>>> 250-PIPELINING
>>> 250-8BITMIME
>>> 250-DSN
>>> 250-AUTH LOGIN   <--- the Tx-authentication type available [per M$!]
>> Actally that one is the standard
>>
>>> 250-AUTH=LOGIN
>> The one with embedded '=' sign is the WinWOES smudge
>> Not all hosts support it (none of our MTA do)
>>
> Thanks, I'll check my research docs.

Also - typical MTA has *at least* 2, often half a dozen available auth methods.

Which one you get is to be chosen from the selection 'advertised' on the banner, 
(above), but you may get a different-looking initial banner depending on arrival 
port and protocol in use.

*snip*

> -------
> 
> For years I've been harping on about a 'system where collaborators
> can incrementally contribute'. And Edgar replied by refering to wiki.
> Now that I've finally found and read a mass of wikipedia, I've 
> confirmed that the idea works very well.  
> 
> The ETH method, where each student must do his OWN project,
> is NOT appropriate to *us* outsiders.    I strongly urge the setting up
> of a method whereby, several contributors can incrementally
> advance the same [one of several] project.
> 
> 
> == Chris Glur.
> 

You've clarified one of the biggest factors holding back advancement:

A Uni is *required* to evaluate each student on *their* ability - not that of 
the group.  A business is mostly the reverse, but not entirely.

That is why companies use a Uni degree as just one more box that needs to be 
ticked, and military organizations - where teamwork is life-or-death, seldom 
place much importance on a degree not their own.

Either must train on what the grad actually needs to know.

ETH is doing what it (believes) it is supposed to do.

A totally different group is where Linux-style bazaar vs cathedral goes on at 
its best.

post grads? dropouts? bystanders?

;-)

But tougher for active students or active staff. 'Spare time' is in too short a 
supply.

Bill



More information about the Oberon mailing list