Postfix met Spamassassin, daarnaast de nodige checks op
enkele blacklists. Dit houdt bij mij 99% van de spam buiten
de deur. Dat ene procentje dat er wel doorkomt is wel zo
vreemd en bizar dat bijna geen enkel spamfilter dit tegen
kan houden.
Maar daar heb ik dat weer een procmailregel voor geschreven :).

Ik houd mijn emailadres zorgvuldig geheim. Elke keer als ik
m'n emailadres nodig hem maak ik een alias aan. Mocht daar
spam op binnenkomen, dan wis ik die alias weer.
Werkt prima (tot nu toe).

Daarvoor zijn aanbieders als hotmail en gmail uitgevonden ;-)

Gewoon voorzichtig zijn, en heb nog geen spam ontvangen op
m'n inmiddels bijna 1/2 jaar oude email adres. Ook m'n
Yahoo! mail adres waar ik echt niet voorzichtig mee ben,
krijgt slecht ca. 2 spam's per maand te verwerken.

Huh? Vreemd en bizar genoeg om niet gefilterd te kunnen worden maar jij filtert het wel? Hoe doe je dat dan? En waarom zou je hetzelfde niet kunnen doen met een spamfilter?

Neuh, aliasjes op je mailserver doet wonderen.
Per website waar je een mailadres achterlaat een apart
alias, zodat je meteen kunt achterhalen welke website je
mailadres heeft doorverkocht.

Zodat je foei! kan zeggen......?

Nee, zodat ik em aan de schandpaal kan nagelen, en daarnaast
ook de webmaster van de site even duidelijk maken dat je em
aan de schandpaal hebt genageld.

Goed, ik heb een groot aantal regels in mijn procmail staan,
waarmee ik voor mij bekende mail filter. Alles dat niet aan
die voorwaarden voldoet, komt in een mapje possible_spam
terecht.
Dus ik filter veel spam, sorteer mijn absoluut correcte mail
en de twijfelgevallen komen in een apart boxje, waar ik eens
in de week in kijk.

Ik gebruik mijn standaard spamfilter in Outlook en het
spamfilter van mijn hosting provider waar ik zelf ook de
spam mail kan uploaden om het filter te "leren" wat spam en
wat geen spam is.

Ik gebruik mijn standaard spamfilter in Outlook en het
spamfilter van mijn hosting provider waar ik zelf ook de
spam mail kan uploaden om het filter te "leren" wat spam en
wat geen spam is.

Wat sommige ISP's verkeerd doen is het aan uitgaande
mail toevoegen van de HELO/EHLO van mail-clients,
waar spamfilters over kunnen struikelen.
E-mail-clients geven zelden tot nooit een legitieme
HELO/EHLO, als in HELO pietjespc
Tussen mail-servers behoort bij HELO/EHLO altijd een
geldige FQDN te worden opgegeven.

Anders, namelijk via de internetprovider en de ingebouwde
spamfilter van Thunderbird.

Anders, namelijk de enige manier die echt werkt, met een
whitelist.
Als je al meer dan een decenium het zelfde e-mail adres hebt
krijg
je nou eenmaal zo veel spam dat je een echte oplossing moet
gaan zoeken.
Als de spam filter van de ISP er overheen is geweest is het
aantal spam berichten van enkelle duizenden naar enkele
honderden afgenomen, maar
ondanks de speling zitten er nog steeds false positives in
de spam box.
In beginsel de mail dus in drie splitsen:

* SPAM 99.9+ % spam. paar duizend per week,
max een keer per
week met de hand op zoek naar
false positives. 1 a 2 per
week.
* UNK 90+ % spam. vele tientallen per dag
maximaal een keer per dag op
zoek naar non-spam.
1 a 2 per dag.
* WHITELIST 0 % spam. enkele tientallen per dag, geen
false positives
tot nog toe.

Het is niet de ISP die dit toevoegt maar de client.

