Re: Delivery Status Notification (Failure)
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 jhar...@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)
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)
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: e9bfbdbd61f044c288b222e857ff6...@ea2 From: emin.akbu...@izsmmmo.com mailto:emin.akbu...@izsmmmo.com To: eminakbu...@gmail.com mailto:eminakbu...@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
Re: Delivery Status Notification (Failure)
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: e9bfbdbd61f044c288b222e857ff6...@ea2 From: emin.akbu...@izsmmmo.com To: eminakbu...@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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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)
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...@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;il;i++){ i%8? c=1: (c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Delivery Status Notification (Failure)
2010/9/2 Karsten Bräckelmann guent...@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)
On Fri, 3 Sep 2010, Emin Akbulut wrote: 2010/9/2 Karsten Br?ckelmann guent...@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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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)
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: e9bfbdbd61f044c288b222e857ff6...@ea2 From: emin.akbu...@izsmmmo.com To: eminakbu...@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