-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathrfc4408-s9.html
241 lines (241 loc) · 14.8 KB
/
rfc4408-s9.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="tr" xml:lang="tr">
<head>
<title>9. Etkilenimler</title>
<meta name="generator" content="DocBook XSL Stylesheets V-special (derived from DocBook XSL v1.79.1 for Turkish Linux Documentation Project by Nilgün Belma Bugüner - nilgun (at) tlbp.org.tr)" />
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" type="text/css" href="/style/nav.css" />
<link rel="icon" type="image/png" href="/images/belgeler-logo.png" />
<meta name="robots" content="index, follow" />
</head>
<body>
<header>
<div class="navbar">
<div style="width:33%" class="dropdown">
<button type="button" class="dropbtn" onclick="window.location.assign('rfc4408-s8.html')">Önceki</button>
<div class="dropdown-content">8. Makrolar</div>
</div>
<div style="width:34%" class="dropdown">
<button class="dropbtn">Yukarı</button>
<div class="dropdown-content">
<button type="button" class="dropbtn" onclick="window.location.assign('/index.html')">Baş Sayfa</button>
<button type="button" class="dropbtn" onclick="window.location.assign('/KiTAPLIK/index.html')">Kitaplık</button>
<button type="button" class="dropbtn" onclick="window.location.assign('aik.html')">Ana Başlık</button>
<button type="button" class="dropbtn" onclick="window.location.assign('rfc4408.html')">Üst Başlık</button>
</div>
</div>
<div style="width:33%" class="dropdown">
<button type="button" class="dropbtn" onclick="window.location.assign('rfc4408-sa.html')">Sonraki</button>
<div class="dropdown-content">10. Güvenlik Değerlendirmeleri</div>
</div>
</div>
</header>
<section class="mainpage">
<div class="crumbs">
<p> </p>
</div>
<section class="sect1" id="rfc4408-s9">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both">9. Etkilenimler</h2>
</div>
</div>
</div>
<p>
Bu bölümde Genel Ağ Epostasıyla ilgili çeşitli öğelere bu belgenin uygulanmasının belli başlı sonuçlarına anahatlarıyla değinilecektir. Bu belgenin bu tür öğelerin işlemleri üzerindeki bilinen etkileri konusunda okuyucunun aydınlanması amaçlanmıştır. Bu bölüm bir "nasıl" kılavuzu ya da bir "en iyi uygulamalar" belgesi değildir ve bu belgenin ışığında böyle öğelere neler yapılması gerektiğinin kapsamlı bir listesi değildir.
</p>
<p>
Bu bölüm, uyulması zorunlu bölümlerden biri değildir.
</p>
<section class="sect2" id="rfc4408-s91">
<div class="titlepage">
<div>
<div>
<h3 class="title">9.1. Gönderici Alanlar</h3>
</div>
</div>
</div>
<p>
Bu belirtimle uyumlu olmak isteyen alanların, alan isimlerini "HELO" ve "MAIL FROM" kimliklerinde kullanarak posta gönderebilecek konakları belirlemeleri gerekecektir. Böyle bir listenin hazırlanması, basitçe bir teknik alıştırmanın değil hem teknik hem de yönetimsel değerlendirmeler altında verilen kararların sonucu olarak ortaya çıkar.
</p>
<p>
"Mevcutların izlenmesi" mekanizmasını içeren kayıtlar yayınlamak yararlı olabilir. İsim sunucusunun günlüklerine bakarak kabaca bir liste üretilebilir. Örnek:
</p>
<pre class="literallayout monospaced">
v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
</pre>
</section>
<section class="sect2" id="rfc4408-s92">
<div class="titlepage">
<div>
<div>
<h3 class="title">9.2. Postalama Listeleri</h3>
</div>
</div>
</div>
<p>
Postalama listelerinin listeye gönderecekleri postayı nasıl teslim edeceklerini bilmeleri gerekir. Postalama listelerinin [<a class="xref" href="rfc4408-sd.html#rfc4408-RFC2821" title="Simple Mail Transfer Protocol">RFC2821</a>]'in <a class="xref" href="rfc2821-s3a.html" title="3.10. Postalama Listeleri ve Rumuzlar">Postalama Listeleri ve Rumuzlar</a> bölümünde ve [<a class="xref" href="rfc4408-sd.html#rfc4408-RFC1123" title="Requirements for Internet Hosts - Application and Support">RFC1123</a>]'ün 5.3.6. bölümündeki, dönüş yolunun listeyi yöneten şey veya şahsın posta kutusu olarak değiştirilmesi gereğini *ZORUNLU* belirten gereksinimlere uyması gerekir *ZORUNLU*. Dönüş yolunun değiştirilmesi gereğinin çok çeşitli ve uzun uzadıya giden sebepleri vardır, SPF bu gereksinime güç katar.
</p>
<p>
Uygulamada, halihazırda kullanımda olan hemen tüm postalama listesi yazılımları bu gereksinimi karşılamaktadır. Listeye erişimle ilgili sorunları saptayamayan veya belki de uyum sağlamayan postalama listelerinin kullanım alanı sınırlıdır. Tamamen tek bir alana dahili olarak hizmet sunan böyle listeler bu gereksinimden etkilenmezler.
</p>
</section>
<section class="sect2" id="rfc4408-s93">
<div class="titlepage">
<div>
<div>
<h3 class="title">9.3. Yönlendirme Hizmetleri ve Takma Adlar</h3>
</div>
</div>
</div>
<p>
Yönlendirme hizmetleri postayı harici bir posta kutusuna teslim edilmek üzere alırlar. Bu belgenin yazımı sırasında, böyle hizmetlerin genel uygulaması, postayı harici bir posta kutusuna teslim ederken iletinin özgün "MAIL FROM" kimliğini kullanmak şeklindedir. [<a class="xref" href="rfc4408-sd.html#rfc4408-RFC1123" title="Requirements for Internet Hosts - Application and Support">RFC1123</a>] ve [<a class="xref" href="rfc4408-sd.html#rfc4408-RFC2821" title="Simple Mail Transfer Protocol">RFC2821</a>] belirtimleri bu eylemi bir "posta listesi" değil, bir "takma ad" uygulaması olarak açıklarlar. Bu, harici posta kutusu MTA'sının böyle postaları yönlendirme hizmetinin bir konağı ile yaptığı bağlantıda göreceği ve dolayısıyla "MAIL FROM" kimliğinin genelde sınamayı aşamayacağı anlamına gelir.
</p>
<p>
Bu sorunu gidermekte kullanılabilen teknikler üç yerde olabilir.
</p>
<div class="orderedlist">
<ol class="orderedlist" type="1">
<li class="listitem">
<p>
Başta, eposta ilk gönderilirken.
</p>
<div class="orderedlist">
<ol class="orderedlist" type="1">
<li class="listitem">
<p>
Yönlendiricilerin IP adresi olabilecekler için "<code class="literal">Fail</code>" yerine "<code class="literal">Neutral</code>" sonuçlar verilebilir. Örnek:
</p>
<pre class="literallayout monospaced">
"v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
</pre>
<p>
Bu, bir anti-spam DNS karalistesinde bir sorguya sebep olur. Sadece, burada kayıtlı kaynaklardan gelen epostalara "Fail" sonucu verilebilir. Diğer epostalar, yönlendiricilerden gelenler de dahil olmak üzere "<code class="literal">Neutral</code>" sonucu alabilirler. Bilinen iyi kaynaklardan gelenler ayrıldıktan sonra DNS kara listelerine bakmak, bu listelerin hatalı kayıtlarından büyük oranda korunmayı sağlar.
</p>
</li>
<li class="listitem">
<p>
"MAIL FROM" kimliğindeki yerel kısım, postanın yetkili bir kaynaktan geldiğini şifreli biçimde belli eden ek bir bilgi içerebilir. Bu durumda şöyle bir SPF kaydı kullanılabilirdi:
</p>
<pre class="literallayout monospaced">
"v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
</pre>
<p>
Sonra da,özelleştirilmiş bir DNS sunucusu yerel kısmı doğrulayan _spf_verify alt alanını sunmaya ayarlanabilir. Bu ek bir DNS sorgusu gerektireceğinden, epostanın bilinen bir iyi kaynaktan gelmemesi sebebiyle reddedilmesi sözkonusu olduğunda bu ek sorgu yapılabilir.
</p>
<p>
Alan yaftalarındaki 63 karakterlik sınırdan dolayı, bu yaklaşım sadece, yerel kısım oluşturma şeması sadece azami 63 karakterlik yerel kısımların oluşturulacağını veya kırpılmış yerel kısımların gerektiği gibi işleneceğini garanti ediyorsa güvenilir olarak çalışır.
</p>
</li>
<li class="listitem">
<p>
Benzer şekilde, umulmadık IP adreslerinden gelen epostaya hız sınırlaması koyan özelleştirilmiş bir DNS sunucusu ayarlanabilir.
</p>
<pre class="literallayout monospaced">
"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
</pre>
</li>
<li class="listitem">
<p>
SPF, özel durumlarda kullanıcıya özgü kural oluşturmaya izin verir. Örneğin, bu SPF kaydı ve ona uygun isim kalıplı DNS kayıtları kullanılabilir:
</p>
<pre class="literallayout monospaced">
"v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
</pre>
</li>
</ol>
</div>
</li>
<li class="listitem">
<p>
Ortada, eposta yönlendirilirken.
</p>
<div class="orderedlist">
<ol class="orderedlist" type="1">
<li class="listitem">
<p>
Yönlendirme hizmetleri "MAIL FROM" kimliğini kendilerine göre yeniden yazarak sorunu çözümleyebilir. Bu, harici posta kutusundaki boş dönüş yollu postanın yönlendirme hizmeti tarafından yeniden boş dönüş yollu yapıldığı anlamına gelir. Yönlendirme hizmetinin parçası olarak özkaynak gereksinimleri ve karmaşıklığındaki çeşitliliğe bağlı olarak bunu yapan çeşitli şemalar vardır.
</p>
</li>
<li class="listitem">
<p>
Çok kullanılan MTA'ların birçoğu "takma ad" anlamsallığına, özgün takma ada "owner-" öneki getirerek ek bir takma isim oluşturan "postalama listesi" anlamsallığını verebilirler (örn, "friends: george@example.com, fred@example.org" takma adı, "owner-friends: localowner" şeklinde başka bir takma ad gerektirirdi).
</p>
</li>
</ol>
</div>
</li>
<li class="listitem">
<p>
Sonda, eposta alınırken.
</p>
<div class="orderedlist">
<ol class="orderedlist" type="1">
<li class="listitem">
<p>
Harici posta kutusunun sahibi yönlendirme hizmetine güvence vermek isterse, istemci konak, yönlendirme hizmetine ait olduğunda, harici posta kutusunun MTA'sının SPF sınamalarını atlamasını sağlayabilir.
</p>
</li>
<li class="listitem">
<p>
"HELO" kimliği gibi, diğer kimliklerle yapılan sınamalar başarısız olmuş bir "MAIL FROM" kimliği sınamasından sonra red öncesi ek bir sınama olarak kullanılabilir.
</p>
</li>
<li class="listitem">
<p>
Büyük alanlar için, alanın posta kutularının sahipleri tarafından kullanılan yönlendirme hizmetlerinin tam ve doğru bir listesini yapmak mümkün olmayabilir. Böyle durumlarda, genel olarak tanınan yönlendirme hizmetleri aklistelere kaydedilebilir.
</p>
</li>
</ol>
</div>
</li>
</ol>
</div>
</section>
<section class="sect2" id="rfc4408-s94">
<div class="titlepage">
<div>
<div>
<h3 class="title">9.4. Posta Hizmetleri</h3>
</div>
</div>
</div>
<p>
Üçüncü şahıs alanlara toptan posta göndermek gibi posta hizmetleri sunan hizmet sağlayıcılar, bu belgede açıklanan yetkilendirme sınaması ışığında kendi ayarlarını yapabilirler. "MAIL FROM" kimliği hizmet sağlayıcının alanını kullanan böyle bir eposta için kullanılmışsa, hizmet sağlayıcı sadece, gönderici konağının (varsa) kendi SPF kaydı tarafından yetkilendirilmesine ihtiyaç duyar.
</p>
<p>
"MAIL FROM" kimliği hizmet sağlayıcının alanını kullanmıyorsa, biraz daha dikkatli olmak gerekir. SPF kaydının biçimi dahilinde, üçüncü şahıs alanların kendi yararına posta göndermesi için hizmet sağlayıcınan MTA'sını yetkili kılacak birçok seçenek bulunmaktadır. Aynı MTA'yı kullanan çok çeşitli müşterileri olan ISP'ler gibi posta hizmeti sağlayıcıları çapraz-müşteri sahtekarlıklarından kaçınmayı sağlayacak adımları atmalıdırlar (bkz, <a class="xref" href="rfc4408-sa.html#rfc4408-sa4" title="10.4. Çapraz-Kullanıcı Sahtekarlığı">Çapraz-Kullanıcı Sahtekarlığı</a>).
</p>
</section>
<section class="sect2" id="rfc4408-s95">
<div class="titlepage">
<div>
<div>
<h3 class="title">9.5. MTA Röleleri</h3>
</div>
</div>
</div>
<p>
Yetkilendirme sınaması, bir epostanın alıcısı ve göndericisi arasında keyfi MTA röleleri kullanımına genel olarak imkan vermez.
</p>
<p>
Bir örgüt içinde, MTA röleleri etkin olarak konuşlandırılmış olabilir. Bununla birlikte, bu belgenin amaçları gereği, böyle röleler aslında şeffaf olmalı, SPF yetkilendirme sınaması da farklı alanların sınır MTA'ları arasındaki bir sınama olmalıdır.
</p>
<p>
Posta göndericiler için bu, SPF kayıtlarının, postayı Genel Ağ'a gönderen MTA'ları yetkilendirdiği anlamına gelir. Kendi aralarında posta alışverişi yapan dahili MTA'lar gibi, bunlar da kendi aralarında posta alışverişi yapan sınır MTA'lardır, şeklinde düşünülebilir.
</p>
<p>
Posta alıcıları, özellikle tüm ikincil MX'leri de içererek, sınır MTA'larda yetkilendirme sınaması yapmak isteyeceklerdir. Bu, SMTP oturumu sırasında DSN üretilmeksizin reddilerek başarısız olan postaya izin verir. Dahili MTA'lar bundan sonra yetkilendirme sınaması yapmazlar. Sınırdan başka bir yerde yetkilendirme sınaması yapmak için, iletiyi örgüte aktaran ilk konak saptanmalıdır. Böyle bir saptama için bilginin ileti başlığından çıkarılması zor olduğundan sınırdan başka bir yerde sınama yapılması önerilmez.
</p>
</section>
</section>
<footer>
<div align="center" class="footer">
<small>Bir <a href="http://belgeler.org.tr/">Linux Kitaplığı</a> Sayfası</small>
</div>
</footer>
</section>
</body>
</html>