E-postalarım spam olarak bile gönderilmez, ancak alınmazsa hangi tanılama adımlarını yapabilirim?

Diğer alıcılara gönderilen e-postaların iyi çalıştığı sırada, belirli alıcılara gönderilen tüm e-postaların spam olarak bile olsa, hiçbir hata göndermediği ancak asla ulaşmadığı bir sorunum var. Yorgunum ve neler olduğunu teşhis etmenin yollarını arıyorum.

• Geçen hafta bir istemciye Outlook 2016'dan bazı e-postalar gönderdim. Artık alınmadığını gördüm. Alan adlarında başkalarına e-posta göndermeyi denedim ve hiçbiri e-postalarımı almıyor gibi görünüyor, ancak diğer alanlardaki diğerleri
• "Gönderilmiş" klasörümü kontrol ettim ve gönderilen tüm postalarla aynı görünüyorlar. Hiçbir teslim raporu veya benzer bir şey vardı ve onlar "giden" klasörde "giden" değil. Ben de bu insanlara son e-postalarımı kendim CCing denedim - kesinlikle gönderir.
• Söz konusu müşteriyle görüştüm ve spam klasöründe bile benden hiçbir şey almadılar . Onlardan e-posta alabilirim, ancak benden hiçbir şey almıyorlar - hatta e-postalarına verdiğim cevapları bile.
• İlk e-postada iki küçük (500kb) PDF eki vardı, ancak aynı kader eki olmayan takip e-postaları geldi. Hiçbir e-postada resim veya bağlantı yok. Bunlar, geçmişte aynı e-posta adresi ve Outlook aracılığıyla e-posta alışverişi yaptığım bir ve üç kişiye normal işle ilgili e-postalardı. Onlar da benimle aynı ülkede.
• Teslimat hatası yanıtı veya benzeri bir şey yoktu. Bu tür ilk e-posta geçen Cuma günü sabah 8: 55'te gönderildi, bu yüzden 5 gün önce ve yanımda veya onların hiçbir şey alınmadı.
• Bana gelen e-postaları iyi geliyor - ve aslında, başarısız olan ilk e-postalarım kendi e-postalarına cevaplardı. Ayrıca, bu etki alanına iki hafta önce normal şekilde alınan e-postalarım oldu.

• Bu etki alanına çeşitli test e-postaları denedim ve hiçbir şey geçmiyor:

  • "Bu bir test e-postasıdır" diyen masum e-postalar ve benzeri asla gelmez
  • Webmail ve Android posta uygulamamdan gelen e-postalar Outlook'tan gelen e-postalarla aynı şekilde gelmez (ve ayrıca teslim raporları vermez - her şey sessizce başarısız olur)
  • Telefonumun 3G'sini kullanarak gönderilen e-postalar, WiFi'm kullanılarak gönderilen e-postalarla aynı kadere sahip
  • Ayrıca aynı etki alanında yeni bir e-posta hesabı oluşturdum (örneğin test@my-domain.comher zamanki adımın yanına gitmek için my-name@my-domain.com) ve tam olarak aynı sorunu yaşadım (webmail kullanılarak test edildi).
  • Geri dönen teslimat alıcılarını engelleyen bir çeşit karmaşa SMTP ayarına sahip olup olmadığımı test etmek için, hg1ugtvr34vrgfrt2t@ashfrlwejbtlwerhtklhejtkghwerkbjhrw.com adresine muhtemelen mevcut olmadığını gösteren bir e-posta gönderdim. Tamamen normal bir "Posta teslimi başarısız oldu: gönderene mesaj döndürme" geri dönme aldım - bu yüzden geri dönme alabiliyorum, sadece bir nedenle bu alan adından gönderilmiyorum.
  • Örneğin kişisel Gmail hesabımdan onlara gönderilen e-postalar iyi durumda (bu yüzden bu sorun çözülene kadar bunu kullanıyorum)

