Showing posts with label trouble shooting. Show all posts
Showing posts with label trouble shooting. Show all posts

Friday, November 06, 2015

Yahoo doesn't accept cellphone number?

Recently I have big issue with yahoo. I need a couple of newest accounts at yahoo to test.
Since a while, yahoo asks for cellphone number to complete the registration process.
A verification code will be sent by yahoo to this number and you have to type this code on the webpage.
I found a lot of trash cellphone numbers. Just like trash Email addresses, these numbers can be used by anyone but the sms texts including history can be read by anyone as well.

http://vsimcard.com/free_cards.php for instant.
I used the number 004917679801863 to set up a new account.
Sadly yahoo told me this is not a valid cellphone number.


If I review the history...

SenderDateContent
44778147065903/11/2015 11:05:527699 ist Ihr Bestätigungscode von Yahoo
44778147065903/11/2015 09:51:048635 is your verification code from Yahoo
44778147065903/11/2015 00:11:020697 ist Ihr Bestätigungscode von Yahoo

at least this number has been used for setting up new accounts only by today.
which means,

  • This number is active. Yahoo has accepted it.
  • The same number can be used more than once.
  • The same number can be used more than once on the same day.
Here is the question: is 3 times the limit for the same number?

Mobile phone

It's extremely important to keep your contact info up-to-date because it's one of the ways that we protect your account security. If you forget your password, you can easily reset it with your mobile number and get back into your account. If you don't provide a supported mobile number, you'll be unable to complete registration.
We also collect an optional phone number in the event you don't have access to your mobile so that we can call or send a text if you lost account access.
Yahoo doesn't say how often one single number can be used.
However, I found the following code in the quell text.

//SMS
    SMS_STATUS_99                           : 'Es ist ein Fehler aufgetreten. <a href="/registration">Bitte versuchen Sie es erneut.</a>',
    SMS_STATUS_101                          : 'Es ist ein Fehler aufgetreten. <a href="/registration">Bitte versuchen Sie es erneut.</a>',
    SMS_STATUS_106                          : 'Dies ist keine gültige Handynummer.',
    SMS_STATUS_107                          : 'Sie haben die Höchstgrenze für SMS erreicht. <a href="/registration">Bitte versuchen Sie es erneut.</a>',
    SMS_GENERIC_ERROR                       : 'Es ist ein Fehler aufgetreten. <a href="/registration">Bitte versuchen Sie es erneut.</a> ', 

Was is the meaning of SMS status 106? I am neither a deliverability expert on SMS nor a yahoo guru...
It seems, yahoo must try to send SMS to this number but without success.

Who knows more about it? Otherwise, I will keep on testing to find out a solution.

Friday, July 10, 2015

Gmail has a new release! New analytics tool with smart dashboard













Google launched its Gmail Postmaster Tools, which allow the qualified high-volume senders to get a better idea of how Gmail treats their emails.

The tool shall show lots of deliverability informations in different dashboards.





















Once the domain ownership has been verified, the qualified senders can monitor the Email delivery to the biggest ISP of the world.

Wednesday, February 04, 2015

Trouble shooting -- an easy way to recognize IP reputation

Who's using PowerMTA to send Emails, knows the amazing backoff mode.
There is a setting named "backoff-reroute-to-virtual-mta". If this is set up, then PMTA reroutes the traffic from the trouble IP to the pointed IP automatically.

Assume I have a pool consisting of 4 IPs, IP1, 2, 3 and 4.
I set up a loop by using the setting "backoff-reroute-to-virtual-mta" to reduce the queues and bounces.
It means, the traffic will be rerouted from 1 to 2, 2 to 3, 3 to 4 and 4 to 1 automatically, if there are certain issues to send out the emails over original IPs.

Since these 4 IPs stay in the same pool, they must carry the same traffic theoretically.
After the setting of backoff rerouting, they will carry the same traffic, if and only if these 4 IPs have the similar (necessary condition) and healthy (sufficient condition) reputation.

Once I check the dashboard/report and I see very different total numbers of message counts.
Depends on the number of bounces (explanation s.b.), the IP has most total sent, has the best reputation and the one has least sent, has the poorest reputation.

Why I am saying, it depends on the bounce numbers?
It happens, that all of these 4 IPs have bad reputation.
All mails ran cycle, they are ended up in one IP, for example IP1, and bounced there.
For this case, IP1 has the most traffic, most bounces, probably most deliveries, but it doesn't have a good reputation either.

This is an easy way to measure IP reputation from the sender's side.
SNDS, Return Path, etc. are not needed.