«

I use MailWasher to screen several POP accounts for spam before I
download the email with Outlook. Beginning December 22 (yesterday) I
get the following error when I try and check my Orcon account with
MailWasher:

"The POP server does not appear to conform to the POP3 protocol (I
couldn't parse the unique-id listing)"

Is anyone else having problems with MailWasher and Orcon? I can still
check my other POP accounts without error.

I've submitted a support ticket to the Orcon help desk but don't expect
a response for a couple of weeks.

While I'm on the subject of Orcon, are any other BitStream customers
having problems with web browsing during peak times? I get a lot of
timeout errors when trying to access sites such as stuff.co.nz during
the evening.

This issue should be resolved this morning and would of only affected a very
small amount of customers on a very small number of clients.

Thanks
Craig

<> wrote in message
news: oups.com...
>I use MailWasher to screen several POP accounts for spam before I
> download the email with Outlook. Beginning December 22 (yesterday) I
> get the following error when I try and check my Orcon account with
> MailWasher:
>
> "The POP server does not appear to conform to the POP3 protocol (I
> couldn't parse the unique-id listing)"
>

Craig Whitmore wrote:
> This issue should be resolved this morning and would of only affected a very
> small amount of customers on a very small number of clients.

The Orcon mail servers haven't been close to RFC compliant in months.
Are you finally ditching DBMail? Please?

The Other Guy

wrote:

<snip>

> While I'm on the subject of Orcon, are any other BitStream customers
> having problems with web browsing during peak times? I get a lot of
> timeout errors when trying to access sites such as stuff.co.nz during
> the evening.

Been getting a few, yes. Couldn't connect to nzcity and stuff a couple times
yesterday. Something about 'No response" and "Timeout".
--
~misfit~

The Other Guy wrote:
> Craig Whitmore wrote:
>
>> This issue should be resolved this morning and would of only affected
>> a very small amount of customers on a very small number of clients.
>
>
> The Orcon mail servers haven't been close to RFC compliant in months.
> Are you finally ditching DBMail? Please?

Now that I'm home from the office, I thought I'd expand on my RFC
compliance problems. I don't wish to sound like I'm complaining, I just
wish to point these out in the hope that they can be fixed.

All of these have caused me problems over recent times
sending/receiving. They are not purely theoretical issues.

1/ HELO/EHLO blocking.

The Orcon mail servers (at least last time I tested, a few months ago)
block 'invalid' HELO/EHLO parameters by dropping the connection after
the command is issued.

There a few problems with this. A FQDN does not require a PTR record,
and this doesn't take in to account address literals or other sensible
values which is all the client is required to give when a FQDN is unknown.

The SMTP RFCs makes mention of dynamic IP addressing and hosts with no
fixed hostname, so blocking on that basis is also invalid.

The SMTP RFC also makes it clear that the HELO/EHLO MUST NOT prevent the
message from being delivered. Orcon servers (and indeed many others out
there) are failing on this.

2/ Delivery to postmaster

Related to the above, there is no possibility to deliver mail to
postmaster. Servers are required to make an effort to deliver mail to
postmaster, which is clearly impossible when blocking based on HELO/EHLO.

3/ POP3 mail order

The POP3 server does not order messages correctly. The numbers should be
strictly ascending, so the newest arrival always has the highest number.

The problem here is the way the RFC is written. From memory it mentions
the order must be that in which messages appear in drop files. The only
sensible way to place mail in a drop file was to append (re-writing is
inefficient), so I think it is reasonable to interpret the RFC as
requiring this strict ordering. Serveral clients also make this assumption.

The authors of DBMail used by Orcon, presumably in an effort to reduce
server load, interpreted this in the way that was most favourable to
them... the order the information is extracted from the database. The
problem with SQL databases is the order is in no way guaranteed.

This particular issue is a problem for me persoanlly as I use telnet to
check my mail. I should be able to just look at the items with the
highest number, not have to go through each one to find the 'new' message.

Although this was most definitely a client bug, I also had one e-mail
client crash on me every time a message arrived out of order.

4/ Header re-writing

