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 54239766 for CGatePro@mail.stalker.com; Fri, 26 Jun 2009 21:25:46 -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 7125676 for CGatePro@mail.stalker.com; Sat, 27 Jun 2009 06:25:14 +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=k69VCLuewqPOs8Jb8vTmN3Zn7QqsZFZBbyCR27ZgF6wDlxqQAPW7ZXzY8hv76Tf72y MzJSZZqn9WgkA51B0a/lEWjlzpkStvGXYyUCixAh2LDaDF05pIrIoyRPTTF+lAVXCkiG ukFtOcsdcpBDe6NOSFVqDzqTVnN3kMWYl8Dg4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niversoft.com; s=default; l=14988; t=1246076711; x=1246681511; q=dns/txt; h=Message-ID:Date:From:User-Agent:MIME-Version:To: Subject:References:In-Reply-To:Content-Type; bh=7juL7C1y/RhoUZwz mnA+afceiCbwR3s1kCZC6ur4zMU=; b=T6rYQ39TzD4eozDUBf+5CfqB0N/TazYM k1LeMG+Le9BYNGCym9jsl+6G0fLkuqdT9VNS0Ea7Jw+Sij0m+3+k+PFgLT9jRcse FpFzwg5vjQkioPrJxK/JCE8McxmSsm/1Uz/55LFTp7Uu+mIhyS4nFi1OCUP2Rild 1tC4/LjqYYI= Received: from dummy.name; Sat, 27 Jun 2009 00:25:10 -0400 Message-ID: <4A459F27.5050109@niversoft.com> Date: Sat, 27 Jun 2009 00:25: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="------------020807050203030204060205" This is a multi-part message in MIME format. --------------020807050203030204060205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable It's (usually) the contrary - on mail clients (at least those used by=20 normal people, not spammers), the MAIL FROM is generated using the user=20 account or From address, and the MAIL TO is generated from the To, Cc=20 and Bcc fields. Then, the From, To and CC fields are copied into message = headers, and the Bcc field is discarded. Spammers just put anything they want anywhere. You can prevent them from = putting your addredd in the return-path of message they send you. NH David Modoski wrote: > > Good point. I never realized that. I thought that the From:/To: fields = > were populated from the MAIL FROM and RCPT TO entries that are passed=20 > to the mail server. > > =20 > > =20 > > *From:* CommuniGate Pro Discussions [mailto:CGatePro@mail.stalker.com] = > *On Behalf Of *Nicolas Hatier > *Sent:* June 26, 2009 12:01 PM > *To:* CommuniGate Pro Discussions > *Subject:* Re: Sending FROM accounts in domain even with=20 > authentication enabled > > =20 > > > "MAIL FROM" is an SMTP command, not a mail header... The DATA portion=20 > of the SMTP transaction is usually left mostly unmodified in its way=20 > to the client. Some additional headers are added (Return-Path, which=20 > 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=20 > 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=20 > DKIM/DomainKeys. DomainKeys will read the reported "From" address, and = > 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=20 > filter is another step against impersonation, which is what you=20 > 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. > =20 > 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. > =20 > -----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 > =20 > 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. > =20 > The exact error message when using a CGP domain account > =20 > 575 david.modoski@mydomain.com send= er requires authentication > =20 > -----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 > =20 > David Modoski wrote: > =20 > > We have authentication enabled for all of our CGP accounts for send= ing > > email. This requires that the account holder authenticate to the > > server before submitting mail. I've tested by connecting to the SMT= P > > port and using a FROM address within our domain (I'm informed by th= e > > server that this account needs to authenticate before sending mail)= =2E > > However, I've just started receiving SPAM that is address FROM an > > email account within the domain. Anyone have any ideas how that mig= ht > > be getting through? > > =20 > > Thanks, > > Dave > > =20 > > =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. > =20 > 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. > =20 > Lyle Giese > LCR Computer Services, Inc. > =20 > =20 > =20 > > =20 > > --=20 > > *Nicolas Hatier* > > Niversoft id=E9es logicielles - http://www.niversoft.com > --=20 *Nicolas Hatier* > Niversoft id=E9es logicielles - http://www.niversoft.com --------------020807050203030204060205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
It's (usually) the contrary - on mail clients (at least those used by normal people, not spammers), the MAIL FROM is generated using the user account or From address, and the MAIL TO is generated from the To, Cc and Bcc fields. Then, the From, To and CC fields are copied into message headers, and the Bcc field is discarded.

Spammers just put anything they want anywhere. You can prevent them from putting your addredd in the return-path of message they send you.

NH

David Modoski wrote:

Good point. I never realized that. I thought that the From:/To: fields were populated from the MAIL FROM and RCPT TO entries that are passed to the mail server.

 

 

From: CommuniGate Pro Discussions [mailto:CGatePro@mail.stalker.com] On Behalf Of Nicolas Hatier
Sent: June 26, 2009 12:01 PM
To: CommuniGate Pro Discussions
Subject: Re: Sending FROM accounts in domain even with authentication enabled

 


"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


--

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

--------------020807050203030204060205--