Hi Martin, you are not alone, but gmx should solve one part of the problem: mails from gmx probably do not indicate in a standard way that mail was received from an authenticated user. Once SA finds that information, it is supposed to consider the mta (in that case gmx) rather than the original sender for various tests. There have been discussions about specific ways to describe authenticated users that SA should recognize but might not .... but as far as I remember gmx does not put in an auth header at all
Wolfgang Hamann >> >> Jay Chandler wrote: >> > Not entirely sure what you're saying in the last two paragraphs, >> >> OK, let me put this in different words, let's be more concrete. >> As you all can see I have this Mail Address @gmx.net. GMX is my mail >> provider. They run a server mail.gmx.net for email submission, where I >> have to authenticate myself using username and password. And that's what >> I do, send ym mail through GMX, who then send it on to my specified >> destination. GMX itself of course has a static IP, so that part looks >> right. But GMX logs in a Received header from which IP the mail >> originated, which in my case is of course a dialup IP. >> >> When I later receive that same mail using fetchmail and run it through >> SpamAssassin, it notices the original IP was a dynamic IP, and flags the >> email. >> >> Inspired by all your comments so far, I ran some checks of sending test >> mails to different domains, and in fact found out that they are not >> flagged by SpamAssassin. >> >> But GMX itself has a rather large user base, and when I send to my mail >> address there the mail gets flagged. I guess SpamAssassin does not know >> whether GMX accepted the mail because the sender authenticated >> correctly, or whether it had to accept the mail because it's the MX for >> the final destination. This distinction might however be possible, as >> the MX server is mx0.gmx.de, distinct from the submission server >> mail.gmx.net. And of course there a header called X-Authenticated >> present on authenticated received mails, although that might as well be >> present prior to receiving the mail, i.e. forgable. >> >> To put it short, the problem seems to be about sending from a dynamic IP >> to recipients using the same mail provider. >> >> And as this mail provider does not relay mails to its users through >> SMTP, the problem is probably restricted to users using fetchmail, else >> I can see no way for SpamAssassin to enter the scene. >> >> So I can try to reconfigure my SpamAssassin to handle the case of mails >> sent to GMX specially, i.e. looking for headers indicating an >> authenticated sender. I don't know if there can be some generic solution >> that handles this case even for SpamAssassin administrators on dialup >> machines who did not think of this scenario. >> >> > but it looks different from the receiving MTA. >> > >> > It's thought process, approximately: >> >=20 >> > Who's trying to connect to me? It's a static IP with correct DNS >> > reversals? Okay, works for me. >> >=20 >> > Versus: >> >=20 >> > Who's trying to connect to me? A dynamic IP address? Looks spammy to >> > me. REJECT! >> >> The MTA on GMX does not have to rely on IP checks, because it can do >> SASL authentication, at least on the mail submission server. >> >> Other MTAs are only contacted by GMX, so they are contacted from a >> static IP with correct DNS settings, no problem there. >> >> I guess SpamAssassin thinks along these lines: >> >> Oh, I got mail that was received by one external host (mail.gmx.net) >> before passing through some internal nets (fetchmail, local postfix). So >> let's first drop the internal nets. Now I take it this Received header >> added by GMX has to be checked, and find that it notes >> >> Greetings, >> Martin >>
