Do some ISPs bar access to smtp except from clients/<dial-up>?

Discussion in 'Linux Networking' started by, Oct 5, 2012.

  1. Guest

    Here's the diagram instead of a thousnad words.

    Me -> FixedRadioModem -> ISP2 -> Internet
    http == OK
    Usenet == OK
    telnet ..etc == OK

    ISP2 ->
    pop=fail : wrong ID/paswrd
    smtp=fail : wrong ID/paswrd

    Me -> FixedRadioModem -> ISP2 -> Internet -> ISP1
    pop:ID1 == OK
    pop:ID2 == OK
    smtp:ID1 == see telnet log below
    smtp:ID2 == see telnet log below

    Apart from the general increase in crime & corruption, here is South Africa,
    there seems to be a war on between ISPs.

    Previously I had dialup to ISP1 for 2 email accounts.

    Then they introduced <Transmit Authorisation> and I had to
    modify my mail client.

    Then some years later I could not send to my gmail account, although I
    was able to send and recieve between the 2 different accounts, on
    the same ISP1.

    Could this be explained by Transmit Authorisation not allowing
    the mail to EXIT the smtp, although it could transfer WITHIN the
    same 'domain'; ie. within the ISP.

    Now I can't even communicate between the 2 in the same-ISP.
    Although both pops receive from my gmail -- http-based.

    Presently I can access gmail from ISP2

    Here's a telnet trace to ISP1, via the fixedRadioModen of ISP2:----
    spawn telnet 25
    Connected to
    Escape character is '^]'.
    220 ESMTP
    501 #5.0.0 EHLO requires domain address
    334 ********
    334 ***********************
    235 #2.0.0 OK Authenticated <-----*!
    503 #5.5.1 MAIL first
    MAIL FROM:<crgl***>
    250 sender <crgl***> ok
    RCPT TO:<eas***>
    250 recipient <eas***> ok
    354 go ahead
    Date: Sept 3012
    Subject: tst2 expect Ac2Ae2

    Line after space-line separator
    250 ok: Message 910133084 accepted <---- *!
    Connection closed by foreign host.

    ---------------- end of telnet session trace:-----------

    So the smtp indicates "Message 910133084 accepted", but
    "RCPT TO:" doesn't receive any thing.
    Although "RCPT TO:" receives from my gmail..etc.

    ISP2 [Neotel/neomail] admits that their email is not-working
    and will be fixed real-soon-now; for the last 6 weeks.

    The help-line's recorded message of ISP1 advises to use:

    which telnet-traces as follows :--------
    spawn telnet 25
    Connected to
    Escape character is '^]'.
    220 ESMTP
    250-SIZE 33554432

    501 malformed auth input (#5.5.4) <-------------* !

    I don't want to waste effort on the RFC to see if/how to get past
    the TxAuthorisation, because the help-line live-person of ISP1 says
    "you need to contact ISP2 for you smtp".
    And then she says the change to is only for FUTURE.

    I'm speculating that ISP1 could previously accept smtp input via the
    general-internet, but due to <problems>, it's now been set-up to ONLY
    receive input from its clients, ie. via dial-up [ISDL ? is it called today].

    Would this be a possible explanation?

    The whole confusion coincided with plenty spam-mails from Japan and
    ISP1 having a new Macphee [an Intel corp] absurdly-http-based facility
    to manage-your-spam.

    If via ISP2's fixedRadioModem, I can:
    ISP1: telnet : smtp: as per log above, but the mail is NOT delivered,
    http, USEnet ..etc. is OK,
    then why would ISP2's pop & smtp be out of order for weeks?

    Is there something special happening with global email, these last few month?

    == TIA.
, Oct 5, 2012
    1. Advertisements


    Whiskers Guest

    ["Followup-To:" header set to comp.os.linux.networking.]

    Many ISPs only permit outgoing email using SMTP on port 25, for their own
    users sending emails 'from' email addresses provided by that ISP. Try
    using port 587 instead, or refer to your 'third party' email service
    provider for information about which ports you can use for their service
    when your 'local' port 25 is blocked.
    Nothing I know of. It does look as though the ISPs you use are only now
    catching up with what has been normal practice for several years elsewhere.
    Whiskers, Oct 5, 2012
    1. Advertisements


    Steve Baker Guest

    On Fri, 5 Oct 2012 14:53:55 +0000 (UTC), wrote:

    They might want to see a few more header lines, like maybe a From:
    and a To:. Also, that Date: line is malformed.

    That's not how AUTH PLAIN is done. Try AUTH LOGIN, which you seem to
    understand based on the first telnet session.
    Steve Baker, Oct 5, 2012
  4. Guest

    What's annoying is that there is no 'error message', so that you don't KNOW
    the the mail won't be forwarded. It's just dropped.

    So I tried to probe, to find out what the server wants:-

    log_file LogVariousExpect

    spawn telnet 25
    expect 220
    send "ehlo\r"
    expect 501

    spawn telnet 25
    expect 220
    send "ehlo\r"
    expect 501

    spawn telnet 25
    expect 220
    send "ehlo\r"
    expect 501

    spawn telnet 587
    expect 220
    send "ehlo\r"
    expect 501

    spawn telnet 587
    expect 220
    send "ehlo\r"
    expect 501

    spawn telnet 587
    expect 220
    send "ehlo\r"
    expect 501

    exit 0
    ===> and this is what I got:--
    spawn telnet 25

    Connected to

    Escape character is '^]'.

    220 ESMTP

    501 #5.0.0 EHLO requires domain address

    invalid command name "quit"
    while executing
    (file "./VariousExpect" line 9)
    It's no good querying the ISP.
    They are run like a KFC franchise.
    With their newly WEB-BASED html-mail MacPhee
    [an Intel corp] spam control mechanism.

    I suppose getting the mail to the remote destination is
    quiet complex, so one can't bypass the ISP's server, else
    spamming would be even worse than it presently is?

    == TIA
, Oct 7, 2012
  5. Guest

    The accumulation of logs of "try/S" is already too much.
    Their server seems set up as a tar-trap.
    It doesn't announce that it won't forward the mails.
    So refining/tuning the TxAuthentication to correct syntax
    is just a waste of resources. Which is the intention of
    their tar-trap.
, Oct 7, 2012
  6. You cannot just say 'ehlo'. Try 'ehlo', substituting the
    proper domain name. The EHLO command is explained in RFC 1869.
    Thor Kottelin, Oct 7, 2012

    Whiskers Guest

    Your system's own 'hostname' should be OK, even if it isn't registered as a
    domain name accessible using the global public DNS system.
    Whiskers, Oct 7, 2012
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.