If I had a dollar for every Linux box...

[Twail.L]

If I had a dollar for every Linux box, incorrectly set-up as a mail server,
that has been in my experience to encounter, I would have made my own
modest bid for the entire RedHat Company by now. However, the following
just takes the cake, both soundly and comprehensively, and is testament
again to the way these MVP people think. Useless...

IN REGARDS TO: "Authenticated SMTP"
"If your ISP has failed to set up their system properly, it may be that you
are not "logged in" to their server unless you Receive Mail. If you find
that you can receive mail, and anything you send immediately afterwards
does go, while anything you attempt to send half an hour later doesn't,
your ISP may be one of those."

http://www.entourage.mvps.org/troubleshoot/send_receive/sending_problems.html

*** Note the complete lack of accountability; "If your ISP has failed to
set up their system properly"

....It's actually called "POP before SMTP", and, notwithstanding it's
"work-around" type status, it is still accepted as being a viable paradigm
for "Authenticated SMTP" type sending. FACT.

Other Mail clients known to work with qmail's "Authenticated SMTP"
feature.; Outlook, Outlook Express, Agent, Eudora, Apple Mail &
"/usr/bin/mail + shell script".

Entourage2004 - bzzzzt!

The MVP's have to denounce it as being an ISP error because they don't have
an explanation for Entourage not supporting proper "Authenticated SMTP"
properly.

 

[Barry Wainwright]

If I had a dollar for every Linux box, incorrectly set-up as a mail server,
that has been in my experience to encounter, I would have made my own
modest bid for the entire RedHat Company by now. However, the following
just takes the cake, both soundly and comprehensively, and is testament
again to the way these MVP people think. Useless...

IN REGARDS TO: "Authenticated SMTP"
"If your ISP has failed to set up their system properly, it may be that you
are not "logged in" to their server unless you Receive Mail. If you find
that you can receive mail, and anything you send immediately afterwards
does go, while anything you attempt to send half an hour later doesn't,
your ISP may be one of those."

http://www.entourage.mvps.org/troubleshoot/send_receive/sending_problems.html

*** Note the complete lack of accountability; "If your ISP has failed to
set up their system properly"

...It's actually called "POP before SMTP", and, notwithstanding it's

"work-around" type status, it is still accepted as being a viable paradigm
for "Authenticated SMTP" type sending. FACT.

Other Mail clients known to work with qmail's "Authenticated SMTP"
feature.; Outlook, Outlook Express, Agent, Eudora, Apple Mail &
"/usr/bin/mail + shell script".

Entourage2004 - bzzzzt!

The MVP's have to denounce it as being an ISP error because they don't have
an explanation for Entourage not supporting proper "Authenticated SMTP"
properly.

Well, as an MVP I'm sure you won't be surprised if I object to your tone.

However, with regard to 'POP Before SMTP', it is an old system that tried to
prevent mail relaying, but is not what most people would consider as
'authenticated SMTP' nowadays.

The system has fallen in disrepute and has declined in usage due to several
inherent problems with it, and the ready availability of many simpler, more
secure and less vulnerable systems (like 'real' authenticated SMTP).

The main inherent weaknesses in POP Before SMTP are that:
a) if you are connected to your ISP's mail server through a router
using NAT translation (applies to about 99% of people using broadband and
more than one computer on a home network, and about 99.9% of medium to large
companies) then the POP collection will automatically 'authenticate' all the
users in that subnet - which could be several hundred computers outside of
your control.
b) If you happen to be using a location with a dynamic IP address (such
as 99.99% of users on dial-up have, and many users on broadband), then
collecting you mail could authenticate that IP address and leave it
authenticated after you have disconnected. The next user to log in (and you
have no control over who this is or where they may be located) to the mail
server could be allocated the same, already authenticated IP address.
c) Many of the 'black list' organisations will see a POP before SMTP
server as an open relay and will block your mail to their subscribers

There really is no valid reason nowadays to continue using POP before SMTP.
I could make a case for supporting the statement on the web page "If your
ISP has failed to set up their system properlyŠ". After all, doesn't
'properly' include 'securely' and using 'modern, widely supported
protocols'? POP Before SMTP is neither secure, modern or widely supported.

In actual fact, it is a relatively trivial exercise to set up entourage to
be fully compatible with POP Before SMTP using either applescripts or
schedules. Perhaps the web page could be updated to include this wider
information, but the whole site is the virtually un-aided work of one
individual, and is intended to be a non-technical introduction and
assistance to the average user. Someone who understands the intricacies of
POP Before SMTP hardly falls into the target audience for the site. Also,
you approach to post an inflammatory, insulting mail in this public forum is
hardly to be applauded. If you had concerns about the page, wouldn't the
polite way to deal with it have been to mail the webmaster directly and
raise your concerns in a positive way? I know Diane well, she is always
responsive to constructive criticism. To have her (or any MVPs) voluntary
efforts deprecated in the way you have done is spiteful, unnecessary and
counterproductive.

I have also removed the totally unnecessary cross-post to the windows XP
newsgroup. What on earth sort of relevance has this post to that group?

 

