Изпечатай

[Naka]

Потребителят попълва поле за e-mail във формата но освен стандартната синтактична проверка с  preg_match() искам да е много по-сигурно и да се провери дали наистина е-майла съществува.
Мисля си за следните стъпки, които да се изпълняват една след друга.


1. синтактична проверка с регулярен израз - има много примери (повечето от които са и грешни) - Но какво ще стане с домейните на кирилица.. Ами името преди @ също може да е уникод??? Ако продължа да използвам даже и добре написан регулярен израз след време ще почне да реже e-mail на кирилица.

2. Проверка дали се резолва домейн частта на e-maila. В php има функця checkdnsrr() с която може да се направи проверка дали съществува MX запис.

Но..Какво би станало ако e-maila е валиден но острещният ДНС сървер в момента не работи?

Незнам и как се държат mail сърверите ако няма MX запис но има A запис. ако няма MX трябва ли да се прави допълнителна проверка за А?

3. Проверка за Юзер частта /преди @/
мислех си да направя някаква SMPT конекция и като се стигне до  RCPT TO:<xxx@yyy.zz> сърверите обикновенно връщат грешка  553 sorry, this recipient is not in my v..... и прекратявам конекцията непосредствено след RCPT TO: независимо дали е приет или отказан юзера.

Но mail.yahoo.com никога не съобщава че няма такъв юзер. Той винаги приема но просто не доставя писмото.

Ето това е част от конекцията към  yahoo.com когато се опитвам да доставя писмо към несъществуващ юсер: naka_2344i_23trw - yahoo отговаря с 250 ОК

Код:

...
...
RCPT TO:<naka_2344i_23trw@yahoo.com>
250 recipient <naka_2344i_23trw@yahoo.com> ok..
DATA..
354 go ahead..
..
..

Идеи как би трябвало да се направи най-правилно?

[VladSun]

Всичко това е много хубаво (и достатъчно сложно), но бих предпочел да пратя активиращ код на съответния e-mail и при доставяне/прочитане/кликане да се удостовери валидността/съществуването/актуалността на e-mail-а.
Всякакви други (може би освен preg_match-a) проверки отпадат.

[n00b]

А някой сървъри правят друго. Казват че са много заети и да опитат пак. След 5 мин примерно.

Така се предпазват от SPAM-a (Host.bg).

По този начин цялата проверка отива на кино.

[Naka]

бих предпочел да пратя активиращ код на съответния e-mail и при доставяне/прочитане/кликане да се удостовери валидността/съществуването/актуалността на e-mail-а.

Идеално решение, само че формата ми не е за регистрация а просто за данни за контакти. и тези данни трябва да са точни в момента на попълването.
Ако го изпусна няма как да му взема е-майла освен да му се обадя по тел, и да го питам. Понеже няма регистрация, няма как юзера да се върне и да му съобщя, че не потвърдил е-майла.
Може би някакво решение с бисквитки, ама още не съм го измислил.

това много ми хареса:
http://www.tienhuis.nl/php-email-address-validation-with-verify-probe
http://www.tienhuis.nl/files/email_verify_source.php

Незнам и как се държат mail сърверите ако няма MX запис но има A запис. ако няма MX трябва ли да се прави допълнителна проверка за А?

Явно трябва да се прави проверка и за А запис.

According to RFC 2821 (referred from http://php.net/manual/en/function.getmxrr.php) an email address can be valid even though there are no MX records for the domain.

според http://www.faqs.org/rfcs/rfc2821.html глава 5

   The lookup first attempts to locate an MX
   record associated with the name.  If a CNAME record is found instead,
   the resulting name is processed as if it were the initial name.  If
   no MX records are found, but an A RR is found, the A RR is treated as
   if it was associated with an implicit MX RR, with a preference of 0,
   pointing to that host.  If one or more MX RRs are found for a given
   name, SMTP systems MUST NOT utilize any A RRs associated with that
   name unless they are located using the MX RRs; the "implicit MX" rule
   above applies only if there are no MX records present.  If MX records
   are present, but none of them are usable, this situation MUST be
   reported as an error.

А някой сървъри правят друго. Казват че са много заети и да опитат пак. След 5 мин примерно.Така се предпазват от SPAM-a (Host.bg).

Така беше Яхоото преди 2-3 години и целият свят изпъшка. Резултатът беше че писмата се бавеха 6-12 часа. Ако му се откаже на mail сервера 1-2 пъти той може да се пробва примерно след 6 часа отново.

[Naka]

Някой може ли да помогне как би трябвало да се чете този стандарт?
http://tools.ietf.org/html/rfc5322
т.е какво им означават кодировките в rfc документите
точка:
3.2.3. Atom

atext          =   ALPHA / DIGIT /    ; Printable US-ASCII
                       "!" / "#" /        ;  characters not including
                       "$" / "%" /        ;  specials.  Used for atoms.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"
   atom            =  [CFWS] 1*atext [CFWS]
   dot-atom-text   =   1*atext *("." 1*atext)
   dot-atom        =   [CFWS] dot-atom-text [CFWS]

и по надолу
3.4.1. Addr-Spec Specification

   addr-spec       =   local-part "@" domain
   local-part      =   dot-atom / quoted-string / obs-local-part
   domain          =   dot-atom / domain-literal / obs-domain
   domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

предполагам че  '/' означва ИЛИ
ами [CFWS] 1*atext [CFWS] какво ще означава
ами това
dot-atom-text   =   1*atext *("." 1*atext)
 

Не ми стигат регулярните изрази ама сега трябва да им гадая и техните криптографии 

---------------------------------------
PS: разбрах как се разгадава
http://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_Form
http://tools.ietf.org/html/rfc822#section-2