[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