Poort 465 is verouderd. 587 gebruiken dus. Het gebruik van (start)TLS heeft geen enkele invloed op spamscore.

Ik (TS) ben nogal ouderwets, maar bij mijn ouders laat ik alles staan zoals ik van de week heb ingesteld (volgens de instellingen van KPN).

Zelf (XS4All), gebruik ik nog wel poort 465 voor SMTP omdat ik het idee eng vind, dat de encryptie helemaal gestript kan worden op een onbetrouwbaar netwerk. En dat je mail wachtwoord dan zichtbaar is. Maar op spamfilters heeft het dus geen invloed. Dat is goed om te weten. (Wel vreemd omdat HTTPS wel invloed heeft op de ranking in zoekmachines boven HTTP, maar SMTP+TLS dus niet boven slechts SMTP op poort 25).

STARTTLS is uitgevonden om de server te dwingen een encrypted verbinding te starten, ook als je per ongeluk in je email client hebt gekozen voor een poort die normaal een unencrypted verbinding zou geven. Zo ben je dus redelijk verzekerd van een encrypted verbinding. (de server moet dan natuurlijk ook STARTTLS ondersteunen)
Helaas is hier wel een (aanvankelijk meestal onopgemerkte) MITM-aanval mogelijk.
Voorbeeld van MITM STARTTLS strippen:
https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/

Je kan ook zeggen: STARTTLS is voor leken die zelf niet doorhebben of ze encrypted of unencrypted mailen
en gewoon maar een poort gebruiken "die werkt". (in de zin dat ze er emails op kunnen verzenden of ontvangen)
En STARTTLS zorgt er dan wel voor dat de verbinding altijd encry?ed is (op servers die het ondersteunen).
Merk op dat STARTTLS niet automatisch betekent dat je altijd een TLS verbinding krijgt. SSL is ook mogelijk.
Wel ondersteunen er steeds minder mailservers SSL(v3).

Emailproviders kunnen er ook zelf voor zorgen dat er altijd een TLS encrypted verbinding wordt opgezet,
ook op een poort die eigenlijk niet voor TLS is bedoeld, en zonder dat je STARTTLS hoeft te gebruiken.
Ziggo krijgt het zelfs voor elkaar om een niet-officiële TLS poort ietsje veiliger te maken dan de officiële TLS poort.
(als dit tenminste nog steeds zo is; heb het nog geen jaar geleden eens onderzocht)

Voor SMTP (gebruikt voor verzenden van je emailberichten) heb je soms STARTTLS nodig.
Dat zit zo: vroeger gebruikte men aparte poorten voor SSL en TLS en unencrypted. Dat vond men op een gegeven moment een verspilling en nodeloos ingewikkeld. Het kan daarom ook voorkomen dat de SMTP poort (587) standaard unencrypted is, en dat je met STARTTLS een encrypted verbinding moet afdwingen. Maar andere mailservers gebruiken nog wat historisch gebruikelijk was, of beginnen standaard altijd een encrypted verbinding om hun klanten te beschermen.

Je kan daarom meestal het beste even bij je emailprovider opzoeken welke poorten zij waarvoor gebruiken.
Voor wat betreft KPN: https://www.kpn.com/faq/16722
Volgens die informatie hoef je niet beslist STARTTLS te gebruiken, maar kun je TLS/SSL op je emailcliënt instellen.
Dat heeft hier met het oog op MITM de voorkeur.

Voor wat betreft spam:
Vroeger had je poort 25, die werd veel gebruikt om spam te versturen (met eenvoudige smtp software die geen encryptie aan hoefde te kunnen) maar poort 25 kan je op de meeste provider-emailservers in Nederland al niet meer gebruiken.
Alleen mailservers die hebben gekozen voor een standaard unencrypted poort 587 ( waar je dus STARTTLS moet gebruiken om encryptie af te dwingen) accepteert nog unencrypted smtp, maar geeft dan bijna hetzelfde spamprobleem als poort 25. Vandaar zul je in Nederland niet veel grote emailservers zien die werken op unencrypted poort 587, want dat zou spam weer bevorderen.

Voor wat betreft het verschil in die headers van jou:
weet je zeker dat SSL/TLS is aangezet in je emailclient?

Ik (TS) kijk op mijn eigen computer in Thunderbird. En voor SMTP zijn er maar drie mogelijkheden:
- None
- STARTTLS
- SSL/TLS

Ik zie niet hoe ik dit verkeerd kan doen (en de eerste Received header van KPN laat ook zien dat het ingesteld is).

Dat STARTTLS is bedacht om een poort uit te sparen, dat wist ik niet. Lekker bezig die lui van de IETF ;-)

Het is een misvatting van anoniem 18:47 dat poort 587 door spammers misbruikt zou kunnen worden want er is *altijd* authenticatie nodig op poort 587, in tegenstelling tot poort 25.

