Re: Simple mail from Dynamic IP listed as spam

[ha...@t-online.de]

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
>> 

Re: Simple mail from Dynamic IP listed as spam

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

Martin von Gagern wrote:
> Daryl C. W. O'Shea wrote:
>> So long as the "problem relays" are acting solely as MSAs and never MXes
>> for your mail this patch will solve your problem:
>> http://people.apache.org/~dos/sa-patches/msa_networks.3.1
> 
> This patch will solve my problems on receiving such mails from other
> users, and spare me the trouble of hacking my own rules.
> Thank you for that!
> 
> However it won't solve the problem of me sending mail to other
> SpamAssassin users that don't know about this problem.

Only other gmx.net users who have the same trusted networks config, 
except are missing this patch and config will have a problem.  Everyone 
else in the world won't have a problem... they'll do the DNSBL lookups 
you're concerned about on mail.gmx.net [213.165.64.20].


> Is this patch intended for inclusion in a future SpamAssassin version?

Maybe.


> Would it make sense to include a list of known MSAs as well?

Absolutely not.


Daryl

Re: Simple mail from Dynamic IP listed as spam

[Martin von Gagern <Ma...@gmx.net>]

Daryl C. W. O'Shea wrote:
> So long as the "problem relays" are acting solely as MSAs and never MXes
> for your mail this patch will solve your problem:
> http://people.apache.org/~dos/sa-patches/msa_networks.3.1

This patch will solve my problems on receiving such mails from other
users, and spare me the trouble of hacking my own rules.
Thank you for that!

However it won't solve the problem of me sending mail to other
SpamAssassin users that don't know about this problem.

Is this patch intended for inclusion in a future SpamAssassin version?
Would it make sense to include a list of known MSAs as well?

Martin

Re: Simple mail from Dynamic IP listed as spam

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

Martin von Gagern wrote:

> To look at it from a different angle, whether or not an X-Authenticated
> header has any special meaning at all probably depends on the MTAs in
> the chain, so special knowledge is needed to be sure. And with the same
> kind of knowledge you'd know that mail.gmx.net is not the MX for the
> final destination, hence it's the sender's MSA, hence treat this as the
> originating IP.
> 
> I know of no perfect solution, but maybe the X-Authenticated header
> might be a useful rule to include, with a negative score, not as an
> absolute fact but rather as an idication some check might have occurred.

So long as the "problem relays" are acting solely as MSAs and never MXes 
for your mail this patch will solve your problem:

http://people.apache.org/~dos/sa-patches/msa_networks.3.1


Regards,

Daryl

Re: Simple mail from Dynamic IP listed as spam

[Martin von Gagern <Ma...@gmx.net>]

hamann.w@t-online.de wrote:
> mails from gmx probably do not indicate in a standard way that mail was
> received from an authenticated user.

What would be a "standard way"?

> but as far as I remember gmx does not put in an auth header at all

Looking at any of the growing number of test mails I sent myself, I see
this line in each one:

X-Authenticated: #858129

Problem is this line is immediately /after/ the Received headers. As any
spammer can in theory include arbitrary lines into the messages he
sends, so those headers have to be deemed untrustworthy.

I just wanted to check whether gxm would strip this header when
delivering unauthenticated mail, but I never got this far: mail.gmx.net
won't accept mails from unauthenticated users, and the MX that DNS gives
me, mx0.gmx.net, immediately closes a connection without any greeting or
other message. Probably because I'm connecting from a dynamic IP...

To look at it from a different angle, whether or not an X-Authenticated
header has any special meaning at all probably depends on the MTAs in
the chain, so special knowledge is needed to be sure. And with the same
kind of knowledge you'd know that mail.gmx.net is not the MX for the
final destination, hence it's the sender's MSA, hence treat this as the
originating IP.

I know of no perfect solution, but maybe the X-Authenticated header
might be a useful rule to include, with a negative score, not as an
absolute fact but rather as an idication some check might have occurred.

Greetings,
 Martin von Gagern