Oops, after you send the "mail from" the next step is the "Rcpt
to:"....not the data command.
Sorry about that.
Mike
-------- Original Message --------
Subject: Re: [NF] Standard Email Sender Verification Procedures
From: Mike Copeland <m...@ggisoft.com>
To: profoxt...@leafe.com
Date: 4/29/2013 4:36 PM
When you send
mail from:<overfullexistingmail...@mydomain.org>
and their server responds with
250 OK
then your next step would be to issue the DATA command and start
sending your message.
The receiving server doesn't know if it is talking to telnet (with you
typing commands) or Outlook or Thunderbird or any other email client
software.
You might consider installing a network sniffer on your workstation
(like Wireshark) and then you'll be able to see, exactly, what the
communications between your email client software and their email
server software is.
I wouldn't suggest going to that much trouble, but the fact that
Telnet is providing you with an 250 OK but your email client software
apparently doesn't, makes me wonder what else may be going on.
Try to work completely through the telnet test and send yourself an
email "Hello World" and see what happens. And yeah, I'm very aware of
what a pain in the butt sending email via telnet is....one little typo
and you have to start over.
Mike
-------- Original Message --------
Subject: Re: [NF] Standard Email Sender Verification Procedures
From: Ken Dibble <krdib...@stny.rr.com>
To: profoxt...@leafe.com
Date: 4/29/2013 4:03 PM
At 03:41 PM 4/29/2013 -0500, you wrote:
I think that your explanation (below) is clear.
Why, in the name of all that is normal, would the email service
provider that you use test YOUR account for being full when YOU send
an email? Or to ask it another way, what is the logic for doing
that? Are they assuming that if your email inbox is full that you
are not going to send anything? That's just nuts.
Or, again, am I misunderstanding?
In your info, below, you identified yourself as u...@mydomain.net.
If you try to send me an email using your account u...@mydomain.net,
then I would only expect MY email address to be an issue in a
perfect world. Now, almost any self-respecting email service
provider (your service provider that you pay for the privilege) will
test the sender/sending address ("u...@mydomain.net") to be both a
valid address and an address that they are responsible for.
Hmmmm.....maybe that is why he is attempting to use a call back
procedure...
Okay, so you say that this only happens when your inbox has reached
the arbitrary limit the service provider has set.
The service provider says that if they don't get a 250 (all okay)
then they refuse to let you send. Curious.
I would say that the service provider is using a very odd, and
obviously unworkable, method to determine if you are one of their
customers. Why would they not, instead, maintain a database of
customers email addresses and validate against that?
Sorry, but I'm going to have to cast my vote for another
provider...or you're going to have to poke them until they revise
their methods. I think you also said that something "changed"
recently, so obviously they are not anti-change.
This all makes me wonder if they actually have control of the email
server they are selling you service from...there are a lot of
resellers out there that just handle the human-customer-seller
interaction and buy the service at a discount from the actual
computer owner-operator.
Hm... that could be. That might be why, as the provider said, the MTA
and LDA don't really know each other.
I did the following:
telnet mail.mydomain.org
220
ehlo test.com
250
mail from:<overfullexistingmail...@mydomain.org>
250 OK
So at that point my provider could have sent the email on to my
intended recipient with full confidence that I am a valid user.
However, if I try to send email from that same account using my
POP/SMTP client, I get 550 Sender verify failed.
This is, of course, verified email, which requires the SMTP
conversation to do a few more things, including sending the account
address and a password. So I would guess the verification occurs on
the account/password check, before we even get to MAIL FROM:
Thanks.
Ken Dibble
www.stic-cil.org
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/517ee863.8060...@ggisoft.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