Lees [url=http://www.faqs.org/rfcs/rfc2821.html]RFC-2821[/url] Section 4.1.1.1 maar een keertje goed door. Er staat nergens dat die info achter HELO/EHLO aan bepaalde voorwaarden MOET voldoen.

Ik was niet zo duidelijk, maar werd de toevoeging bedoeld aan Received headers door enkele ISP's
aan door abonnee's verzonden post:

Received: from [#] (helo=#)

Van bijvoorbeeld (3rd-party) Backup-MX's is dergelijk aanvullende informatie wel functioneel, voor eigen additionele contrôle.

RFC-2821 (proposed standard)

Syntax:

ehlo = EHLO SP Domain CRLF
helo = HELO SP Domain CRLF

3.6 Domains

Only resolvable, fully-qualified, domain names (FQDNs) are
permitted when domain names are used in SMTP. In other
words, names that can be resolved to MX RRs or A RRs (as
discussed in section 5) are permitted, as are CNAME RRs
whose targets can be resolved, in turn, to MX or A RRs.
Local nicknames or unqualified names MUST NOT be used.
There are two exceptions to the rule requiring FQDNs:

- The domain name given in the EHLO command MUST BE either
a primary host name (a domain name that resolves to an
A RR) or, if the host has no name, an address literal as
described in section 4.1.1.1.

- The reserved mailbox name "postmaster" may be used in a
RCPT command without domain qualification (see section
4.1.1.3) and MUST be accepted if so used.

4.1.1.1
[...]
In situations in which the SMTP client system does not have
a meaningful domain name (e.g., when its address is
dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see
section 4.1.3)[...]

Dit geldt voor clients zoals Thunderbird, Outlook (Express),
Evolution en dergelijken, binnen een autonoom netwerk.

Voor systemen die vanaf het internet te benaderen zijn:

RFC-1912 (Informational), 2.1 Inconsistent, Missing, or Bad Data

Every Internet-reachable host should have a name. The
consequences of this are becoming more and more obvious.
Many services available on the Internet will not talk to you
if you aren't correctly registered in the DNS. Make sure
your PTR and A records match. For every IP address, there
should be a matching PTR record in the in-addr.arpa domain.
If a host is multi-homed, (more than one IP address) make
sure that all IP addresses have a corresponding PTR record
(not just the first one). Failure to have matching PTR and A
records can cause loss of Internet services similar to not
being registered in the DNS at all. Also, PTR records must
point back to a valid A record, not a alias defined by a CNAME.

Nog iets over 'should' (en 'shall'). Should is géén
vrijblijvende 'mag' als in you may do so.
You should do that, you should have done that.
Dat zou je moeten doen, dat had je moeten doen.

Let goed op de status van RFC's. RFC-2821 is een
voorgestelde standaard die nog niet is aangenomen.
Tot dan geldt STD-10 (RFC-821) als standaard.

STD-10:

HELO SP domain CRLF

[...]

The first command in a session must be the HELO command. The
HELO command may be used later in a session as well.
If the HELO command argument is not acceptable a 501 failure
reply must be returned and the receiver-SMTP must stay in
the same state.

Bij mij komt er alleen maar spam in mn outbox! :P

Klopt. Maar SHOULD is ook geen MUST. You SHOULD do it, dan wordt er aangeraden om het te doen maar er is geen man overboord als je het niet doet. You MUST do it, dan moet je het doen, je bent het verplicht.
Het merendeel van de RFC's, die nu in gebruik zijn, zijn drafts.

Enne...
http://www.faqs.org/rfcs/std/std-index.html

Wie denk je dat hier wel bij varen, bij verschillende
interpretaties van dezelfde documenten (onder andere door
verschillen in taal en dergelijken)?
Iets behoren te doen, wat je zou moeten doen en moeten doen
is niet zo heel erg verschillend.
Meestal is er geen reden om iets wat je behoort te doen niet
te doen, hoewel dat laatste soms als makkelijker wordt ervaren.

Het is alleen een beetje vervelend wanneer je
pakketten niet geaccepteerd worden.

:) Ja, dat is ook lekker duidelijk. Om er nog een schepje
bovenop te doen kent RFC2821 ook een Errata, wat er op
neer komt: the reader must make his/her own judgment. Wanneer men
op die manier specificaties voor elektronica zou opstellen dan ging
dagelijks een en ander in rook op.

Spamfilter op antivirus smtp proxy, die ook proxiet voor
http en ftp.

postfix + policyd
spamfilter (SpamAssassin + Maia Mailguard)
+ Hacks naar Spamikaze
die voor mij automatisch een RBLDNS creeert.

Zoveel interpretatie is er niet. Verplicht, optioneel of wordt aangeraden...
http://www.ietf.org/rfc/rfc2119.txt

Sommige (zendende) mailservers voeren bijvoorbeeld geen
geldig domain in de HELO, hebben geen MX-records, hebben
verkeerde of helemaal geen DNS-vermelding.

Okay, expliciet moet het niet, maar zijn er geen (legitieme)
redenen om niet te doen wat men aanbevolen behoort te doen.

Op het WAN mag men verwachten dat wat men aanbevolen behoort
te doen wordt gedaan of aanwezig behoort te zijn aanwezig is.

Los van of je dit zo bedoelt, wordt deze zin door mensen gelezen als "Wat je achter HELO/EHLO zet mag je zelf weten." Maar dat is niet zo.

Denk bijvoorbeeld eens aan servers/netwerken met een eigen intern dns domain bijv. mycompany.local?. Waarom zou een mailserver, die alleen maar e-mail verzend een MX record moeten hebben? MX records zijn voor ontvangende mailservers. Denk ook aan IP load-balancers, meerdere machines die via hetzelfde IP adres naar binnen/buiten communiceren. Hoe ga je dat fatsoenlijk in DNS zetten? Een A RR lukt nog wel maar een PTR RR niet. Forward-reverse lookups falen dan.

Nee, je mag het verwachten maar je dient er rekening mee te houden dat het niet gebeurd.

Je hebt gelijk dat MX-records niet in dat rijtje thuishoort.
Dan sta je
werkelijk overal open voor.

Sorry, ik heb de RFC's niet geschreven ;)

Dus toch een interpretatieverschil.

omdat de rfc's dat zo stellen?

die geef je dan allemaal dezelfde HELO naam, bijvoorbeeld, de
FQDN waar het PTR record van dat ip adres naar wijst?

Ik neem geen email aan van (ongeauthoriseerde, niet-whitelisted)
mailservers die geen reverse dns lookup hebben en/of geen FQDN in het
HELO commando voeren en/of die FQDN niet resolved in dns naar een A of een MX record (of een CNAME die wijst naar een A of MX)...