E-posta kendi etki alanımdan geliyor - Aynı e-posta adresinden ve aynı Outlook'tan diğer kişilere e-posta gönderdim ve para cezası aldılar. Gmail ara sıra onları spam olarak işaretler, bu da aradığım bir şeydir, ancak diğer istemcilerde sorun yoktur.

Bunun dışında devam edecek hiçbir şey göremiyorum. Emin yani benim sorunu teşhis için buraya yetmezse değilim ben bir çözüm değil soruyorum ama için tanı adımlarla ı alabilir örneğin,:

• Outlook'ta gönderebileceğim bir rapor veya günlük gibi "başlık altında" bir şey var mı?
• İlgili olabilecek herhangi bir sunucu veya etki alanı ile ilgili günlük türü var mı? Alan adım, Centos VPS'deki bir SMTP sunucusuna atanmış.
• Bilmem ve kontrol etmem gereken herhangi bir kara liste veya güvenlik müdahalesi türü var mı, bir e-postanın spam klasörüne bile ulaşmamasına neden olur mu?

Bu soruyu, e-postaların bazı insanlar tarafından alınmadığını gördüm , bu benzer ancak iki farklılıkla:

• Toplu posta sistemi kullanıyorlar, düzenli Outlook kullanıyorum, her seferinde bir e-posta.
• Kabul edilen cevap greylisteyi suçluyor - ancak, ilk eksik e- postam geçen Cuma (beş gün önce) idi ve görünüşte greylistesi e-postaları 15 dakika ile "birkaç gün" arasında geciktiriyor.

Tyson'ın önerdiği gibi, http://mxtoolbox.com/ denedim ama maalesef herhangi bir ipucu vermedi (en azından görebildiğim herhangi bir ipucu değil). Bir şeyi kaçırmam durumunda, sonuçlar şöyle:

Kara liste kontrolü

Bilinen 95 kara listeye karşı XX.XX.XX.XX kontrol ediliyor ...

1 zaman aşımı ile 0 kez listelendi

[listenin sonunda bir sürü yeşil keneler:]

TIMEOUT IPrange RBL Project [response time:] 0

Yani bilinen herhangi bir kara listede yok. IPrange RBL kontrolünün neden başarısız olduğunu bilmiyorum, ancak http://iprange.net/rbl/lookup/ adresinden manuel olarak kontrol ettim ve orada da kara listeye alınmadım.

SMTP kontrolü:

Bu yüzden bağlantı süresi biraz yavaş (neden olduğundan emin değilim, buna bakacağım), ancak bunun neden gönderilen postaların bazen tamamen ortadan kalkmasına neden olacağını anlamıyorum.

http://intodns.com, alan adımın tüm MX denetimleri için sürekli yeşil onay işaretleri veriyor.

(Centos / Linux) sunucusundaki günlük dosyalarına göz atmayı denedim:

• /var/log/maillog- bunların hepsi boş. Bunların sendmail günlükleri olduğuna inanıyorum ve şu anda sendmail kullanmıyorum, bu yüzden mantıklı.
• /var/log/exim/reject.logreddedilen kaba kuvvet girişimleriyle doludur dovecot. Denedim fail2banve durdurabileceklerini görmek için güvenlik duvarı ayarlarımı vb. Kontrol etmeye devam edeceğim, ancak bunun ilgili olduğunu düşünmüyorum
• /var/log/exim/main.log ayrıca birçok reddedilen kaba kuvvet girişimi içerir, ancak gerçek gönderilen bazı e-postaların kayıtlarını da içerir:

İşte aynı alandaki üç kişiye de başarısız olan üç kişiye bir e-posta (bazı alfasayısal dizeleri düzenledim ve IP adreslerini TXT.LIKE.TH.IS ile değiştirdim):

