SMTP kullanıcı adını doğrulamak ve posta listesi içeriğini elde etmek için komutlar da sağlar. Bunu karakter dizisi bağımsız değişkenler alan VRFY ve EXPN komutları ile yapar. Gerçeklenimler VRFY ve EXPN komutlarını desteklerse iyi olur *ÖNERİ* (yine de, VRFY için Normal Yanıt ve VRFY, EXPN ve Güvenlik bölümlerine bakınız).

VRFY komutu için dizge bir kullanıcı ismi veya bir kullanıcı ismi ve alandır (aşağıya bakınız). Eğer normal bir yanıt (250 gibi) geliyorsa, yanıt kullanıcının posta kutusunu içermek zorundayken *ZORUNLU* kullanıcının tam ismini de içerebilir *SEÇİMLİK*. Dizge şu biçimlerden biri olmalıdır *ZORUNLU*:

    Kullanıcının Adı ve Soyadı <yerel-kısım@alan>
    yerel-kısım@alan

VRFY komutunun bağımsız değişkeni olan isim birden fazla posta kutusunu betimleyebildiği takdirde, sunucu ya belirsizliğe dikkat çeker ya da başka olasılıklar belirtir *SEÇİMLİK*. Başka bir deyişle, VRFY komutunun meşru yanıtı şunlardan birinin benzeri olabilir:

553 User ambiguous  // 553 Kullanıcı belirsiz

veya

553- Ambiguous;  Possibilities are  // 553- Belirsizlik; Olasılıklar:
553-Joe Smith <jsmith@foo.com>
553-Harry Smith <hsmith@foo.com>
553 Melvin Smith <dweep@foo.com>

ya da

553-Ambiguous;  Possibilities
553- <jsmith@foo.com>
553- <hsmith@foo.com>
553 <dweep@foo.com>

Normal şartlar altında, bir 553 yanıtı alan bir istemcinin kullanıcıya sonucu açıklamaması beklenir. Tam olarak belirtilen biçimlerin ve [34]'te açıklandığı gibi ek yanıt kodları tarafından ilave olarak "user ambiguous" veya "ambiguous" anahtar sözcüklerinin olası kullanımı, gerektiğinde diğer dillere özdevinimli çeviriyi kolaylaştıracaktır. Şüphesiz, oldukça özdevinimli hale getirilmiş ya da İngilizce'den farklı bir dilde işlem yapan bir istemci, yanıtın içerdiği metni olduğu gibi kullanıcıya yansıtmak yerine yanıtı tercüme etmeyi veya kullanıcıya durumu raporlamadan önce ek bilgi için bir sözlük hizmetine başvurulması gibi özdevinimli eylemlerden birini yapmayı tercih ederdi.

EXPN komutu için dizge bir postalama listesidir ve başarılı (250 gibi) bir çok satırlı yanıt postalama listesindeki posta kutularının listesini içermeli *ZORUNLU* iken, bu liste kullanıcılarının ad ve soyadlarını da içerebilir *SEÇİMLİK*.

Bazı konaklarda, bir posta kutusu ile tek bir posta kutusunun rumuzu arasındaki fark, her iki girdi türü için ortak bir veri yapısı kullanıldığından, bulanıktır ve sadece tek bir posta kutusu içeren postalama listelerinin varlığı olasıdır. Bir postalama listesine VRFY uygulayacak bir istek yapılmışsa, iletinin listedeki herkese teslimi şeklinde adreslenmiş olması durumunda bir olumlu yanıt verilebilir *SEÇİMLİK*, aksi takdirde bir hata raporlanırsa iyi olur *ÖNERİ* ("550 bu bir postalama listesi adresidir, bir kullanıcı adresi değildir" veya "252 Posta listesi üyelerini doğrulamaya izin verilmiyor" gibi bir hata raporu). Eğer bir kullanıcı ismini açan bir istek yapılmışsa tek bir isim içeren bir listeden oluşan olumlu bir yanıt verilebileceği gibi bir hata da raporlanabilir *SEÇİMLİK* ("550 bu bir kullanıcı adresidir, bir postalama listesi adresi değildir" gibi bir hata raporu).

Başarılı bir çok satırlı cevap (EXPN için normal olan) durumunda yanıtın her satırında tam olarak bir posta kutusu belirtilir. Belirsiz bir istek yapılması durumundan yukarıda bahsedilmişti.

"Kullanıcı adı" bulanık bir terimdir ve tedbirli kullanılmıştır. VRFY veya EXPN komutlarının gerçeklenimi en azından "kullanıcı adları" olarak yerel posta kutularını tanımayı içermelidir *ZORUNLU*. Şu an ki Genel Ağ uygulaması sıklıkla çok sayıda alanın postasıyla tek bir konağın ilgilenmesi sonucunu doğurduğundan, konaklar, özellikle de bu işlevselliği sağlayan konakların, bir "kullanıcı ismi" olarak "yerel-kısım@alan" biçimini kabul etmeleri iyi olur *ÖNERİ*; bu konaklar ek olarak "kullanıcı isimleri" olarak başka dizgeleri tanımayı tercih edebilir *SEÇİMLİK*.

Bir çok satırlı yanıt gerektiren bir posta kutusu listesinin açılımı durumu şöyle örneklenebilir:

İ: EXPN Numune-Topluluk
S:  250-Jon Postel <Postel@isi.edu>
S:  250-Fred Fonebone <Fonebone@physics.foo-u.edu>
S:  250 Sam Q. Smith <SQSmith@ozellikle.genel.com>

veya

İ: EXPN imtiyaz-sevenler-listesi
S:  550 Size Erisim Yasak.

