Email : Hop Count Exceeded - verantwoordelijkheid?

[usr-local-dick]

Hoi

Als listmaster krijg ik dagelijks allerlei errors om mijn oren.
De meeste zijn uiteraard user unknown etc, maar soms krijg ik Hop Count Exceeded.
Sinds ik op onze (debian sarge) mailserver Spamassassin heb geinstalleerd en ook amavisd-new, krijgt ieder mailtje een paar extra hops. Dit is op zich ene legitieme actie.
Onze email distributie software (majordomo) zorgt ervoor dat er weer extra hop bij komen.

Als de ontvanger ook nog eens spamassassin heeft, of een paar interne mailservers die iets doen, komen er nog weer meer bij.

Tegenwoordig kom ik dus steeds vaker Hop Count Exceeded tegen.
Sommige servers geven een error bij 15 hops, sommigen bij 20.

Wat is de policy hierbij eigenlijk? En hoe gaan jullie daar mee om?

Nu gebeurt het dus dat mensen mail niet krijgen vanwege die hop count. Wie moet ik daarop aanspreken? De remote postmaster?

Graag jullie mening.

[alt-92]

15 is iig een Exchange default (is te verhogen), ook bij diverse protocols overigens (RIP bijvoorbeeld).
Als een mail over 15 hops (MTAs dus) moet lopen zit er wel erg veel tussen lijkt me..

[ Voor 10% gewijzigd door alt-92 op 19-11-2005 01:27 ]

[Anoniem: 159032]

Je kan natuurlijk moeilijk de remote postmaster hierop aanspreken als je er zelf ook een zooi hops bovenop gooit lijkt me... Kun je er zelf niet iets tussenuit slopen?

[mvdejong]

Het probleem met de hop-count is dat de meeste spam- en virus-filters worden geinstalleerd als een "intermediate" mail-server. De mail die op een enkele server binnenkomt gaat kan zo feitelijk al 3 hops oplopen :
- spam-filter (die als eerste, dan hebben de volgende 2 een hoop minder werk ...)
- virus-scanner
- daadwerkelijke mail-server

Aangezien ISP's met regionale vestigingen, maar ook internationale bedrijven, vaak al weer 2 servers nodig hebben om mail af te leveren, de centrale en de regionale, tikt dat ook aardig aan.

Ik werk bij een internationaal bedrijf, en het hoofd-kantoor had een tijdje geleden besloten dat alle mail, niet alleen die voor <bedrijf>.com, maar ook die voor <bedrijf>.nl, toch via de server van het (Franse) hoofdkantoor moest worden ontvangen en verstuurd. Dat was lachen, want zelfs met een max. hop-count van 25 konden we de mail voor onze eigen vestiging keurig op 1 hop voor het einde zien overlijden, er zaten uiteindelijk 26 hops tussen voor een aantal verzenders. Er zaten in Frankrijk 3 mail-servers, en in Nederland 2 mail-server tussen.
Toch maar ongehoorzaam geweest en het MX-record voor het <bedrijf>.nl domein teruggezet naar onze eigen servers.

[MikeN]

Gewoon de remote postmaster vertellen dat hij/zijn software maar de aanbevelingen uit de RFC over moet nemen

[Brahiewahiewa]

mvdejong schreef op zaterdag 19 november 2005 @ 14:21:
...Toch maar ongehoorzaam geweest en het MX-record voor het <bedrijf>.nl domein teruggezet naar onze eigen servers.

Je had natuurlijk ook gewoon de maximum hop count op je server omhoog kunnen zetten. Die maximum hop count is namelijk een waarde die per MTA verschilt. Dus als je weet dat mail binnen je bedrijf nog over een aanzienlijk aantal hops gaat kun je daar maar het beste op anticiperen en de maximum hop count op die servers verhogen.

@TS: je kunt het jezelf moeilijk maken en de discussie aangaan met al die postmasters over de precieze waarde van hun maximum hop count. Je kunt het jezelf ook makkelijk maken door op de laatste server die binnen jouw bedrijf, een scriptje te draaien wat de interne headers eruit sloopt. Als ik het goed lees scheelt dat zo'n 5 hops dus dat zal het aantal "hop count exceeded" messages wat je terugkrijgt aanzienlijk beperken.

[mvdejong]

Overigens is zoiets ook aan de hand (geweest) met het IP-protocol.
Aanvankelijk was de default-waarde voor de TTL (Time To Live), wat niet een tijds-aanduiding is, maar het aantal routers dat een pakketje mag passeren voordat aangenomen wordt dat er een routing-loop is opgetreden, en dus wordt gedropt, gesteld op 64. Maar met de "explosie" van internet en alle ISP-interne en bedrijfs-interne routers, kostte dat erg veel pakketjes het leven, zodat tegenwoordig 255 de startwaarde voor TTL behoort te zijn.