2016-02-12 08:55:41 no host name found for IP address MY.PC'S.IP.ADR
2016-02-12 08:55:49 1aU9Vw-0004vq-EG <= me@my-domain.com H=(MyPCName) [MY.PC'S.IP.ADR] P=esmtpa A=dovecot_login:me@my-domain.com S=1443429 id=000001d17563$920b5cf0$7b1622d0$@my-domain.com
2016-02-12 08:55:51 1aU9Vw-0004vq-EG => alice.domain@receives-nothing.org <alice.domain@receives-nothing.org> R=dnslookup T=remote_smtp H=cluster5.us.messagelabs.com [US.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:55:51 1aU9Vw-0004vq-EG -> brian.domain@receives-nothing.org <bob.domain@receives-nothing.org> R=dnslookup T=remote_smtp H=cluster5.us.messagelabs.com [US.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:55:51 1aU9Vw-0004vq-EG -> carol.domain@receives-nothing.org <carol.domain@receives-nothing.org> R=dnslookup T=remote_smtp H=cluster5.us.messagelabs.com [US.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:55:51 1aU9Vw-0004vq-EG Completed

Başarılı olan bir kişiye e-posta (alıcı tarafından alındı):

2016-02-12 08:58:20 no host name found for IP address MY.PC'S.IP.ADR
2016-02-12 08:58:23 1aU9YU-0004w0-IN <= me@my-domain.com H=(MyPCName) [MY.PC'S.IP.ADR] P=esmtpa A=dovecot_login:me@my-domain.com S=23133 id=003101d61537$874b04a0$59e01ed0$@my-domain.com
2016-02-12 08:58:26 1aU9YU-0004w0-IN => zak.receives@email-normally.org <zak.receives@email-normally.org> R=dnslookup T=remote_smtp H=cluster4.eu.messagelabs.com [UK.IP.ADR.ESS] X=UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256
2016-02-12 08:58:26 1aU9YU-0004w0-IN Completed

İkisi arasında önemli bir fark göremiyorum. Her ikisi de önce ve sonra kaba kuvvet enkazı ve diğer e-postalardan başka bir şey değildir.

Ben önemi bilmiyorum cluster5.us.messagelabs.comya cluster4.eu.messagelabs.com, ama ilişkili IP adresleri hem MessageLabs IP adresleridir.

Googling messagelabs.com, alakalı görünen ve her iki müşterimin de (birlikte) MessageLabs abonesi olduğunu öne süren bu blog makalesini ortaya çıkardı , ancak önemli farklılıklar için a) yazarın aksine teslimat yapmıyorum bile makbuz ve b) e-postalarımı engelleyen MessageLabs olsaydı, neden bir müşterisi için değil, diğeri için engellemiş olduğunu anlamıyorum.

E-posta sorunlarını giderme "gönderen" ve "alıcı" sorunlarına ayrılabilir. Başkalarına gönderebildiğiniz için Gönderen taraf muhtemelen iyi çalışıyor. Sorunu bulmak için Alıcı tarafını araştırmanız gerekir.

Günlüklere bakmak iyi bir adımdır ve mesajlarınızın nereye ulaştığını ve nerede olmadıklarını size söyleyebilir. Normal e-posta akışı şu şekilde olur:

1. E-posta yazılımınızdan sunucunuza gönderiyorsunuz

2. Sunucunuz sunucularına gönderir

3. Sunucuları e-posta istemcilerine gönderir

Bu durumda, günlüklerinin sunucusunun göründüğünü görebilirsiniz

cluster5.us.messagelabs.com

Messagelabs, şimdi Symantec'e ait olan bir e-posta filtreleme hizmetidir. Bunun gibi ileti filtreleme hizmetleri , iletiler istemci yazılımına gönderilmeden önce tüm spam ve önemsiz e-postaları kaldırmak için kullanılır . Bu, mesaj etiketleri tarafından engellenen iletilerin istemci yazılımındaki spam veya önemsiz e-posta klasörlerinde açılmayacağı anlamına gelir. Sadece kaybolacaklar ve alıcı hiçbir zaman hiçbir işaret görmeyecek. Nadiren de olsa "birisi@example.com'dan gelen bir ileti engellendi." Engelini kaldırmak için BT departmanınıza başvurun "şeklinde bir mesaj alabilirler.

Bu, burada olanlara çok benziyor. Teknik olarak, gönderdiğiniz bağlantıdaki adam gibi mesaj etiketlerinden hemen yanıt almalısınız, ancak bu garanti edilmez. Spam olduğunu düşünüyorlarsa iletinizi sessizce silebilirler. Genellikle mesaj etiketleri, müşterilerinin BT departmanına engellenen mesajların yayınlanabileceği bir arayüz sağlar. Şirketteki kişinizden e-posta adresinizden engellenmiş mesaj olup olmadığını BT ekibinden kontrol etmesini isteyebilirsiniz. En azından onlarla iletişime geçmenin başka bir yolu varsa yapabilirsin!

Diğer yararlı genel sorun giderme adımları: Günlük dosyalarına erişiminiz yoksa, "MX kayıtları" na bakarak sunucunun herhangi bir etki alanı için ne olması gerektiğini öğrenebilirsiniz.

Örneğin burada: http://mxtoolbox.com/

MX kaydı, e-postanızı nereye göndereceklerini öğrenmek için bir e-posta sunucusunun aradığı şeydir.

Daha sonra, e-posta kabul edip etmediğini ve hangi hata mesajlarını alabileceğinizi görmek için mx kaydında listelenen sunucuya manuel bağlantı başlatabilirsiniz. Putty: http://www.putty.org/ gibi bir telnet programı ve 25 numaralı bağlantı noktasındaki e-posta sunucusuna telnet kullanın. Gereksinim duyacağınız bazı komutlar burada listelenmiştir: http://www.yuki-onna.co. uk / e-posta / smtp.html

Artık posta sunucularına bağlanabilir ve e-posta adresinizi "Kimden" adresi olarak kullanarak bir e-posta gönderebilir ve sunucunun doğrudan nasıl yanıt verdiğini görebilirsiniz. Döndürülen tüm e-posta hata kodları google'da veya burada aranabilir: http://www.serversmtp.com/en/smtp-error

Sunucuya bağlanıp bağlanamadığınızı kontrol ettikten sonra, e-postanızın neden spam olarak veya başka bir nedenle reddedildiğini söyleyebilir, ancak bunun nedenini çözmek kolay olmayabilir. Bu aşamada, mesaj etiketleri müşterilerinden, sunucularından aldığınız hata kodları (veya bunların eksikliği) ile destek numaralarıyla iletişim kurmasını istemenizi öneririm. İleti etiketlerinin müşterisi olmadığınız için, bir sorunu kaydedemez veya ileti etiketlerinden müşterinin hesabındaki ayarları kontrol etmesini isteyemezsiniz. Müşterileri bunu kendileri sormak zorunda kalacaklar. Bu, diğer posta filtreleme sağlayıcıları için benzerdir.

Umarım hata kodu, sunucunuzun bir blok listesinde listelenmesi veya bir SPF kaydının olmaması gibi belirli bir soruna işaret eder ve üçüncü eldeki bir posta filtreleme sağlayıcısıyla uğraşmak asla eğlenceli olmadığından bunu kendiniz düzeltebilirsiniz. Bu gibi son sorun, hata bulunmadan ve mesaj etiketleri düzeltmeden önce çözmek için üç ay sürdü.

Ben benden çok daha bilgili gibi görünüyor çünkü SPF ve DKIM ayarları hakkında ayrıntılar için kubanczyk tarafından cevap erteleyeceğim!

İyi şanslar!

Giden SMTP günlükleriniz, hedefin iletiyi kabul ettiğini gösterir. Hedef posta sunucusu herhangi bir nedenle geri dönme gönderecek kadar nazikse, elde ettiğiniz tek şey budur. Müşteriye e-postaya ne olduğunu (kim bilmeyebilir) sormanın yanı sıra, tahmin dışında yapabileceğiniz çok şey yok. İstemciden aldığınız bir iletideki aktarım başlıklarına da bakabilirsiniz.

İşte MessageLabs çözümü için bir ürün veri sayfası (sayfa 2'deki kontrol işlemlerine bakın)

Bu nedenle, bu müşterinin posta sistemi, postaları engellemek, reddetmek, değiştirmek, filtrelemek, taramak, yeniden yönlendirmek vb.

1. Aktarım başlıkları (Bu mesaj başka bir ürün tarafından tarandı mı? Şifreleme için işaretlendi mi? İmzalı mı? Kaynak posta sistemine güveniyor muyum?)
2. Alıcılar (Kimin kime e-posta göndermesine izin verilir?)
3. Konu, ek kısıtlamaları (Konudaki 'V1AGArA' var mı? .Exe içeriyor mu?)
4. Metinde kısıtlanmış anahtar kelimeler mi var?
5. Mesajın metni sınıflandırıldı mı? (Bu mesaj küfürlü olarak işaretlendi mi? PII içeriyor mu?)

Liste uzayıp gidiyor. MessageLab'ın teklifine tamamen aşina değilim, ancak büyük bankanın uyumluluğunun, yönetişiminin, riskinin ve BT güvenlik departmanlarının sevdiği benzer bir ürünle çalışıyorum, çünkü bu departmanların filtreleme, denetleme, arşivleme, inceleme, analiz etme, kategorize etme, engelleme son derece ayrıntılı bir ayrıntıya sahip posta. Müşterilerimizin çoğunun yasal olarak aşağıdaki gibi ortak şeyler yapması gerekir:

1. Mesajı gözden geçirmek ve onaylamak için şeffaf bir şekilde şirketin hukuk ekibine yönlendirerek finansal düzenlemeleri potansiyel olarak ihlal edebilecek gelen ve giden postaları karantinaya alın.
2. Gelen veya giden iletilerdeki katılımcıları iletinin içeriğine göre yeniden yazın.
3. İçeriğe veya anahtar kelimelere göre iletiyi belirli posta kutularından engelleme
4. Belge analizine dayanarak mesajın bölümlerini yeniden düzenleme ve yeniden yazma
5. Ek kısıtlamalar uygulayın ve bölgeye göre eylemleri kontrol edin . Bir örnek, bir müşterimin sahip olduğu ITAR düzenlemelerinden kaynaklanır. Belirli coğrafi bölgelerden gelen tüm e-postaların, son kullanıcı posta kutularına ulaşmak için el ile onay gerektiren büyük posta hacmi alt kümeleriyle uygulanan fazladan derin içerik analiz politikalarına sahip olması gerekiyordu.

Ve elbette, kurumsal e-postada herhangi bir şey olabileceğinden ve olacağından, hedef posta sunucusunun her zaman mesajınızı atması ve rölenize bir 200 OKveya 250 COMPLETEDyanıt vermesi olasılığı her zaman vardır . Bu olur ... black holeRogue routing döngülerini ortadan kaldırmak için mail rölelerini mail rölesine yönlendirecek şekilde konfigüre eden bazı müşteriler biliyorum . Kurumsal posta her zaman eğlencelidir :)

Güncelleme: Bu cevap, herhangi bir e-posta hakkında bir teşhis raporu almanın bir yolunu açıklar (e-postaların içeriği, başlıkları ve sunucu kurulumu). Sunucu ayarlarımı iyileştirmek için çok yararlı olsa da, maalesef burada ortaya çıkan her şeyi düzelttikten sonra bile, e-postalarım hala geçmiyor. Bunu burada bırakacağım çünkü diğerleri benden daha fazla şansa sahip olabilir.

Birkaç ücretsiz çevrimiçi e-posta test hizmeti buldum. Bir kerelik bir e-posta adresi oluştururlar, bir e-posta gönderir ve ardından bir bağlantıyı tıklatırsınız ve bilinen çeşitli spam filtrelerinin bu e-postayı nasıl derecelendireceği hakkında bir rapor verir.

Genellikle haber bültenlerini test etmek için tasarlanmışlardır, ancak amacım için uygundur.

Hangisini deneyeceğimi bilmiyordum, ama ilk denediğim - https://www.mail-tester.com/ - yararlı sonuçlar verdi.

test@my-domain.comBunlar için yanlış bir e-posta hesabı kullandım , çünkü e-posta hesaplarını spam için test etmek için ücretsiz bir hizmete sahip olmak, daha sonra bu e-posta hesaplarını spam listelerine satmak çok açık bir iş modeli ... :-)

Rapor bana takip etmem için faydalı ipuçları verdi. İşte onların kararı:

Fena değil. Bazı gelen kutuları yine de sizi reddedebilir

5/10

Ve teşhislerinin bir ekran görüntüsü:

("gövde mesajı hatalar içeriyor" göründüğü kadar kötü değil, sadece abonelikten çıkma bağlantısı olmadığına işaret ediyor, çünkü tamamen bir haber bültenini test ettiğimi varsayıyor)

Aradığım şey buydu: Herhangi bir başarısız teslimat bildirimi olmadan denemek ve düzeltmek için eyleme geçirilebilir şeyler.

Şimdi e-posta adreslerimin posta sunucusu ana bilgisayar adı mail.my-domain.com yerine ana VPS ana bilgisayar adını vps.alanadim.com'u neden gösterdiğini ve neden ayarladığım SPF girişlerinin nedenini araştıracağım. aylar önce ve hangi MX araçlarının iyi olduğunu söylediler - tam olarak propogasyona geçmediler.

Bu özellikle benim özel sorunumun köküne benziyor: bazı yapılandırmaların ilgisiz olduğunu düşünen ve bazılarının balık olduğunu düşünen sunucu yapılandırmasının tuhaflığı:

Güncelleme...

Kötü haber ... Mail Tester raporunda ortaya çıkan tüm sorunları çözdüm (ilgilenen herkes için HELO adres sorunu ve SPF yayılım sorunu hakkında Sunucu Hatası sorularıma bakın ). E-postalarım şimdi Mail Tester'tan mükemmel bir 10/10 alıyor ...

Vaov! Mükemmel, gönderebilirsin

10/10

... ancak e-postalarım hala bu garip alan tarafından alınmıyor . Bir şekilde kuruluşa özel bir kara listeye eklenmiş olduğumu düşünmeye başladım (belki birisi "cevap" veya "arşiv" yerine yanlışlıkla "spam" düğmesine bastı ... bunun açıklayıp açıklamayacağından emin değil misiniz?) .

Burada vahşi tahminimi deneyeceğim. SPF ve DKIM kullandığınızı görüyorum. Bu nedenle DMARC kullanma olasılığı da vardır (özellikle MX'iniz exim oluyorsa).

Şimdi, postanızın receives-nothing.org adresine gitme şansı var ve orada bir geri dönen ileti (postanızı neden kabul edemediklerini gösteren bir iade postası) alıyorsunuz. Ancak, deneyimlerden bahsetmişken , başta büyük olanlar olmak üzere pek çok kuruluşun geri dönen mesajlar göndermek için ciddi mekanizmaları vardır . Özellikle, Lotus Domino çünkü kopya, yanlış DKIM'yı dışarı her seferinde düz gönderir sizin kendi iletide DKIM imzası aynen. Diğer daha ince hatalar da çok olma eğilimindedir.

Birçok geri dönen ileti SPF'de başarısız olur. (Teknik neden düzgün olarak MAIL FROM: <> 'a sahip olmaları ve EHLO'larıyla ilgili bir problemleri olabilir.) DMARC politikası varsa, bu onları sadece DKIM'de asılı bırakır, bu da çok fazla sorun yaşar. mantıken:

DMARC = (SPF veya DKIM) ve (Başlık kimliğinin hizalama kontrolü)

Bu nedenle, MX'inizdeki gelen postaları kontrol etmek için DMARC, DKIM, SPF'yi geçici olarak devre dışı bırakmayı deneyin . (Bu, DNS kayıtlarınızı yalnızca exim ayarlarınızı değiştirmemeniz gerektiği anlamına gelir.) Bunları postalayın ve hemen çıkma için birkaç saat bekleyin ve ardından DMARC, DKIM, SPF'yi yeniden etkinleştirin.

Genellikle posta sağlayıcıların bazı garip kuralları vardır ve kurallara uyan postaları otomatik olarak kaldırırlar.
Bu sorunu yaşadık:
Bir posta sağlayıcı aynı sokak adresinde başka bir şirket (spam posta gönderen) bulunduğu için postalarımızı sokak adresine göre sildi ...
Yani şunu yapardım:
- içerik (normal altbilginiz olmadan) ve posta kutunuza eklenmeden, postalarınızı almayan
=> Alınabiliyorsa, normal içeriğinizin bir kısmı "kötü" olarak işaretlenir
Her durumda eşinize ( (postalarınızı almayan)) sağlayıcı adı için tıklayın ve telefon hatlarını arayın.

Benzer bir sorunum vardı. Son kullanıcı, belirli bir harici e-postaya MSOutlook e-postasının hiçbir zaman görünmediğini söylüyor. E-postalar gönderilen öğelerindeydi. Asla teslim edilemedi. MSExchange, başka bir posta sistemine başarıyla teslim edildiğini gösterdi. Harici e-postayla gönderilen kullanıcı spam veya önemsiz postalarında görmedi.

Çözüm. Harici kullanıcının e-postası için önbelleğini temizledi. Bu kişiden alınan bir e-postadan kopyalanan ve yapıştırılan e-posta adresi ve şimdi çalışıyor. Git şekil.

Microsoft'un web sitesinde bu "bilgi" bulundu, umarım en azından biraz yardımcı olur. SOURCE => Outlook giden e-postalar alıcılar tarafından alınmıyor

SORU:

Kişiler Outlook üzerinden gönderdiğim e-postaları almıyor. Gönderilmiş klasörümde başarıyla gönderildiğini gösteriyorlar ve teslim edilemediğini belirten mesajlar almıyorum. Alıcılarımın spam veya önemsiz klasörlerinde bitmiyorlar.

CEVAP:

Bununla ilgili sorun yaşıyorsanız, Outlook 2007'de bir kişinin aynı sorunu yaşadığı ve bazı bağlantı noktası özelliklerini değiştirerek çözülen bir iş parçacığı vardır . Tüm kredi çözümünü yayınlayan OP, Lisa'ya gidiyor: =>

SORU:

Outlook 2007'yi Vista'da çalıştırma ... giden iletiler gitmiyor, ancak giden posta kutusunda "tamamlandı" deyin. Mesajlar muhataplar tarafından alınmıyor ve gönderilen klasörde görünmüyor. Bunun için bir düzeltme var mı? Sonraki bilgisayar bitti Windows 7, aynı program, sorun yok. Aynı ağa bağlanmış ve internet iyi.

CEVAP:

Outlook'ta yapılandırılan e-posta hesabı türü nedir (POP, IMAP, MAPI veya EXCHANGE)? Giden kutusunda e-postaları görüyor musunuz veya giden kutusunda mı kalıyor? Kendinize bir e-posta göndermeyi deneyin ve test e-postasını alıp alamayacağınızı kontrol edin. Ayrıca sistemi temiz önyükleme modunda önyükleyin ve ardından e-postayı göndermeyi ve kontrol etmeyi deneyin. Sistemi temiz önyükleme modunda önyüklemek için aşağıdaki bağlantıya bakın: http://support.microsoft.com/kb/929135 (uzun ayrıntılı prosedür.)

Not: Sorun çözüldükten sonra sistemi normal moda yeniden başlattığınızdan emin olun.