You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Emin Akbulut <em...@gmail.com> on 2010/09/01 23:57:05 UTC
Re: Delivery Status Notification (Failure)
Good. My test mail headers rejected here: : P
Delivery to the following recipient failed permanently:
users@spamassassin.apache.org
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient
domain. We recommend contacting the other email provider for further
information about the cause of this error. The error that the other server
returned was: 552 552 spam score (1002.5) exceeded threshold (state 18).
*I try again:*
There is no second MTA/SMTP server. Imagine 3 machines
in my environment: 1. Mail client, 2: Mail server 3: SA server.
Test message is OUTGOING message, I'm authenticated user.
The only HELO command sender is my mail client and it's not
a relay server, huh?
Original test message headers:
Received: from ea2 ([78.186.240.194]) by izsmmmo.com with MailEnable ESMTP;
Wed, 1 Sep 2010 15:30:15 +0300
Message-ID: <E9...@ea2>
From: <em...@izsmmmo.com>
To: <em...@gmail.com>
Subject: HELO_NO_DOMAIN test
Date: Wed, 1 Sep 2010 15:23:20 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0003_01CB49E9.9C0B6070"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 14.0.8117.416
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416
Bu, MIME biçiminde çok taraflı bir iletidir.
------=_NextPart_000_0003_01CB49E9.9C0B6070
Content-Type: text/plain;
charset="iso-8859-9"
Content-Transfer-Encoding: quoted-printable
XJS*C4JDBQADN1.NSBN3*2IDNEN*@@@@@@@GTUBE@
@@-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
------=_NextPart_000_0003_01CB49E9.9C0B6070
Content-Type: text/html;
charset="iso-8859-9"
Content-Transfer-Encoding: quoted-printable
Re: Delivery Status Notification (Failure)
Posted by John Hardin <jh...@impsec.org>.
On Thu, 2 Sep 2010, Emin Akbulut wrote:
> Good. My test mail headers rejected here: : P
It's best to post sample messages to a site like pastebin, and then just
post the URL for that here. A sample sent to the mailing list will, as
you've seen, be subject to scanning and rejection, as well as subject to
modification by any host it passes through, making it more difficult to
trust as the basis for analysis.
> *I try again:*
>
> There is no second MTA/SMTP server. Imagine 3 machines
> in my environment: 1. Mail client, 2: Mail server 3: SA server.
> Test message is OUTGOING message, I'm authenticated user.
That's the second possible scenario I was wondering about, but I did not
want to complicate my original question too much.
You are scanning outbound email. That detail may not have been clear in
the original posts.
Someone else with experience scanning outbound mail may have more
suggestions to offer, as I do not scan outbound mail and don't have
experience with all of the gotchas.
> The only HELO command sender is my mail client and it's not
> a relay server, huh?
No, but from the point of view of the SMTP exchange there isn't any
explicit distinction between an originator of a message and an
intermediate relay.
A quick note before all my commentary: setting your mail client(s) to use
a fully-qualified domain name as the HELO string would fix the problem.
Doing this in Outlook might require changing the network name of your
computer. I don't use Outlook so I can't offer exact instructions.
On to the commentary...
Is the IP address below modified by you in any way to protect privacy? If
not, then that's a public Internet IP address. Not seeing a reserved
network there makes me assume your mail client is not on a private subnet
on the private side of your MTA. Some of my comments will be based on that
assumption, I apologize if I am in error.
>From the headers that it appears you are not using authenticated SMTP. You
should be. That would greatly help SA figure things out when the mail
clients you're serving are on the public Internet.
Since you are not using authenticated SMTP, you are not an "authenticated
user" as you claimed to be above. What exactly makes you an "authenticated
user"?
To check my assumption: is your mail client actually on a private subnet
under your control, or is it directly connected to the Internet somewhere
else and getting an IP address you cannot control or predict?
If the clients are on a private subnet under your control, you can tell SA
that their subnet is "internal", you can tell your MTA to not pass
outbound messages to SA (based on the IP address), or you write an
offsetting rule that matches locally-originated email (based on the IP
address in a Received: header) and adds some negative points to the score.
(Side question: if your mail clients _are_ on a privately-controlled
subnetwork, why didn't you use one of the network address spaces reserved
for that purpose?)
> Original test message headers:
>
> Received: from ea2 ([78.186.240.194]) by izsmmmo.com with MailEnable ESMTP;
> Wed, 1 Sep 2010 15:30:15 +0300
> Message-ID: <E9...@ea2>
> From: <em...@izsmmmo.com>
> To: <em...@gmail.com>
> Subject: HELO_NO_DOMAIN test
> Date: Wed, 1 Sep 2010 15:23:20 +0300
> MIME-Version: 1.0
> Content-Type: multipart/alternative;
> boundary="----=_NextPart_000_0003_01CB49E9.9C0B6070"
> X-Priority: 3
> X-MSMail-Priority: Normal
> Importance: Normal
> X-Mailer: Microsoft Windows Live Mail 14.0.8117.416
> X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416
>
> Bu, MIME biçiminde çok taraflı bir iletidir.
>
> ------=_NextPart_000_0003_01CB49E9.9C0B6070
> Content-Type: text/plain;
> charset="iso-8859-9"
> Content-Transfer-Encoding: quoted-printable
>
> XJS*C4JDBQADN1.NSBN3*2IDNEN*@@@@@@@GTUBE@
> @@-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
> ------=_NextPart_000_0003_01CB49E9.9C0B6070
> Content-Type: text/html;
> charset="iso-8859-9"
> Content-Transfer-Encoding: quoted-printable
>
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Therapeutic Phrenologist - send email for affordable rate schedule.
-----------------------------------------------------------------------
15 days until the 223rd anniversary of the signing of the U.S. Constitution
Re: Delivery Status Notification (Failure)
Posted by Kris Deugau <kd...@vianet.ca>.
Emin Akbulut wrote:
> OK thanks a lot, I though relays were only servers. We have 3000+
> accounts from all over the country so I'm going to override the score
> as lower. I also lowered DOS_OUTLOOK_TO_MX from 2.636 to 1.0
> and lowered blacklisted IP scores because of dynamic IP usage
> and now I eliminated high volumes of -UNSENT- false positives. False
> negatives are better than false positives huh?
Hits on rules like DOS_OUTLOOK_TO_MX also usually indicate a problem of
some kind with your trust settings - trusted_networks,
internal_networks, msa_networks, etc.
I run a filter cluster that processes both inbound mail from the MX
cluster going in to customer mailboxes, and outbound mail sent by
customers through our outbound relay cluster, and have no problems with
outbound mail getting an extra 4 points due to the stupid things client
MUAs do in submitting mail.
Careful manual setting of all trusted_networks and related settings
makes misfires of rules relating to "is this a direct-to-MX message?"
almost impossible.
-kgd
Re: Delivery Status Notification (Failure)
Posted by Emin Akbulut <em...@gmail.com>.
OK thanks a lot, I though relays were only servers. We have 3000+
accounts from all over the country so I'm going to override the score
as lower. I also lowered DOS_OUTLOOK_TO_MX from 2.636 to 1.0
and lowered blacklisted IP scores because of dynamic IP usage
and now I eliminated high volumes of -UNSENT- false positives. False
negatives are better than false positives huh?
Now SA system looks working.
On Fri, Sep 3, 2010 at 1:09 AM, John Hardin <jh...@impsec.org> wrote:
> On Fri, 3 Sep 2010, Emin Akbulut wrote:
> "Relay" is "the system that submitted the message". For the purposes of the
> HELO string it does not matter whether that is a MTA or a MUA. "Incorrect"
> is "it did not use a FQDN".
>
> There is no problem with the rule.
>
>
> --
> John Hardin KA7OHZ
>
Re: Delivery Status Notification (Failure)
Posted by John Hardin <jh...@impsec.org>.
On Fri, 3 Sep 2010, Emin Akbulut wrote:
> 2010/9/2 Karsten Br�ckelmann <gu...@rudersport.de>
>
>> Kind of repeating myself here, but... HOW does SA running on the third
>> machine get the message? The headers you showed us aren't necessarily
>> the ones SA ultimately gets to see.
>
> Oh god, it's not mystery, my mail server got two IP, an internal
> and a real IP. SA has only internal IP. That's it. So my hop count
> from mail client to server, server to SA, always 1.
>
> I'm authenticated, there is no doubt.
Using just the mail headers that you provided as an example, show us how
we are to know the sender is authenticated. Proof by vigorous assertion is
not proof.
> Let me explain why I did ask that question; what is HELO_NO_DOMAIN?
The HELO does not contain a domain part. From your example:
> Received: from ea2 ([78.186.240.194]) by izsmmmo.com with MailEnable ESMTP;
"ea2" is not a fully qualified host name. There is no domain part.
> because SA scores our users and they are not spammers, they are ordinary
> authenticated message senders, just like me. HELO_NO_DOMAIN and
> FSL_HELO_NON_FQDN_1 and a few others make innocent messages nearly spam.
That is because you are scanning outbound mail while making no provision
for the way a MUA will submit messages. If you configured all of your mail
clients to use a fully-qualified host name instead of just a machine name,
these problems would go away.
> So I have to fix HELO_NO_DOMAIN problem.
I told you how to do that.
(1) fix your mail clients to use fully-qualified host names rather than
just machine names,
or
(2) stop scanning outbound mail,
or
(3) write a rule that recognizes locally-originated messages and subtracts
(say) five points from the score.
> I'm asking in another way another point of view:
>
> *HELO_NO_DOMAIN Relay reports its domain incorrectly*
>
> So what/who is relay here and what reports incorrect?
"Relay" is "the system that submitted the message". For the purposes of
the HELO string it does not matter whether that is a MTA or a MUA.
"Incorrect" is "it did not use a FQDN".
There is no problem with the rule.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Vista is at best mildly annoying and at worst makes you want to
rush to Redmond, Wash. and rip somebody's liver out. -- Forbes
-----------------------------------------------------------------------
15 days until the 223rd anniversary of the signing of the U.S. Constitution
Re: Delivery Status Notification (Failure)
Posted by Emin Akbulut <em...@gmail.com>.
2010/9/2 Karsten Bräckelmann <gu...@rudersport.de>
>
> Kind of repeating myself here, but... HOW does SA running on the third
> machine get the message? The headers you showed us aren't necessarily
> the ones SA ultimately gets to see.
>
>
Oh god, it's not mystery, my mail server got two IP, an internal
and a real IP. SA has only internal IP. That's it. So my hop count
from mail client to server, server to SA, always 1.
I'm authenticated, there is no doubt. Let me explain why I did ask
that question; what is HELO_NO_DOMAIN? because SA scores
our users and they are not spammers, they are ordinary authenticated
message senders, just like me. HELO_NO_DOMAIN and
FSL_HELO_NON_FQDN_1 and a few others make innocent
messages nearly spam. A non-spam message scored ~4
points at first. If user types ALL CAPS SUBJECT vs.
then his message becomes a spam. I cannot tell to
everybody; hey do not use caps in subject. So
I have to fix HELO_NO_DOMAIN problem.
I'm asking in another way another point of view:
*HELO_NO_DOMAIN Relay reports its domain incorrectly*
So what/who is relay here and what reports incorrect?
Re: Delivery Status Notification (Failure)
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Thu, 2010-09-02 at 00:57 +0300, Emin Akbulut wrote:
> Good. My test mail headers rejected here: : P
Ugh, yeah -- do not send spam this way. GTUBE by its very definition is
meant to be caught by SA.
Replying to the DSN probably wasn't the best of choices either. What's
that subject got to do with your question?
> I try again:
>
> There is no second MTA/SMTP server. Imagine 3 machines
> in my environment: 1. Mail client, 2: Mail server 3: SA server.
So your MUA on the client machine sends the message to your MailEnable
SMTP server. Which is, what the single Received header shows.
Kind of repeating myself here, but... HOW does SA running on the third
machine get the message? The headers you showed us aren't necessarily
the ones SA ultimately gets to see.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Delivery Status Notification (Failure)
Posted by Bowie Bailey <Bo...@BUC.com>.
On 9/1/2010 5:57 PM, Emin Akbulut wrote:
> /*
> */
>
> There is no second MTA/SMTP server. Imagine 3 machines
> in my environment: 1. Mail client, 2: Mail server 3: SA server.
> Test message is OUTGOING message, I'm authenticated user.
> The only HELO command sender is my mail client and it's not
> a relay server, huh?
>
> Original test message headers:
>
> Received: from ea2 ([78.186.240.194]) by izsmmmo.com
> <http://izsmmmo.com/> with MailEnable ESMTP; Wed, 1 Sep 2010
> 15:30:15 +0300
> Message-ID: <E9...@ea2>
> From: <emin.akbulut@izsmmmo.com <ma...@izsmmmo.com>>
> To: <eminakbulut@gmail.com <ma...@gmail.com>>
> Subject: HELO_NO_DOMAIN test
> Date: Wed, 1 Sep 2010 15:23:20 +0300
> MIME-Version: 1.0
> Content-Type: multipart/alternative;
> boundary="----=_NextPart_000_0003_01CB49E9.9C0B6070"
> X-Priority: 3
> X-MSMail-Priority: Normal
> Importance: Normal
> X-Mailer: Microsoft Windows Live Mail 14.0.8117.416
> X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416
>
> Bu, MIME biçiminde çok taraflı bir iletidir.
>
> ------=_NextPart_000_0003_01CB49E9.9C0B6070
> Content-Type: text/plain;
> charset="iso-8859-9"
> Content-Transfer-Encoding: quoted-printable
>
> XJS*C4JDBQADN1.NSBN3*2IDNEN*@@@@@@@GTUBE@@@-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
> ------=_NextPart_000_0003_01CB49E9.9C0B6070
> Content-Type: text/html;
> charset="iso-8859-9"
> Content-Transfer-Encoding: quoted-printable
>
1) I lost track of your question.
2) Those headers do not look like the message passed through SA. If you
are questioning what SA is doing, we need to see the headers AFTER SA
has processed the message so we can see what it did.
--
Bowie