Wat is de kans dat je op een mitm loopt als je binnen het KPN netwerk verbinding zoekt met de kpn mailserver? Staar je niet blind op risico's die er eigenlijk niet zijn.

Poort 25 is voor server server en hier kan TLS en STARTTLS afgedwongen worden. Poort 587 is voor de clients en hier is authenticatie altijd aan te bevelen. Op poort 25 moet je Relay niet toestaan en alles gaat door de spamfilters en controle op DKIM en DMARC als die aanwezig zijn.

Als ik zonder encryptie iets door poort 587 druk dan is er geen DKIM aanwezig en zo gemakkelijk te controleren als iemand de encryptie uitschakeld zoals hierboven is beschreven. Poort 587 is de gevaarlijkste poort en moet daarom goed worden afgeschermd.

Poort 25 is de standaard poort om email te ontvangen vanaf Internet, dus dat wordt vollop gebruikt, ook door alle Nederlandse providers. Poort 587 is in de eerste plaats bedoeld om mail van de gebruiker naar de mail server te transporteren, waarna de server het zal bezorgen op de bestemde plaats (meestal door een lookup van het MX record in DNS).

Uitgaande poort 25 wordt op eigen netwerken wel eens dichtgezet door beheerders in een poging om besmette clients te beletten spam te versturen zonder authenticatie. Besmette computers kunnen dan nog wel accountgegevens stelen om alsnog spam te bezorgen.

Een enkele beheerder denkt dat spam verstuurd wordt vanaf poort 25, maar dat is natuurlijk nonsens. Poort 25 is altijd de ontvangende poort, niet de verzendende.

Heb ik ook niet zo algemeen beweerd. Ik heb beweerd dat mailservers waar je unencrypted op poort 587 kan binnenkomen net zo gevoelig voor spam zouden zijn als poort 25, en dat dit een reden is om op geen enkele manier unencrypted verkeer toe te laten op poort 587, en dan heb je het gezeik met STARTTLS om een encrypted verbinding te forceren in plaats van unencrypted ook niet meer.
Maar maak je niet druk: dit soort mailservers uit de nieuwe bedeling heb ik hier in Nederland nog niet gezien. Het is maar even dat je het weet dat het wél mogelijk is om encrypted en unencrypted voortaan over één poort te doen, bijv. misschien als je elders een mailserver gebruikt.

Zo redeneren we niet in securityland.
Iemand die dit leest zou eens toegang tot haar KPN-mail willen hebben via een publiek wifipunt?
En ook in situaties waar je niet snel een MITM verwacht kan je het beste voor de meest zekere oplossing kiezen.
<if the shit hits the fan> weet je het maar nooit of je toch nog geraakt wordt.

Excuseer, ontvangen via poort 25 is inderdaad meestal niet het probleem. Daar heb je helemaal gelijk in.
Er zijn vooral beperkingen met je uitgaande verkeer over poort 25.
Bij Ziggo kun je bijv. over poort 25 alleen verbinding maken met de smtp server van Ziggo,
en niet rechtsreeks met andere smtp servers, tenzij via de smtpserver van Ziggo had ik begrepen?
https://tweakers.net/nieuws/73034/ziggo-blokkeert-alternatieve-smtp-servers-op-poort-25.html
Ik raad iedereen aan om hun provider te raadplegen voor de details als je dit wil weten voordat je er tegenaan loopt.
Vaak zetten providers het wel op internet.

Zie ook https://en.wikipedia.org/wiki/SMTP:
Deze quote protesteert ook meteen tegen de opmerking van Anoniem 2:28:
is dus niet waar.

Poort 25 kán best de verzendende poort zijn, tenzij de outgoing port 25 is geblokkeerd door je provider.
En daarom kan iemand die dit wil weten het beste zijn/haar provider raadplegen welke policy ze op dit gebied hebben.

Nee. Er wordt door mail servers onderling verbinding gelegd typisch vanaf een hogere poort (1024 en hoger) naar poort 25, niet specifiek vanaf poort 25. Poort 25 is voor ontvangen. Hetzelfde geldt voor mail client -> mail server communicatie naar poort 25.

Verder kan alles, applicaties kunnen met voldoende rechten zelf de zender poort kiezen. Je kunt bijvoorbeeld vanaf poort 80 je mail bezorgen naar poort 25.

Spam en "encrypted" hebben niks met elkaar te maken! Je kunt zowel spam als niet-spam encrypted of plain versturen.

@anoniem 16:31