[Twail.L]

Well, as an MVP I'm sure you won't be surprised if I object to your tone.

Knock yourself out.

However, with regard to 'POP Before SMTP', it is an old system that tried to
prevent mail relaying, but is not what most people would consider as
'authenticated SMTP' nowadays.

No, not necessarily normal, but it's still considered valid and applicable
in certain situations. If it provides any kind of authentication
whatsoever, then it has *some* advantage over straight SMTP sending.
Even out of context, ANY authentication is better than NO authentication.

Now, given that these penultimate comments are out of context in contrast
to the prevalence of "POP before SMTP", they are consistent with the
previous appraisal of this system itself. The specific issue was more to do
with how the system in question was represented on the original website
that was referenced in the first post on this thread.

The system has fallen in disrepute and has declined in usage due to several
inherent problems with it, and the ready availability of many simpler, more
secure and less vulnerable systems (like 'real' authenticated SMTP).

"several inherent problems" have catalyzed the shift towards more secure
and less vulnerable systems.

Yes, well; "several inherent problems".
http://www.entourage.mvps.org/troubleshoot/crashes.html

The main inherent weaknesses in POP Before SMTP are that:

[...] Snip superfluous appraisal of "POP before SMTP"

In actual fact, it is a relatively trivial exercise to set up entourage to
be fully compatible with POP Before SMTP using either applescripts or
schedules.

Which, then of course begs the question:

Q. Apart from "Authenticated SMTP" not being correctly implemented in
Entourage, why in the hell would one need to do this?

Perhaps the web page could be updated to include this wider
information, but the whole site is the virtually un-aided work of one
individual, and is intended to be a non-technical introduction and
assistance to the average user. Someone who understands the intricacies of
POP Before SMTP hardly falls into the target audience for the site.

She should then take the big step and create a managerial type structure,
then delegate what tasks are unserviceable due to being so inundated with
other stuff.

Also, you approach to post an inflammatory,

[...]
I didn't mean to hurt any ones feelings.

In order to stay within the context of the original post, do you have any
comments on the incorrect implementation of "Authenticated SMTP" in
Entourage 2004? Reference material is provided below.

I have also removed the totally unnecessary cross-post to the windows XP
newsgroup. What on earth sort of relevance has this post to that group?

Restored, because there's an abundance of expert knowledge in this group,
of which you and others would most likely benefit.

 

[Twail.L]

Well, as an MVP I'm sure you won't be surprised if I object to your tone.

Knock yourself out.

However, with regard to 'POP Before SMTP', it is an old system that tried to
prevent mail relaying, but is not what most people would consider as
'authenticated SMTP' nowadays.

No, not necessarily normal, but it's still considered valid and applicable
in certain situations. If it provides any kind of authentication
whatsoever, then it has *some* advantage over straight SMTP sending.
Even out of context, ANY authentication is better than NO authentication.

Now, given that these penultimate comments are out of context in contrast
to the prevalence of "POP before SMTP", they are consistent with the
previous appraisal of this system itself. The specific issue was more to do
with how the system in question was represented on the original website
that was referenced in the first post on this thread.

The system has fallen in disrepute and has declined in usage due to several
inherent problems with it, and the ready availability of many simpler, more
secure and less vulnerable systems (like 'real' authenticated SMTP).

"several inherent problems" have catalyzed the shift towards more secure
and less vulnerable systems.

Yes, well; "several inherent problems".
http://www.entourage.mvps.org/troubleshoot/crashes.html

The main inherent weaknesses in POP Before SMTP are that:

[...] Snip superfluous appraisal of "POP before SMTP"

In actual fact, it is a relatively trivial exercise to set up entourage to
be fully compatible with POP Before SMTP using either applescripts or
schedules.

Which, then of course begs the question:

Q. Apart from "Authenticated SMTP" not being correctly implemented in
Entourage, why in the hell would one need to do this?

Perhaps the web page could be updated to include this wider
information, but the whole site is the virtually un-aided work of one
individual, and is intended to be a non-technical introduction and
assistance to the average user. Someone who understands the intricacies of
POP Before SMTP hardly falls into the target audience for the site.

She should then take the big step and create a managerial type structure,
then delegate what tasks are unserviceable due to being so inundated with
other stuff.

Also, you approach to post an inflammatory,

[...]
I didn't mean to hurt any ones feelings.

In order to stay within the context of the original post, do you have any
comments on the incorrect implementation of "Authenticated SMTP" in
Entourage 2004? Reference material is provided below.

I have also removed the totally unnecessary cross-post to the windows XP
newsgroup. What on earth sort of relevance has this post to that group?

Restored, because there's an abundance of expert knowledge in this group,
of which you and others would most likely benefit.

 

[Barry Wainwright]

Let's see what Barry Wainwright <[email protected]> has up their
dress.

[Large snip of TrollBait]

In simple terms, POP before SMTP is an old-fashioned, insecure scheme(1)
that is outdated and used on very few modern systems. It is a scheme not
directly supported in Entourage. I would rather they spent their development
money on more worthwhile stuff. However, it is trivial to implement if you
really want/need that functionality because your mail server doesn't support
any secure form of authentication. Simply set up two timed schedules, the
first to collect mail, firing a few minutes before the second which sends
mail.

