Problem with Orcon mail server

Discussion in 'NZ Computing' started by g00g1eme@gmail.com, Dec 22, 2005.

  1. Guest

    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.
     
    , Dec 22, 2005
    #1
    1. Advertising

  2. 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:...
    >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, Dec 22, 2005
    #2
    1. Advertising

  3. 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
     
    The Other Guy, Dec 22, 2005
    #3
  4. ~misfit~ Guest

    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~
     
    ~misfit~, Dec 22, 2005
    #4
  5. 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
     
    The Other Guy, Dec 23, 2005
    #5

  6. >
    > 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
     
    Craig Whitmore, Dec 23, 2005
    #6
  7. Shane Guest

    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"
     
    Shane, Dec 23, 2005
    #7
  8. 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, Dec 23, 2005
    #8
  9. 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
     
    The Other Guy, Dec 23, 2005
    #9

  10. >
    > 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
     
    Craig Whitmore, Dec 23, 2005
    #10
  11. I've thought of another RFC violation of the Orcon servers. Messages
    deleted during a POP3 session were being deleted permanently if the
    connection was dropped. The RFC requires this occurs only in a
    particular state, which can only be entered using 'quit'. I've lost mail
    as a result of this, which is very annoying. Fortunately I had read the
    mail so knew who it was from. Recent upgrades may also have fixed this,
    I have not retested it.

    The new load balancer POP3 also doesn't appeaer to lock POP3 sessions.

    More on the From issue...

    It seems the from header is being removed from messages by Orcon, but
    the replacement is being inserted by Thunderbird. This explains why you
    aren't seeing it in your tests, but not why it is being removed for me.

    To assist, here are the logs from the sending application, and the
    headers as viewed via telnet.

    $ cat log.txt
    rx: "220 mail.orcon.net.nz ESMTP
    "
    tx: "ehlo 10.10.0.239
    "
    rx: "250-dbmail-mx1.orcon.net.nz Hello
    60-234-131-10.bitstream.orcon.net.nz [60.234.131.10], pleased to meet you
    "
    rx: "250-ENHANCEDSTATUSCODES
    "
    rx: "250-PIPELINING
    "
    rx: "250-EXPN
    "
    rx: "250-VERB
    "
    rx: "250-8BITMIME
    "
    rx: "250-SIZE
    "
    rx: "250-DSN
    "
    rx: "250-ETRN
    "
    rx: "250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
    "
    rx: "250-STARTTLS
    "
    rx: "250-DELIVERBY
    "
    rx: "250 HELP
    "
    tx: "mail from:<>
    "
    rx: "250 2.1.0 <>... Sender ok
    "
    tx: "rcpt to: <>
    "
    rx: "250 2.1.5 <>... Recipient ok
    "
    tx: "data
    "
    rx: "354 Enter mail, end with "." on a line by itself
    "
    tx: "From: <>
    "
    tx: "To: <>
    "
    tx: "
    "
    tx: ".
    "
    rx: "250 2.0.0 jBNJ1kV4005347 Message accepted for delivery
    "
    tx: "quit
    "
    rx: "221 2.0.0 dbmail-mx1.orcon.net.nz closing connection
    "



    $ telnet pop.orcon.net.nz 110
    Trying 219.88.242.10...
    Connected to pop.orcon.net.nz.
    Escape character is '^]'.
    +OK POP3 Ready loadbalancer-new.orcon.co.nz 0001db9e
    user username
    +OK USER username set, mate
    pass password
    +OK You are so in
    top 1 0
    +OK 0 lines of message 1
    Return-Path: <>
    Received: from 10.10.0.239 (60-234-131-10.bitstream.orcon.net.nz
    [60.234.131.10])
    by dbmail-mx1.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP
    id jBNJ1kV4005347
    for <>; Sat, 24 Dec 2005 08:01:47 +1300
    To: <>
    X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on
    dbmail-mx1.orcon.net.nz
    X-Virus-Status: Clean
    X-Spam-Score: 0
    X-DSPAM-Improbability: 1 in 406 chance of being spam
    X-DSPAM-Confidence: 0.8022
    X-DSPAM-Probability: 0.0000


    ..

    Once again, no 'From' header!

    The Other Guy
     
    The Other Guy, Dec 23, 2005
    #11

  12. >
    > More on the From issue...
    >
    > It seems the from header is being removed from messages by Orcon, but the
    > replacement is being inserted by Thunderbird. This explains why you aren't
    > seeing it in your tests, but not why it is being removed for me.


    I just checked again..

    and if the MFROM is the Same as the Header From then sendmail will just drop
    the From in the header.
    This really makes sence as the MFROM for example normally will be

    mail from:

    but the header from will be

    From: Username
    not
    From:


    so it will show up in the headers. I guess its just a really small saving of
    space in headers sendmail does.

    I haven't looked at why sendmail does this, but seems quite reasonable thing
    to do.

    Thanks
    Craig
     
    Craig Whitmore, Dec 23, 2005
    #12
  13. > $ cat log.txt
    > rx: "220 mail.orcon.net.nz ESMTP
    > "
    > tx: "ehlo 10.10.0.239
    > "


    Your email client/server should really be going

    EHLO [10.10.0.239] not EHLO 10.10.0.239

    Thanks
    Craig
     
    Craig Whitmore, Dec 23, 2005
    #13
  14. Craig Whitmore wrote:
    >>$ cat log.txt
    >>rx: "220 mail.orcon.net.nz ESMTP
    >>"
    >>tx: "ehlo 10.10.0.239
    >>"

    >
    >
    > Your email client/server should really be going
    >
    > EHLO [10.10.0.239] not EHLO 10.10.0.239


    Thanks. I am aware of this and will fix it over the weekend.

    The client is just one I threw together quickly a few weeks ago, and one
    of the things I needed to test was invalid EHLO/HELO handling. Didn't
    'fix' it after testing.

    If you (or any other readers) notice any other issues, please feel free
    to point them out.

    Thanks,

    The Other Guy
     
    The Other Guy, Dec 23, 2005
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. horizontal

    orcon mail server not working

    horizontal, Sep 24, 2004, in forum: NZ Computing
    Replies:
    18
    Views:
    583
    Seeby Woodhouse - Orcon Internet
    Sep 26, 2004
  2. Worm

    Orcon mail server dodgy?

    Worm, Nov 17, 2004, in forum: NZ Computing
    Replies:
    2
    Views:
    366
  3. Brendan

    changing from Orcon UBS to Orcon Jetstream

    Brendan, Feb 25, 2005, in forum: NZ Computing
    Replies:
    2
    Views:
    569
    Brendan
    Feb 25, 2005
  4. Jamie Kahn Genet

    Orcon UBS 2MBit or stick with Telecom/Orcon 2MBit ADSL?

    Jamie Kahn Genet, Apr 29, 2005, in forum: NZ Computing
    Replies:
    3
    Views:
    528
    Jamie Kahn Genet
    Apr 29, 2005
  5. Nova

    Orcon's Forums (for orcon users)

    Nova, Mar 15, 2006, in forum: NZ Computing
    Replies:
    13
    Views:
    850
    Mutley
    Mar 18, 2006
Loading...

Share This Page