The Orcon server does some particularly nasty header rewriting (bad
practice). In particular, if the first header in your message is the
'from' header (which is entirely valid for client to server delivery,
'Received' should be the first line from relayed messages), then the
'from' header is lost, and replaced by a non-RFC822-compliant 'from'
line that clients will fail to interpret correctly. This is also
potentially a problem for downstream servers that may be distributing
mail based on headers, although such configurations wouldn't be as
popular these days as they may have been previously.

I suspect this is a side-effect of the local delivery portion of the
process (i.e. it should only show up with Orcon to Orcon mail), but I
have not tested this to see if badly formatted mail can be relayed.


There may also be an issue with the new load balancing POP3 server not
interpreting commands sent before the server has responded to the last
command. Technically this isn't an RFC violation as the POP3 protocol
doesn't support it. Unfortunately clients do it, and in fact several
times I have had the 'stat' command fail on me after login, apparently
because I typed it too fast! I have not tested my theory on this one yet.

Hope this helps get the bugs sorted out.

The Other Guy

>
> 1/ HELO/EHLO blocking.
>
> The Orcon mail servers (at least last time I tested, a few months ago)
> block 'invalid' HELO/EHLO parameters by dropping the connection after the
> command is issued.

We are blocking HELO/EHLO of the names/ip addresses of the mail server and
localhost + others
We do this as machines should send the HELO/EHLO of the machines hostname,
not the name of the server which the client is connecting to
Also the RFC's say that the HELO/EHLO should be the fully qualified domain
name with at least 1 . in it. but outlook express + many other clients
send usually the hostname only. (so microsoft and many others don't follow
RFC's anyway)

This not done after the initial HELO/EHLO (see below)

We did quite alot of testing in this respect and has not caused any problem
except for
a very small number of broken clients/servers which have been fixed with
clients individually.

Email admins have to these days do rules like this as SO much email tried to
come from malware and viruses. Tens of Thousands of Viruses a day try and
come into Orcon Servers and ALOT more malware/spam etc.

>
> There a few problems with this. A FQDN does not require a PTR record, and
> this doesn't take in to account address literals or other sensible values
> which is all the client is required to give when a FQDN is unknown.

We are not blocking things like HELO [1.1.1.1] or HELO [2.3.4.5] as these
are legal
but HELO 1.1.1.1 and 2.3.4.5 are illegal (but these rules have not been
incorporated yet)

>
> The SMTP RFCs makes mention of dynamic IP addressing and hosts with no
> fixed hostname, so blocking on that basis is also invalid.
>
> The SMTP RFC also makes it clear that the HELO/EHLO MUST NOT prevent the
> message from being delivered. Orcon servers (and indeed many others out
> there) are failing on this.

We are not blocking on the initial HELO but we use other information as well
and blocking after the MAIL FROM (If its an illegal HELO/EHLO) we use both
information to deny/keep processing the message which it says can be used.

I have never ever had any reports false positives (with properly working
clients). and I check the logs quite a lot. If someone wants to let me know
out mail servers are blocking legitimate email please feel free to contact
me

>
> 2/ Delivery to postmaster
>
> Related to the above, there is no possibility to deliver mail to
> postmaster. Servers are required to make an effort to deliver mail to
> postmaster, which is clearly impossible when blocking based on HELO/EHLO.
>

I cannot see how the above can stop delivering to postmaster@domain or even
DSN's.. Can you give me an example?

> 4/ Header re-writing
>
> The Orcon server does some particularly nasty header rewriting (bad
> practice). In particular, if the first header in your message is the
> 'from' header (which is entirely valid for client to server delivery,
> 'Received' should be the first line from relayed messages), then the
> 'from' header is lost, and replaced by a non-RFC822-compliant 'from' line
> that clients will fail to interpret correctly. This is also potentially a
> problem for downstream servers that may be distributing mail based on
> headers, although such configurations wouldn't be as popular these days as
> they may have been previously.
>
Can you also give me an example? as I've never seen this.

Thanks
Craig
Orcon Internet Ltd

On Fri, 23 Dec 2005 20:34:05 +1300, Craig Whitmore wrote:


> Thanks
> Craig
> Orcon Internet Ltd


Given the time and date of Craig posting, I request the group moderator
removes his posting on the grounds that he is obviously far too sober

--
This was the most unkindest cut of all.
-- William Shakespeare, "Julius Caesar"

Craig Whitmore wrote:
>>1/ HELO/EHLO blocking.
>>
>>The Orcon mail servers (at least last time I tested, a few months ago)
>>block 'invalid' HELO/EHLO parameters by dropping the connection after the
>>command is issued.
>
> This not done after the initial HELO/EHLO (see below)
....
> I cannot see how the above can stop delivering to postmaster@domain
or > even DSN's.. Can you give me an example?

This may have been fixed during the last upgrade. I no longer have
access to a system with this configuration, but, if a system connected
to you to send mail, and no hostname was associated with ther IP, the
connection was being dropped before mail could be sent. Even mail to
'postmaster' was not being accepted.

There are lots of systems out there with configurations like this (due
to the fact that this can only be set at the /24 level, not by those
assigned the IP addresses), and blocking on it prevents legitimate mail
getting to me.

I should point out I have turned off _all_ filtering I can. I consider
it worse than the spam it is trying to stop because I can't trust it. I
would rather have the spam than miss out on one real message.

>>4/ Header re-writing
>>
>>The Orcon server does some particularly nasty header rewriting (bad
>>practice). In particular, if the first header in your message is the
>>'from' header (which is entirely valid for client to server delivery,
>>'Received' should be the first line from relayed messages), then the
>>'from' header is lost, and replaced by a non-RFC822-compliant 'from' line
>>that clients will fail to interpret correctly. This is also potentially a
>>problem for downstream servers that may be distributing mail based on
>>headers, although such configurations wouldn't be as popular these days as
>>they may have been previously.
>>
>
> Can you also give me an example? as I've never seen this.

I've found what I think is the cause, and the position doesn't seem to
matter (A bad assumption based on header ordering in two different
clients). The following lines behave differently...

From: "The Other Guy" <>
From: <>

The latter will result in the From header being removed from the
message, and a line similar to the following being inserted at the top
of the message...

From - Sat Dec 24 07:20:10 2005

The Other Guy

The Other Guy wrote:
> I've found what I think is the cause, and the position doesn't seem to
> matter (A bad assumption based on header ordering in two different
> clients). The following lines behave differently...
>
> From: "The Other Guy" <>
> From: <>
>
> The latter will result in the From header being removed from the
> message, and a line similar to the following being inserted at the top
> of the message...
>
> From - Sat Dec 24 07:20:10 2005


I should have said both messages contain this additional header. It is
still likely to confuse any local mail processors. Personally if I were
coding it, I'd throw the message out as being a violation of RFC822.

The Other Guy

>
> I've found what I think is the cause, and the position doesn't seem to
> matter (A bad assumption based on header ordering in two different
> clients). The following lines behave differently...

They seem to work fine either way
>
> From: "The Other Guy" <>

Return-Path: <>
Received: from wodld (news.orcon.net.nz [60.234.1.32])
by dbmail-mx2.orcon.net.nz (8.13.2/8.13.2/Debian-1) with SMTP id
jBNIo5MG029985
for ; Sat, 24 Dec 2005 07:50:22 +1300
From: "The Other Guy" <>
To: undisclosed-recipients:;
X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on
dbmail-mx2.orcon.net.nz
X-Virus-Status: Clean
X-Spam-Score: 0
X-DSPAM-Improbability: 1 in 155 chance of being spam
X-DSPAM-Confidence: 0.6068
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 43ac46fd303361881691211
Message-ID: <mailbox-30329-1135363837-939901@dbmail-mx2>


> From: <>

Return-Path: <>
Received: from wodld (news.orcon.net.nz [60.234.1.32])
by dbmail-mx2.orcon.net.nz (8.13.2/8.13.2/Debian-1) with SMTP id
jBNIoe84030365
for ; Sat, 24 Dec 2005 07:50:52 +1300
From: <>
To: undisclosed-recipients:;
X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on
dbmail-mx2.orcon.net.nz
X-Virus-Status: Clean
X-Spam-Score: 0
X-DSPAM-Improbability: 1 in 155 chance of being spam
X-DSPAM-Confidence: 0.6068
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 43ac4712305391210320651
Message-ID: <mailbox-30538-1135363859-492580@dbmail-mx2>


>
> The latter will result in the From header being removed from the message,
> and a line similar to the following being inserted at the top of the
> message...


>
> From - Sat Dec 24 07:20:10 2005
>
> The Other Guy