homepage

>>> import os
 >>> import time
 >>> os.environ['TZ'] = 'Europe/Moscow'
 >>> time.tzset()
 >>> time.strptime('2010-06-01 MSK', '%Y-%m-%d %Z')
 time.struct_time(tm_year=2010, tm_mon=6, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=1, tm_yday=152, tm_isdst=0)
 >>> time.strptime('2010-06-01 MSD', '%Y-%m-%d %Z')
 Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/lib/python2.7/_strptime.py", line 467, in _strptime_time
 return _strptime(data_string, format)[0]
 File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime
 (data_string, format))
 ValueError: time data '2010-06-01 MSD' does not match format '%Y-%m-%d %Z'
datetime.strptime() and Python 3 behavior is exactly the same. 
The correct name is MSD:
 >>> from datetime import datetime, timezone
 >>> dt = datetime(2010, 5, 31, 21, tzinfo=timezone.utc).astimezone()
 >>> dt.strftime('%Y-%m-%d %Z')
 '2010-06-01 MSD'
strptime() uses the current (wrong for the past date) time.tzname names
despite the correct name being known to the system (as the example above 
demonstrates).
In general, it is impossible to validate a time zone abbreviation even if
the time zone database is available:
- tzname may be ambiguous -- multiple zoneinfo matches (around one third
 of tznames the tz database correspond to multiple UTC offsets (at the
 same or different times) -- it is not unusual) i.e., any scheme that 
 assumes that tzname is enough to get UTC offset such as
 Lib/email/_parsedate.py is wrong.
- and even if zoneinfo is known, it may be misleading e.g., 
 e.g., HAST (Hawaii-Aleutian Standard Time) might be rejected
 because Pacific/Honolulu zoneinfo uses HST. HAST corresponds to 
 America/Adak (US/Aleutian) in tzdata (UTC offset may be the same).
 It might be too rare to care.
Related: issue22377 

Correction:
The correct offset is +0400:
 >>> dt = datetime(2010, 5, 31, 20, tzinfo=timezone.utc).astimezone()
And _timezones dict is defined in Lib/email/_parseaddr.py 

There is no daylight savings time in Moscow and python detects this correctly:
$ TZ=Europe/Moscow python3
>>> import time
>>> time.daylight
0
Note that historically, there was DST, but time module cannot handle historical TZ changes.
(Russian government compensates the relative sanity of not moving the clocks twice a year by changing the UTC offset and TZ boundaries every 5 years or so.:-)

I don't think there is anything we can do here. Without a TZ database, Python has to rely on time.tzname which in case of TZ=Europe/Moscow returns
>>> time.tzname
('MSK', 'MSK')
Hardcoding a timezones dictionary as done in email module may work for a handful of American timezones, but will not work for TZ's like Europe/Moscow.
$ zdump -v Europe/Moscow| tail
Europe/Moscow Sat Oct 24 22:59:59 2009 UTC = Sun Oct 25 02:59:59 2009 MSD isdst=1
Europe/Moscow Sat Oct 24 23:00:00 2009 UTC = Sun Oct 25 02:00:00 2009 MSK isdst=0
Europe/Moscow Sat Mar 27 22:59:59 2010 UTC = Sun Mar 28 01:59:59 2010 MSK isdst=0
Europe/Moscow Sat Mar 27 23:00:00 2010 UTC = Sun Mar 28 03:00:00 2010 MSD isdst=1
Europe/Moscow Sat Oct 30 22:59:59 2010 UTC = Sun Oct 31 02:59:59 2010 MSD isdst=1
Europe/Moscow Sat Oct 30 23:00:00 2010 UTC = Sun Oct 31 02:00:00 2010 MSK isdst=0
Europe/Moscow Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 MSK isdst=0
Europe/Moscow Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 MSK isdst=0
Europe/Moscow Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 MSK isdst=0
Europe/Moscow Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 MSK isdst=0
(And it looks like the planned for 2014年10月26日 switch back to winter time is not in my laptop's database yet.)

On the second thought, we can probably make the same guesswork as in PyInit_timezone (see Modules/timemodule.c) in time.strptime, but not for the current time, but for the time parsed.

My patch for issue22377 also fixes this bug.
With the patch applied. Both MSK and MSD are accepted if the new 
timezones parameter is false (default for Python 3.5, will be changed to 
True in Python 3.6
If timezones is True then MSD return a correct aware datetime object,
MSK is rejected.

MSD variant works on my machine because C library uses
the historical timezone database there. I'm not sure whether it
works on old Windows versions.