VRFY ve EXPN komutlarının karakter dizisi bağımsız değişkenleri kullanıcı adı ve posta kutusu listesi kavramlarının gerçeklenimlerinin çeşitliliğine bağlı olarak daha fazla kısıtlanamaz. Bazı sistemlerde EXPN komutunun bağımsız değişkeni bir postalama listesi içeren bir dosyanın adı olabilir, ama tekrar belitelim ki, Genel Ağ'da dosya isimlendirme uzlaşımları çeşitliliği vardır. Bu komutlardaki tarihsel farklılıklar nedeniyle elde edilen sonuçlar çok dikkatli yorumlanmalı *ÖNERİ* ve sadece sorun teşhisi için kullanılmalıdır *ÖNERİ*.

Bir VRFY veya EXPN isteğinden normal yanıt (2yz veya 551) döndüğünde, yanıt normal olarak "<yerel-kısım@alan>" gibi bir posta kutusu ismi içerir; burada "alan" tamamen nitelikli alan adı olup sözdizimi içinde görünmelidir *ZORUNLU*. Bu belirtimin niyetine karşı çıkmayı haklı gösterecek kadar olağanüstü durumlarda, serbest biçimli metin döndürülebilir *SEÇİMLİK*. Hem bilgisayarlar hem de insanlar tarafından çözümlemeyi kolaylaştırmak için adresler "<" ve ">" arasında olmalıdır *ÖNERİ*. Serbest biçimli hata ayıklama bilgisi değil de adresler döndürüldüğünde, EXPN ve VRFY komutları sadece SMTP RCPT komutlarında kullanılabilen geçerli alan adreslerini döndürmelidir *ZORUNLU*. Bu sebepten, eğer bir adres, teslimatın bir programa veya başka bir sisteme yapılacağı anlamına gelecekse, bu hedefe erişmekte kullanılan posta kutusu ismi belirtilmelidir *ZORUNLU*. Yollar (açıkça kaynak rotaları) EXPN veya VRFY komutundan döndürülmemelidir *ZORUNLU*.

Sunucu gerçeklenimleri VRFY ve EXPN komutlarının ikisine de destek vermelidir *ÖNERİ*. Güvenlik kaygılarıyla, gerçeklenimler, yapılandırma seçenekleri veya eşdeğerleri üzerinden bu komutların biri veya her ikisinin de iptal edilebileceği yerel kurulumları sağlayabilir *SEÇİMLİK*. Bu komutlar desteklendiğinde, röle desteği de varsa, bu komutların rölelerle çalışmaları gerekli değildir. RFC 821'de bunların her ikisi de seçimlik olduğundan, bunlar destekleniyorsa, bir EHLO yanıtında hizmet eklentileri olarak listelenmeleri gerekir *ZORUNLU*.

Bir sunucu, adresi gerçekten doğrulamadıkça, bir VRFY veya EXPN komutuna yanıt olarak bir 250 kodu döndürmemelidir *ZORUNLU*. Bilhassa, sunucunun yaptığı tek iş verilen sözdiziminin geçerliliğini doğrulamaksa bir 250 kodu döndürmemelidir *ZORUNLU*. Bu durumda, 502 (Komut gerçeklenmedi) veya 500 kodu (Sözdizimi hatası, komut anlaşılamadı) döndürmelidir *ÖNERİ*. Başka bir yerde de belirtildiği gibi, VRFY ve EXPN gerçeklenimi (adreslerin gerçekten doğrulanması ve bilgi döndürülmesi anlamında) hararetle önerilmektedir. Bu sebepten, VRFY için 500 veya 502 döndüren gerçeklenimler bu belirtimle tam uyumlu değildir.

Özellikle bir sunucunun, bir alan ya da başka bir sunucu için posta aktarımcı olarak çalıştığı durumda bir adresin doğru gibi göründüğü ama gerçekte sebepsizce doğrulanamadığı durumlar olabilir. Bu durumdaki "Görünen Doğruluk" normalde en azınan sözdizimi denetimi özelliğini ve kimi zaman, belirtilen alanların postayı röleleleyebileceği umulan konaklar olduklarını doğrulayabilme özelliğini ihtiva eder. Bu durumlarda, 252 yanıt kodu döndürülmelidir *ÖNERİ*. Bu durumlar Temel Yapı bölümünde bahsedilen RCPT doğrulama konusuyla paraleldir. Benzer olarak, Adres Düzeltmek veya Güncellemek için Yönlendirme bölümünde bahsedilen uygulama, adreslerin tanındığını ama onlar için alınan postanın sevkedildiğini veya geri gönderildiğini belirten VRFY (ve EXPN) komutlu 251 ve 551 yanıt kodlarına uygulanır. Gerçeklenimler genelde biraz daha uzun sürecek olsa bile VRFY durumunda adres doğrulama ile ilgili olarak RCPT durumuna oranla daha fazla girişken olmalıdır *ÖNERİ*.

EXPN komutu çoğunlukla postalama listeleri ve çok sayıda hedef adresi belirten rumuzlarla ilgili sorunların anlaşılması ve hatalarının ayıklanması için çok yararlıdır. Bazı sistemler yinelenenleri ayıklamak için posta listelerinin kaynak yorumlamasını kullanmayı denediler. Rumuzlama sistemlerinin Genel Ağ'da posta ile etkileşimi, bu stratejilerin konaklar (genelde MX ve CNAME DNS kayıtları), posta kutuları (yerel konak rumuzlarının çeşitli türleri) ve çeşitli vekil düzenlemeleri açısından tutarlı çalışmasını neredeyse imkansız hale getirmiştir ve posta sistemleri bunlara yeltenmemelidir *ÖNERİ*.