Re: [vchkpw] chkuser + localhost as sender MX

2006-08-22 Thread tonix (Antonio Nati)

At 19.09 16/08/2006, you wrote:

On Wed, 16 Aug 2006 09:07:28 -0700 Tom Collins [EMAIL PROTECTED] wrote:

  I've noticed some spam sending hosts, which use e.g. localhost/
  127.0.0.1
  as their sender MX. When my mailserver tries to verify the sending
  account via bounce check (connecting to 127.0.0.1), the rcpt to:
  check is ok, because chkuser accepts unknown rcpt to's from
  localhost. Is there a settings to get rid of that?

 Better would be a patch to qmail-smtpd that only accepted localhost
 and 127.0.0.1 as the HELO name on connections from 127.0.0.1.  I
 don't know enough about chkuser to answer your original question.

This would be one possibility but in this case the mail is already in
the local queue - what we try to prevent. I think an extended chkuser
patch is the better way. While chkuser already checks for an existing
MX-record it could easily test the received A-Record against
127.0.0.0/8, RFC1918 or in case of a fqdn is it resolveable at all.


If you send me more details on how check should be done, I could try 
to put in in 2.0.10 version of chkuser.


Ciao,

Tonino


regards,
Lars Uhlmann




Re: [vchkpw] chkuser + localhost as sender MX

2006-08-16 Thread Tom Collins

On Aug 14, 2006, at 7:22 AM, Veit Guna wrote:
I've noticed some spam sending hosts, which use e.g. localhost/ 
127.0.0.1

as their sender MX. When my mailserver tries to verify the sending
account via bounce check (connecting to 127.0.0.1), the rcpt to: check
is ok, because chkuser accepts unknown rcpt to's from localhost. Is
there a settings to get rid of that?


Better would be a patch to qmail-smtpd that only accepted localhost  
and 127.0.0.1 as the HELO name on connections from 127.0.0.1.  I  
don't know enough about chkuser to answer your original question.


--
Tom Collins  -  [EMAIL PROTECTED]
Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/
QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/




Re: [vchkpw] chkuser + localhost as sender MX

2006-08-16 Thread Lars Uhlmann
On Wed, 16 Aug 2006 09:07:28 -0700 Tom Collins [EMAIL PROTECTED] wrote:

  I've noticed some spam sending hosts, which use e.g. localhost/ 
  127.0.0.1
  as their sender MX. When my mailserver tries to verify the sending
  account via bounce check (connecting to 127.0.0.1), the rcpt to:
  check is ok, because chkuser accepts unknown rcpt to's from
  localhost. Is there a settings to get rid of that?
 
 Better would be a patch to qmail-smtpd that only accepted localhost  
 and 127.0.0.1 as the HELO name on connections from 127.0.0.1.  I  
 don't know enough about chkuser to answer your original question.

This would be one possibility but in this case the mail is already in
the local queue - what we try to prevent. I think an extended chkuser
patch is the better way. While chkuser already checks for an existing
MX-record it could easily test the received A-Record against
127.0.0.0/8, RFC1918 or in case of a fqdn is it resolveable at all.

regards,
Lars Uhlmann


Re: [vchkpw] chkuser + localhost as sender MX

2006-08-16 Thread Veit Guna
Yes, I agree with Lars. Also other local IPs should be checked like
10.x.y.z something.

regards,
Veit



Lars Uhlmann schrieb:
 On Wed, 16 Aug 2006 09:07:28 -0700 Tom Collins [EMAIL PROTECTED] wrote:
 
 I've noticed some spam sending hosts, which use e.g. localhost/ 
 127.0.0.1
 as their sender MX. When my mailserver tries to verify the sending
 account via bounce check (connecting to 127.0.0.1), the rcpt to:
 check is ok, because chkuser accepts unknown rcpt to's from
 localhost. Is there a settings to get rid of that?
 Better would be a patch to qmail-smtpd that only accepted localhost  
 and 127.0.0.1 as the HELO name on connections from 127.0.0.1.  I  
 don't know enough about chkuser to answer your original question.
 
 This would be one possibility but in this case the mail is already in
 the local queue - what we try to prevent. I think an extended chkuser
 patch is the better way. While chkuser already checks for an existing
 MX-record it could easily test the received A-Record against
 127.0.0.0/8, RFC1918 or in case of a fqdn is it resolveable at all.
 
 regards,
 Lars Uhlmann