X-Junk-Score: 0 [] X-Cloudmark-Score: 0 [] Return-Path: Received: from mail.virtuelle.no ([83.137.200.195] verified) by mail.stalker.com (CommuniGate Pro SMTP 5.2.14) with ESMTP id 54229748 for CGatePro@mail.stalker.com; Fri, 26 Jun 2009 09:01:51 -0700 Received-SPF: pass receiver=mail.stalker.com; client-ip=83.137.200.195; envelope-from=nicolas.hatier@niversoft.com X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.72 (ClamAV engine v0.91.2) Received: from [66.110.158.160] (account nicolas.hatier HELO niversoft.com) by mail.virtuelle.no (CommuniGate Pro SMTP 5.0.13) with ESMTPSA id 7120211 for CGatePro@mail.stalker.com; Fri, 26 Jun 2009 18:01:15 +0200 X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.9.3 (ClamAV engine v0.95.1) X-ExtFilter: Niversoft's DomainKeys Helper DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; d=niversoft.com; s=default; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=ly/PmEz0CpJ+u17F5+5Tl/1B/SqWgNPLRuHPnRvaSVuCuYWXZWBH9ZwDcjGk3LP0VY xP1TErumLMXIBMZFkheE1s4ilL8HQ9alTz6jtisFwQGmz/h1TQxX3kV+89bwv06UNkqU 78gj42CiEGgNmbarwbcfybOBGxP8vIg86q1bE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niversoft.com; s=default; l=9381; t=1246032072; x=1246636872; q=dns/txt; h=Message-ID:Date:From:User-Agent:MIME-Version:To: Subject:References:In-Reply-To:Content-Type; bh=fRB88XkjIm+e1yz8 C9A4grwmGopxFa7eMZ1Z6w7b6Oo=; b=hiOR5vBc364U7oSf867cdhyEqDRijvpY q9rSHZTe2ikDc2Rijhc0v9S60Ipo+6YqmM/FE3hQYv+nfBe/VaJBjU5UTRj8/WI3 pgTLrSSX+CS3ShOAlYuxyIRHAfGYGANg68aYoYKuT3RFy0dHhx+VgrSzh2ZThMao HCBTIvbaNfA= Received: from dummy.name; Fri, 26 Jun 2009 12:01:11 -0400 Message-ID: <4A44F0C7.9050909@niversoft.com> Date: Fri, 26 Jun 2009 12:01:11 -0400 From: Nicolas Hatier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Lightning/0.9 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: CommuniGate Pro Discussions Subject: Re: Sending FROM accounts in domain even with authentication enabled References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030001000504090800090100" This is a multi-part message in MIME format. --------------030001000504090800090100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable "MAIL FROM" is an SMTP command, not a mail header... The DATA portion of = the SMTP transaction is usually left mostly unmodified in its way to the = client. Some additional headers are added (Return-Path, which=20 corresponds to the MAIL FROM smtp command, Received, and other headers=20 added by content filters). You should never rely on the From header to programmatically determine=20 where a message comes from, always on the Return-Path. The Form is=20 easily forged. The Return-path too, but at least it can't be forged to=20 an internal address when SMTP Auth is enabled. One notable exception is when using a content filter such as=20 DKIM/DomainKeys. DomainKeys will read the reported "From" address, and=20 verify if the message signature matches the "From domain" public key.=20 And if there is no signature, it will verify whether or not the "From=20 domain" publicly announces it always sign messages. Using such a filter=20 is another step against impersonation, which is what you currently seem=20 to aim. Best regards Nicolas Hatier David Modoski wrote: > Nevermind, I figured out the reason though not sure if there's a way to= prevent it. > > Apparently you can issue the "MAIL FROM:" command with an outside email= address and then later in the transaction after issuing the DATA command= you can insert a FROM: within the data portion which appears to over-rid= e the "MAIL FROM:" in the header. The only indication is in the long head= er where the "Return Path" is set to the real email address submitted. > > -----Original Message----- > From: CommuniGate Pro Discussions [mailto:CGatePro@mail.stalker.com] On= Behalf Of David Modoski > Sent: June 26, 2009 9:27 AM > To: CommuniGate Pro Discussions > Subject: Re: Sending FROM accounts in domain even with authentication e= nabled > > I understand that concept. However, this does not apply to email origin= ating from our server. I can require that all of OUR users authenticate b= efore they are allowed to submit email (any other domain on the Internet = can submit email without authentication). This does work because as I sta= ted when I connect to the SMTP port and send the FROM command with an acc= ount within our domain I immediately get a notification that the account = requires authentication before submitting email. I don't understand how t= he spammers appear to be bypassing this. I'll need to check out the serve= r logs to see if I can find any additional information. > > The exact error message when using a CGP domain account > > 575 david.modoski@mydomain.com sender requires authentication > > -----Original Message----- > From: CommuniGate Pro Discussions [mailto:CGatePro@mail.stalker.com] On= Behalf Of Lyle Giese > Sent: June 26, 2009 8:21 AM > To: CommuniGate Pro Discussions > Subject: Re: Sending FROM accounts in domain even with authentication e= nabled > > David Modoski wrote: > =20 >> We have authentication enabled for all of our CGP accounts for sending= >> email. This requires that the account holder authenticate to the >> server before submitting mail. I've tested by connecting to the SMTP >> port and using a FROM address within our domain (I'm informed by the >> server that this account needs to authenticate before sending mail). >> However, I've just started receiving SPAM that is address FROM an >> email account within the domain. Anyone have any ideas how that might >> be getting through? >> >> Thanks, >> Dave >> >> =20 > This requirement is for relaying email, not sending email. You may say > what's the difference? Relaying means the email will be relayed/sent to= > another email server. Sending can include email for here. > > If you required Authenication for all email, you will be unable to get > email from the world as other mail servers won't be able to send email > to your domains. > > Lyle Giese > LCR Computer Services, Inc. > > > =20 --=20 *Nicolas Hatier* > Niversoft id=E9es logicielles - http://www.niversoft.com --------------030001000504090800090100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
"MAIL FROM" is an SMTP command, not a mail header... The DATA portion of the SMTP transaction is usually left mostly unmodified in its way to the client. Some additional headers are added (Return-Path, which corresponds to the MAIL FROM smtp command, Received, and other headers added by content filters).

You should never rely on the From header to programmatically determine where a message comes from, always on the Return-Path. The Form is easily forged. The Return-path too, but at least it can't be forged to an internal address when SMTP Auth is enabled.

One notable exception is when using a content filter such as DKIM/DomainKeys. DomainKeys will read the reported "From" address, and verify if the message signature matches the "From domain" public key. And if there is no signature, it will verify whether or not the "From domain" publicly announces it always sign messages. Using such a filter is another step against impersonation, which is what you currently seem to aim.

Best regards
Nicolas Hatier

David Modoski wrote: 
Nevermind, I figured out the reason though not sure if there's a way to prevent it.

Apparently you can issue the "MAIL FROM:" command with an outside email address and then later in the transaction after issuing the DATA command you can insert a FROM: within the data portion which appears to over-ride the "MAIL FROM:" in the header. The only indication is in the long header where the "Return Path" is set to the real email address submitted.

-----Original Message-----
From: CommuniGate Pro Discussions [mailto:CGatePro@mail.stalker.com] On Behalf Of David Modoski
Sent: June 26, 2009 9:27 AM
To: CommuniGate Pro Discussions
Subject: Re: Sending FROM accounts in domain even with authentication enabled

I understand that concept. However, this does not apply to email originating from our server. I can require that all of OUR users authenticate before they are allowed to submit email (any other domain on the Internet can submit email without authentication). This does work because as I stated when I connect to the SMTP port and send the FROM command with an account within our domain I immediately get a notification that the account requires authentication before submitting email. I don't understand how the spammers appear to be bypassing this. I'll need to check out the server logs to see if I can find any additional information.

The exact error message when using a CGP domain account

575 david.modoski@mydomain.com sender requires authentication

-----Original Message-----
From: CommuniGate Pro Discussions [mailto:CGatePro@mail.stalker.com] On Behalf Of Lyle Giese
Sent: June 26, 2009 8:21 AM
To: CommuniGate Pro Discussions
Subject: Re: Sending FROM accounts in domain even with authentication enabled

David Modoski wrote:
  
We have authentication enabled for all of our CGP accounts for sending
email. This requires that the account holder authenticate to the
server before submitting mail. I've tested by connecting to the SMTP
port and using a FROM address within our domain (I'm informed by the
server that this account needs to authenticate before sending mail).
However, I've just started receiving SPAM that is address FROM an
email account within the domain. Anyone have any ideas how that might
be getting through?

Thanks,
Dave

    
This requirement is for relaying email, not sending email. You may say
what's the difference? Relaying means the email will be relayed/sent to
another email server. Sending can include email for here.

If you required Authenication for all email, you will be unable to get
email from the world as other mail servers won't be able to send email
to your domains.

Lyle Giese
LCR Computer Services, Inc.

--

Nicolas Hatier <nicolas.hatier@niversoft.com>
Niversoft idées logicielles - http://www.niversoft.com

--------------030001000504090800090100--