Voor de duidelijkheid: poort 465 is *nooit* toegewezen door IANA als poort voor mail. Officieel heeft IANA de poort ook toegewezen aan iets heel anders (http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt,

urd 465 tcp URL Rendesvous Directory for [Toerless_Eckert] [Toerless_Eckert]
SSM
igmpv3lite 465 udp IGMP over UDP for SSM [Toerless_Eckert] [Toerless_Eckert]

Poort 587 vereist *altijd* authenticatie (zie de RFC). Poort 587 laat zowel starttls als tls toe, dat is dus geen enkele belemmering.

Kijk eens bij http://blog.mailgun.com/25-465-587-what-port-should-i-use/ of bij RFC2476.

En ja, we werken in het security gebied al tijden risk based. Het moet immers ook betaalbaar blijven.

Nietes! Ik heb in de geschiedenis nog nooit gehoord van een stad met minstens 25 poorten.

(of als je die hint niet begrijpt: we hadden het daar dus niet over mailverkeer tussen mailservers onderling, troel)

Voor de zekerheid: dat klopt niet. Poort 465 is wel degelijk toegewezen geweest aan SMTPS, deze toewijzing is
later vervallen nadat poort 587 als mail submission port was toegewezen en de inmiddels vrijgekomen poort is (veel)
later aan een andere service toegewezen. Wat waarschijnlijk niet zo handig was gezien het feit dat er de-facto
gebruik van poort 465 is (i.t.t. vele andere poorten die wel zijn toegewezen maar waarvan de achterliggende service
nooit op grote schaal in gebruik genomen is).
Door een service "deprecated" te verklaren krijg je het gebruik niet zomaar weg.

Er bestaat zoiets als "spam" maar ook "nog veel meer spam".
De ellende is ten eerste zoals eerder al gezegd dat je behalve met email ook met hele eenvoudige gratis smtp utilities al mailberichten kunt uitsturen, en ook met bots, en 2)
(bron: https://securitywatch.pcmag.com/spam/290791-port-25-block-stalls-spam-after-all)

Dus nee. Ik ben niet gek, ik ben een vliegtuig Whééééééééééééééééng.

Ah bedankt, zoiets wilde ik ook net antwoorden.
Email heeft een hele history achter de rug, en heeft in het begin zelfs met ftp gewerkt.
Poort 465 is ook een tijdje dé poort voor een encrypted verbinding op smtp geweest, en er zullen nog wel emailservers bestaan die poort 465 nog steeds gebruiken. (hangt zoals de meeste dingen af van kennis en plaatselijke gewoonten)

IANA presenteert het (aanbevolen) poortgebruik sinds 16 november 2017, maar wel met deze waarschuwing:


Lees bijv. wat https://www.sparkpost.com/blog/what-smtp-port/ schrijft over poort 465,
IANA heeft eerst poort 465 bestemd voor smtp encryptie (gebruikt door email) maar gaf die poort later een andere bestemming, zodat er een andere poort moest komen voor die smtp-functie, en dat werd poort 587.

"Maar toch", omdat het een korte tijd normaal was, bestaan er oude systemen die nog met poort 465 werken en
een aantal pagina's op internet adviseren in algemene zin ook nog steeds poort 465.
Maar men zou volgens IANA zou men daar nu port 465 daar niet meer voor moeten gebruiken, tenzij de applicatie het beslist nodig heeft. Want de officiële standaard poort om via een beveiligde (encrypted) verbinding iemand te mailen is dus tegenwoordig poort 587.

Lees het nog maar eens keer, maar nu helemaal.

En geef nou maar gewoon toe dat je niet begreep dat spam niet *vanaf* poort 25 wordt gestuurd. Aan misinformatie en diverse poging eruit te draaien heeft niemand wat.

Mijn berichten zijn: 02:28 en 18:13.

Ik snap dat er wat verwarring kan zijn, maar wat ik in elk geval bedoelde is dit:
clients kunnen problemen ondervinden bij versturen van berichten naar een mailserver over poort 25.
Dat is omdat wereldwijd veel (niet alle) providers hebben besloten het inkomend verkeer op poort 25 afkomstig van clients
af te sluiten. Vanuit de client point of view: het lijkt dan alsof hun outgoing poort 25 naar de mailserver is afgesloten.
Dat gaat dus niet over verkeer tussen mailservers.

De reden daarvan is dat er te gemakkelijk over poort 25 spam kan worden verstuurd (en dat gebeurde ook) zoals je kunt lezen in de genoemde berichten die daar over gaan. Uiteraard hou je daar niet alle spam mee tegen, maar wel een groot deel. Als jij daar anders over denkt, leg dat dan eens heel zorgvuldig uit.

Nou als je dat bedoelde dan klopt dat dus niet.
In "het verkeer tussen mailservers" is er een server de server en de andere is de client.
Die kun je dus niet blokkeren want dan komt er helemaal niks meer binnen.
Jij zult wel een andere definitie van client aanhouden (thuis PC gebruiker ofzo) maar die definitie is onduidelijk en
onmogelijk goed te checken. En er zijn wel blocklijsten waar dan zogenaamd die thuisgebruikers op staan maar
het gebruik hiervan beperkt zich toch vooral tot agressieve eenlingen die een kruistocht tegen spam voeren, de
serieuze mailaanbieders en bedrijven gebruiken dat soort lijsten niet omdat ze weten dat dit heel veel false positives
en dus verloren mail betekent.

Gaat er ooit iemand nog gewoon antwoord geven op de vraag?

[SMTP] STARTTLS of SSL?

Wat niet klopt is dat je alles niet goed gelezen en in je opgenomen hebt.
Anoniem 26-11-2017, 21:58 gebruikte al het woord "client" en door poort 587 er zo bij te betrekken zou toch wel duidelijk moeten gaan waar het dan over gaat.

Of had de moeite genomen om de inhoud van de gegeven links goed door te lezen. Ik herhaal er nog even 2 voor je:
https://tweakers.net/nieuws/73034/ziggo-blokkeert-alternatieve-smtp-servers-op-poort-25.html
https://securitywatch.pcmag.com/spam/290791-port-25-block-stalls-spam-after-all

Al die SSL of TLS is overbodig want de uitgaande mail van KPN voor je facturen wordt standaard onversleuteld verstuurd.
Een hacker-in-the-middle kan eenvoudig je bankrekeningnummer naam en woonadres lezen via deze mail.
Het anwoordt hierover van KPN is:

De KPN mailservers ondersteunen TLS-verbindingen, maar doen dit op dit moment
(nog) niet expliciet bij uitgaande connecties, onder andere vanwege
compatibiliteitsredenen. Het versturen via explicit TLS, in plaats van
STARTTLS, kan daarbij leiden tot het niet kunnen afleveren van e-mail.

@15:36

Bedoel je dat ze STARTTLS ook niet gebruiken? Gek dat het bij andere providers geen probleem is.

Anno 2017 is er geen excuus meer om onversleuteld mail te versturen. Mail servers adverteren wat ze kunnen, aan de hand daarvan kan de verzendende mail server beslissen of STARTTLS mogelijk is. Als een poging mislukt is er altijd nog fallback op onversleuteld. Mocht ook dat mislukken, kan de server een RSET doen of een gehele nieuwe TCP verbinding en SMTP sessie opzetten.

Ik begrijp dus niet wat precies het probleem is bij KPN. Bij welke mail servers levert dit problemen op volgens KPN?

Het zal ongetwijfeld een teruglopend probleem zijn maar je hebt altijd mensen die 10 jaar nadat een probleem de wereld
uit is nog steeds de "best practice" aanhouden die om dat probleem heen werkt. Neem bijvoorbeeld het instellen van
een ethernet link op "100 Full" ipv op "auto" om redenen dat "auto soms problemen geeft". Nou dat is al heel lang
niet meer zo en tegenwoordig geeft hard instellen op Full duplex heel wat meer problemen, maar evengoed blijft
men dit in bepaalde kringen hardnekkig doen.

Zo ook met het enablen van STARTTLS. Je hebt situaties waarin het niet lukt om een verbinding te maken en niet
alle software is slim genoeg om in zo'n geval bij de volgende poging de TLS maar weg te laten. Meestal gaat het
bij iedere poging weer op dezelfde manier mis: EHLO, STARTTLS in de reply, STARTTLS commando en dan lukt
de verbinding niet, mail niet afgeleverd en volgende poging weer dezelfde sequence.
En eigenlijk is het ook nog eens gevaarlijk om een fallback te doen want daarmee open je juist weer de mogelijkheid
voor een man in the middle om de TLS te omzeilen (hoewel dat ook kan door de STARTTLS uit de EHLO reply
weg te filteren).

Kennelijk is de defectheid van STARTTLS in sommige software zo hardnekkig en onrepareerbaar dat er zelfs
beheerders zijn die het binair in de software hebben weggepatched waardoor je in de reply XXXXXXXX ziet staan
ofzo. Of misschien zijn er wel firewall/ids systemen die dat doen... ik heb het in ieder geval vaak gezien in logs.

Zelfs een security bewuste provider als XS4ALL heeft pas heel kort het gebruik van STARTTLS in uitgaande mail
ingeschakeld staan. Ook in verband met (vermeende) problemen.

Het aantal 'hackers in the middle' op internet core verbindingen (tussen KPN mailservers en ziggo mailservers) is toch wel een stuk lager dan het aantal 'hackers in the middle' op "free wifi" .
(en degenen die eventueel meekijken op core linken hebben vast geen mail intercept nodig om je bankrekening of naw te ontdekken)

SMTP Submit met TLS (dus port 587) help tegen hackers en malware in je omgevingsdomein, en daar is wel enig risico op.

Welke vraag bedoel je?