Restored, because there's an abundance of expert knowledge in this group,
of which you and others would most likely benefit.

Removed again (and I note that you have added a Linux group to the original
alt.os.windows-xp cross post), since your initial complaint was against the
treatment of the topic on the Entourage Help pages. This has subsequently
degenerated into a baseless tirade against Entourage (which can quite easily
accomplish your desired objective, and I would be very surprised to see any
'abundance of expert knowledge' in those newsgroups on either Entourage or
the Entourage Help Pages. This leads me to assume that your intention in
cross posting here is self aggrandisement in pursuing a pet topic or theme
and attempting to promote a flame war. Sorry, but you failed.

I really have nothing more to add to this topic, so this is me signing off.


--
Barry Wainwright
Microsoft MVP (see http://mvp.support.microsoft.com for details)
Seen the All-New Entourage Help Pages? - Check them out:
<http://www.entourage.mvps.org/>


(1) I wouldn't even refer to it as a protocol - the only reference to it in
the RFCs I could find on a quick search was in RFC2476 'Message Submission'
where is is glossed over with the words "this does impose restrictions on
clients as well as servers which may cause difficulties"

 

[Twail.L]

Let's see what Barry Wainwright <[email protected]> has up their
dress.

[Large snip of TrollBait]

In simple terms, POP before SMTP is an old-fashioned, insecure scheme(1)
that is outdated and used on very few modern systems. It is a scheme not
directly supported in Entourage. I would rather they spent their development
money on more worthwhile stuff. However, it is trivial to implement if you
really want/need that functionality because your mail server doesn't support
any secure form of authentication. Simply set up two timed schedules, the
first to collect mail, firing a few minutes before the second which sends
mail.

Why are you so fixated on doing an essay on the folly and foibles of "POP
before SMTP"??? Given that your impetus may be a simple reference I made to
the incorrect incantation of such on the said website. Overall it had
little to do with the main issue which now appears to have gone sailing way
over your head.

Removed again (and I note that you have added a Linux group to the original
alt.os.windows-xp cross post), since your initial complaint was against the
treatment of the topic on the Entourage Help pages. This has subsequently
degenerated into a baseless tirade against Entourage (which can quite easily
accomplish your desired objective, and I would be very surprised to see any
'abundance of expert knowledge' in those newsgroups on either Entourage or
the Entourage Help Pages. This leads me to assume that your intention in
cross posting here is self aggrandisement in pursuing a pet topic or theme
and attempting to promote a flame war. Sorry, but you failed.

I really have nothing more to add to this topic, so this is me signing off.

In all of the energy and time that you spent on trying to compartmentalize
and analyzed the objectives of my original post, you have completely and
comprehensively failed to answer the most basic question that I had
originally put out there in my original post...

Q. Do you frequently believe in such self constructed machinations; Of you
sometimes riding a white horse with wings and a horn sticking out of the
top of it's head, galloping across the clouds and on into the gates of
paradise?

Your appraisal and attempted de construction of my objectives has
distracted yourself to the point where you have compositely missed the main
issue (autonomously)...

Here it is again, and please do try not to get too emotionally involved
this time...

##############################################################################

---$64 000.00 question---

Do you have an answer, or can you offer up any kind of relevant or useful
information at all, on why Entourage doesn't correctly implement
"Authenticated SMTP"

Moreover, do you know anything about this bug; Is it in the TCP/IP stack,
or is it bad code somewhere in the much higher level application stack
(most likely). Maybe, it's the Entourage program not incorrectly using the
API for the SMTP transaction, and any thing alse on a sililar level also.

################################################################################

=============================================================
Other Mail clients known to work with qmail's "Authenticated SMTP"
feature.; Outlook, Outlook Express, Agent, Eudora, Apple Mail &
"/usr/bin/mail + shell script".

Entourage2004 - bzzzzt!
=============================================================

 

[Chris Ridd]

Do you have an answer, or can you offer up any kind of relevant or useful
information at all, on why Entourage doesn't correctly implement
"Authenticated SMTP"

Entourage *does* implement authenticated SMTP; it implements the standard
SMTP AUTH extension defined in RFC 2554.

Cheers,

Chris

 

[Twail.L]

Entourage *does* implement authenticated SMTP; it implements the standard
SMTP AUTH extension defined in RFC 2554.

Cheers,

Chris

Thnaks mate,
but I was aware of this, and now, this has subsequently become the main
reason why I really want to get to the bottome of this.

It should work, but it doesn't (when talking to other MTA's)

Specifically with qmail:
www.qmail.org

....So what's the problem???

 

[Chris Ridd]

It should work, but it doesn't (when talking to other MTA's)

Specifically with qmail:
www.qmail.org

...So what's the problem???

Qmail, possibly. My understanding is that Bernstein has a certain attitude
to things and consequently qmail isn't "generous" in what it receives even
though it is probably quite strict in what it sends.

There are bunches of standard qmail patches around that might help you.

Cheers,

Chris