Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Do some ISPs bar access to smtp except from clients/<dial-up>?
5 views
Skip to first unread message
no.to...@gmail.com
Oct 5, 2012, 10:53:55 AM10/5/12
to
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
NB.
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 smtp.absamail.co.za 25
Trying 196.41.6.142...
Connected to smtp.absamail.co.za.
Escape character is '^]'.
220 smtp.absamail.co.za ESMTP
ehlo
501 #5.0.0 EHLO requires domain address
AUTH LOGIN
334 ********
*******************
334 ***********************
*****
235 #2.0.0 OK Authenticated <-----*!
DATA
503 #5.5.1 MAIL first
MAIL FROM:<crgl***@absamail.co.za>
250 sender <crgl***@absamail.co.za> ok
RCPT TO:<eas***@absamail.co.za>
250 recipient <eas***@absamail.co.za> ok
DATA
354 go ahead
Date: Sept 3012
Subject: tst2 expect Ac2Ae2
Line after space-line separator
line-2
line-3
line-4
.
250 ok: Message 910133084 accepted <---- *!
quit
221 smtp.absamail.co.za
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:
smtp.atlantic.net
which telnet-traces as follows :--------
spawn telnet smtp.atlantic.net 25
Trying 69.28.75.82...
Connected to smtp.atlantic.net.
Escape character is '^]'.
220 smtp-1.atlantic.net ESMTP
ehlo
250-smtp-1.atlantic.net
250-PIPELINING
250-8BITMIME
250-SIZE 33554432
250 AUTH LOGIN PLAIN
AUTH PLAIN
334
eas...@absamail.co.za
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 smtp.atlantic.net 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:pop,
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.
Me -> FixedRadioModem -> ISP2 -> Internet
http == OK
Usenet == OK
telnet ..etc == OK
ISP2 ->
pop=fail : wrong ID/paswrd
smtp=fail : wrong ID/paswrd
NB.
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 smtp.absamail.co.za 25
Trying 196.41.6.142...
Connected to smtp.absamail.co.za.
Escape character is '^]'.
220 smtp.absamail.co.za ESMTP
ehlo
501 #5.0.0 EHLO requires domain address
AUTH LOGIN
334 ********
*******************
334 ***********************
*****
235 #2.0.0 OK Authenticated <-----*!
DATA
503 #5.5.1 MAIL first
MAIL FROM:<crgl***@absamail.co.za>
250 sender <crgl***@absamail.co.za> ok
RCPT TO:<eas***@absamail.co.za>
250 recipient <eas***@absamail.co.za> ok
DATA
354 go ahead
Date: Sept 3012
Subject: tst2 expect Ac2Ae2
Line after space-line separator
line-2
line-3
line-4
.
250 ok: Message 910133084 accepted <---- *!
quit
221 smtp.absamail.co.za
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:
smtp.atlantic.net
which telnet-traces as follows :--------
spawn telnet smtp.atlantic.net 25
Trying 69.28.75.82...
Connected to smtp.atlantic.net.
Escape character is '^]'.
220 smtp-1.atlantic.net ESMTP
ehlo
250-smtp-1.atlantic.net
250-PIPELINING
250-8BITMIME
250-SIZE 33554432
250 AUTH LOGIN PLAIN
AUTH PLAIN
334
eas...@absamail.co.za
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 smtp.atlantic.net 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:pop,
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.
Whiskers
Oct 5, 2012, 3:44:03 PM10/5/12
to
["Followup-To:" header set to comp.os.linux.networking.]
On 2012-10-05, no.to...@gmail.com <no.to...@gmail.com> wrote:
[...]
> If via ISP2's fixedRadioModem, I can:
> ISP1:pop,
> 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?
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.
> Is there something special happening with global email, these last few month?
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
-- ~~~~~~~~~~
On 2012-10-05, no.to...@gmail.com <no.to...@gmail.com> wrote:
[...]
> If via ISP2's fixedRadioModem, I can:
> ISP1:pop,
> 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?
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.
> Is there something special happening with global email, these last few month?
catching up with what has been normal practice for several years elsewhere.
--
-- ^^^^^^^^^^
-- Whiskers
-- ~~~~~~~~~~
Steve Baker
Oct 5, 2012, 3:53:29 PM10/5/12
to
On Fri, 5 Oct 2012 14:53:55 +0000 (UTC), no.to...@gmail.com wrote:
...
>DATA
>354 go ahead
>Date: Sept 3012
>Subject: tst2 expect Ac2Ae2
>
>Line after space-line separator
>line-2
>line-3
>line-4
>.
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
...
>DATA
>354 go ahead
>Date: Sept 3012
>Subject: tst2 expect Ac2Ae2
>
>Line after space-line separator
>line-2
>line-3
>line-4
>.
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
no.to...@gmail.com
Oct 7, 2012, 8:00:54 AM10/7/12
to
In article <slrnk6ue5h.u...@ID-107770.user.individual.net>, Whiskers <catwh...@operamail.com> wrote:
> ["Followup-To:" header set to comp.os.linux.networking.]
> On 2012-10-05, no.to...@gmail.com <no.to...@gmail.com> wrote:
>
> [...]
>
> > If via ISP2's fixedRadioModem, I can:
> > ISP1:pop,
> > 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?
>
> 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.
>
What's annoying is that there is no 'error message', so that you don't KNOW
> ["Followup-To:" header set to comp.os.linux.networking.]
> On 2012-10-05, no.to...@gmail.com <no.to...@gmail.com> wrote:
>
> [...]
>
> > If via ISP2's fixedRadioModem, I can:
> > ISP1:pop,
> > 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?
>
> 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.
>
the the mail won't be forwarded. It's just dropped.
So I tried to probe, to find out what the server wants:-
#!/usr/bin/expect
log_file LogVariousExpect
spawn telnet smtp.absamail.co.za 25
expect 220
send "ehlo\r"
expect 501
quit
spawn telnet smtp.vox.co.za 25
expect 220
send "ehlo\r"
expect 501
quit
spawn telnet smtp.lantic.net 25
expect 220
send "ehlo\r"
expect 501
quit
spawn telnet smtp.absamail.co.za 587
expect 220
send "ehlo\r"
expect 501
quit
spawn telnet smtp.vox.co.za 587
expect 220
send "ehlo\r"
expect 501
quit
spawn telnet smtp.lantic.net 587
expect 220
send "ehlo\r"
expect 501
quit
exit 0
===> and this is what I got:--
spawn telnet smtp.absamail.co.za 25
Trying 196.41.6.142...
Connected to smtp.absamail.co.za.
Escape character is '^]'.
220 smtp3.absamail.co.za ESMTP
Trying 196.41.6.142...
Connected to smtp.absamail.co.za.
Escape character is '^]'.
ehlo
501 #5.0.0 EHLO requires domain address
invalid command name "quit"
501 #5.0.0 EHLO requires domain address
while executing
"quit"
(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
no.to...@gmail.com
Oct 7, 2012, 8:01:49 AM10/7/12
to
In article <9pdu685cobcbhaced...@4ax.com>, Steve Baker <bak...@comcast.net> wrote:
> On Fri, 5 Oct 2012 14:53:55 +0000 (UTC), no.to...@gmail.com wrote:
> ....
> On Fri, 5 Oct 2012 14:53:55 +0000 (UTC), no.to...@gmail.com wrote:
>
> >DATA
> >354 go ahead
> >Date: Sept 3012
> >Subject: tst2 expect Ac2Ae2
> >
> >Line after space-line separator
> >line-2
> >line-3
> >line-4
> >.
>
> They might want to see a few more header lines, like maybe a From:
> and a To:. Also, that Date: line is malformed.
>
> ....
> >DATA
> >354 go ahead
> >Date: Sept 3012
> >Subject: tst2 expect Ac2Ae2
> >
> >Line after space-line separator
> >line-2
> >line-3
> >line-4
> >.
>
> They might want to see a few more header lines, like maybe a From:
> and a To:. Also, that Date: line is malformed.
>
> >AUTH PLAIN
> >334
> >eas...@absamail.co.za
> >501 malformed auth input (#5.5.4) <-------------* !
>
> That's not how AUTH PLAIN is done. Try AUTH LOGIN, which you seem to
> understand based on the first telnet session.
>
> --
> Steve Baker
The accumulation of logs of "try/S" is already too much.
> >334
> >eas...@absamail.co.za
> >501 malformed auth input (#5.5.4) <-------------* !
>
> That's not how AUTH PLAIN is done. Try AUTH LOGIN, which you seem to
> understand based on the first telnet session.
>
> --
> Steve Baker
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.
Thor Kottelin
Oct 7, 2012, 8:10:56 AM10/7/12
to
<no.to...@gmail.com> wrote in message
news:k4rqtl$o8u$1...@dont-email.me...
You cannot just say 'ehlo'. Try 'ehlo foo.example.com', substituting the
proper domain name. The EHLO command is explained in RFC 1869.
--
Thor Kottelin
http://www.anta.net/
news:k4rqtl$o8u$1...@dont-email.me...
You cannot just say 'ehlo'. Try 'ehlo foo.example.com', substituting the
proper domain name. The EHLO command is explained in RFC 1869.
--
Thor Kottelin
http://www.anta.net/
Whiskers
Oct 7, 2012, 9:21:29 AM10/7/12
to
On 2012-10-07, Thor Kottelin <th...@anta.net> wrote:
> <no.to...@gmail.com> wrote in message
> news:k4rqtl$o8u$1...@dont-email.me...
>
>> 220 smtp3.absamail.co.za ESMTP
>> ehlo
>>
>> 501 #5.0.0 EHLO requires domain address
>
> You cannot just say 'ehlo'. Try 'ehlo foo.example.com', substituting the
> proper domain name. The EHLO command is explained in RFC 1869.
Your system's own 'hostname' should be OK, even if it isn't registered as a
> <no.to...@gmail.com> wrote in message
> news:k4rqtl$o8u$1...@dont-email.me...
>
>> 220 smtp3.absamail.co.za ESMTP
>> ehlo
>>
>> 501 #5.0.0 EHLO requires domain address
>
> You cannot just say 'ehlo'. Try 'ehlo foo.example.com', substituting the
> proper domain name. The EHLO command is explained in RFC 1869.
domain name accessible using the global public DNS system.
0 new messages