Re: [qmailtoaster] Smtproutes

[Tonix - Antonio Nati]

smtproutes works only if the domain is not in localdomains.

Il 20/08/2020 20:24, Miguel Angel Amable Ventura ha scritto:

Hello everyone,

I have been trying to set up the smtproutes file in 
/var/qmail/control/smtproutes


with the following information:

domainname.com:ip_address_dest:587

restarted qmail with:

qmailctl stop

qmailctl start

systemctl restart dovecot

But when I send an email from domainname.com it does not relay to the 
ip_address_dest server, instead it goes directly to the destination 
domain and does not do the smarthost function. Checking the logs in 
/var/log/qmail/send/current it does not even try to contact the 
smarthost! Maybe I am missing to restart any other service related to 
qmail to read the new config file?


Do you know what i am missing here to get it work ok?

Have a nice day!

Mike


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Got the willys with submission log entries

[Tonix - Antonio Nati]

Usually qmail-smtpd simply accept any sender, and then:

 * delivers always to any local address
 * relays to remote addresses only if sender ip is allowed to relay or
   if there has been a successful authentication phase before.

So, a standard 587 port accepts anything for local addresses and relays 
only if user is authenticated or IP allowed to relay.


To make this behaviour more rigid I added a flag in chkuser module 
(CHKUSER_EXTRA_MUSTAUTH_VARIABLE) which enables qmail-smtpd to accept 
only authenticated users for any type of destination address. As far as 
I remember, in this case chkuser should accept any sender, but will stop 
any destination address, writing both in logs.


See
http://opensource.interazioni.it/qmail/chkuser/documentation/chkuser_settings.html
http://opensource.interazioni.it/qmail/chkuser/documentation/faqs.html

for more informations on this flag.

Regards,

Tonino

Il 11/12/2019 21:40, Eric Broch ha scritto:


http://wiki.qmailtoaster.net/index.php/FAQs#I_see_a_message_in_my_smtp_log_that_states_.22User_and_password_not_set.2C_continuing_without_authentication.22._What_is_going_on.3F

On 12/11/2019 8:14 AM, Tahnan Al Anas wrote:

That I see in qmail send log

On Wed, 11 Dec 2019, 8:06 pm Eric Broch, > wrote:


What log?

On 12/11/2019 1:26 AM, Tahnan Al Anas wrote:

Hi Eric,

Can you tell me why I am seeing all outgoing getting out with
below log?

 success:
User_and_password_not_set,_continuing_without_authentication./


--
--

Best Regards
Muhammad Tahnan Al Anas


On Wed, Dec 11, 2019 at 1:25 AM mailto:bhow...@teamft.com>> wrote:

I have checked out authentication with my submission port
587 and I must authenticate before sending. However, I have
entries in the log from a “bad guy IP address” which say
“sender accepted” and its giving me heartburn.

2019-12-10 02:43:04.376530500 CHKUSER accepted sender: from
 
remote <4vFoWf3:unknown:64.225.41.10> rcpt <> : sender accepted

2019-12-10 03:04:09.269688500 CHKUSER accepted sender: from

 remote
<3aJfz4D7:unknown:64.225.41.10> rcpt <> : sender accepted

(Note: the IP 64.255.41.10 is the real IP of the bad guy)

There are no corresponding lines which say, “client allowed
to relay”

Note after the from address, there are two colons:
  . On all
legitimate entries, there are no such double colons.

How did this guy get that entry into my submission logs
without authenticating?  Is this something I need to worry
about?

Any input would be really appreciated

Boatner Howell

Foundaton Technologies, LLC



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Tony

[Tonix - Antonio Nati]

Which Tony?

Il 23/03/2019 00:44, Eric Broch ha scritto:

Hi Tony,

When I reply to you directly (off list) I get a delivery failure 
(Remote host said: 554 Refused. Your reverse DNS entry contains your 
IP address and a banned keyword).


Is it possible to whitelist my email address?




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] CHKUSER accepted sender but no mail

[Tonix - Antonio Nati]

You should find additional log entries with recipient informations from 
CHKUSER...
If you find them, unique reason for a message disappeared and not logged 
from qmail should be a message too big (message exceeding databytes limit).


Regards,
Tonino

Il 11/03/2019 09:03, Tahnan Al Anas ha scritto:

Dear Admin,

I am using qmailtoaster on centos 7. I have found from one domain in 
our server on smtp log, the mail is accepted in 25 port with log 
information


@40005c85f5f20a427124 CHKUSER accepted sender: from 
 remote 
 rcpt <> : sender 
accepted


But this mail is not received in user inbox and there is no log in 
qmail/send/current.


What should I Check?

--
--

Best Regards
Muhammad Tahnan Al Anas



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: [Norton AntiSpam]Re: [qmailtoaster] SMTPS (port 465) is not working

[Tonix - Antonio Nati]

I forgot to delete the word "privately" :-):-):-).

Il 12/01/2019 00:16, Tonix - Antonio Nati ha scritto:

Hello Eric,

I'm writing privately just for curiosity.
Is chkuser still used in your distribution (I wrote chkuser, and I 
follow some lists on it, but I though it was going to be abandoned)?

Did you customize any variable used by CHKUSER?
Actually I'm not using chkuser anymore, since I'm using an external 
service (which use only some parts of chkuser) for my emails.


Thanks for the info and best regards,

Tonino

Il 11/01/2019 21:40, Eric Broch ha scritto:

here's mine:

#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
RECORDIO="/usr/bin/recordio"
RECORDIO=""
export SMTPS=1
export FORCETLS=0
export SMTPAUTH="!"


exec /usr/bin/softlimit -m 12800 \
/usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c 
"$MAXSMTPD" \

-u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
$RECORDIO \
$SMTPD $VCHKPW /bin/true 2>&1

On 1/11/2019 1:36 PM, Solo wrote:

Hi Eric.


[root@post log]# cat /var/qmail/supervise/smtps/run
#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
export REQUIRE_AUTH=1
export SMTPS=1

exec /usr/bin/softlimit -m 12800 \
 /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c 
"$MAXSMTPD" \

 -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
 $SMTPD $VCHKPW /bin/true 2>&1

/Finn
Den 11-01-2019 kl. 21:27 skrev Eric Broch:

Post output of

# cat /var/qmail/supervise/smtps/run

please.

On 1/11/2019 12:36 PM, Solo wrote:

Hi List.


I am facing #5.7.1 Sorry, that domain isn't in my list of allowed
rcpsthosts (CHKUSER)
whenever i am trying to send using SMTPS - port 465.

I have created a new Minimal Centos7 server, installed qmail as per
the qmailtoaster.org receipe all the way to Qmail-1.03-3.1 (Dev repo)

rsync'ed with -u not to overwrite newer controlfiles, from my 
production
(Qmail-1.03-2.1), dumped database and checked all /var/qmail files 
and

made sure (I hope) that content in rcpthosts, virtualdomains etc was
like production server.

It works very well until I try to use port 465 to submit an e-mail 
then

#5.7.1 Sorry, that domain isn't in my list of allowed rcpsthosts
(CHKUSER) is showing up on my Thunderbird

This is the line in the SMTPS log

2019-01-11 16:38:47.075740500 CHKUSER accepted sender: from
 remote <[192.168.1.100]:unknown:xxx.xxx.xxx.xx> 
rcpt

<> : sender accepted
2019-01-11 16:38:47.129749500 CHKUSER rejected relaying: from
 remote <[192.168.1.100]:unknown:xxx.xxx.xxx.xx> 
rcpt

 : client not allowed to relay

and this is the lines from my submission log

2019-01-11 15:31:07.454431500 CHKUSER accepted sender: from
 remote
<[192.168.1.100]:unknown:xxx.xxx.xxx.xx> rcpt <> : sender accepted
2019-01-11 15:31:07.505012500 CHKUSER relaying rcpt: from
 remote
<[192.168.1.100]:unknown:xxx.xxx.xxx.xx> rcpt  : 
client

allowed to relay


So why is the senders address  in the SMTPS log
and  in the Submission log

I'm almost certain this is my issue because :: is not in the 
rcpthosts
file (I have tried a lot of different settings - and properly 
running in

cirkles now so please -HELP)  - I have not tried, yet, to change
tcp.smtp to include ip-address:allow

Cheers Finn von B





-
To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com








--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: [Norton AntiSpam]Re: [qmailtoaster] SMTPS (port 465) is not working

[Tonix - Antonio Nati]

Hello Eric,

I'm writing privately just for curiosity.
Is chkuser still used in your distribution (I wrote chkuser, and I 
follow some lists on it, but I though it was going to be abandoned)?

Did you customize any variable used by CHKUSER?
Actually I'm not using chkuser anymore, since I'm using an external 
service (which use only some parts of chkuser) for my emails.


Thanks for the info and best regards,

Tonino

Il 11/01/2019 21:40, Eric Broch ha scritto:

here's mine:

#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
RECORDIO="/usr/bin/recordio"
RECORDIO=""
export SMTPS=1
export FORCETLS=0
export SMTPAUTH="!"


exec /usr/bin/softlimit -m 12800 \
/usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
$RECORDIO \
$SMTPD $VCHKPW /bin/true 2>&1

On 1/11/2019 1:36 PM, Solo wrote:

Hi Eric.


[root@post log]# cat /var/qmail/supervise/smtps/run
#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
export REQUIRE_AUTH=1
export SMTPS=1

exec /usr/bin/softlimit -m 12800 \
 /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c 
"$MAXSMTPD" \

 -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
 $SMTPD $VCHKPW /bin/true 2>&1

/Finn
Den 11-01-2019 kl. 21:27 skrev Eric Broch:

Post output of

# cat /var/qmail/supervise/smtps/run

please.

On 1/11/2019 12:36 PM, Solo wrote:

Hi List.


I am facing #5.7.1 Sorry, that domain isn't in my list of allowed
rcpsthosts (CHKUSER)
whenever i am trying to send using SMTPS - port 465.

I have created a new Minimal Centos7 server, installed qmail as per
the qmailtoaster.org receipe all the way to Qmail-1.03-3.1 (Dev repo)

rsync'ed with -u not to overwrite newer controlfiles, from my 
production

(Qmail-1.03-2.1), dumped database and checked all /var/qmail files and
made sure (I hope) that content in rcpthosts, virtualdomains etc was
like production server.

It works very well until I try to use port 465 to submit an e-mail 
then

#5.7.1 Sorry, that domain isn't in my list of allowed rcpsthosts
(CHKUSER) is showing up on my Thunderbird

This is the line in the SMTPS log

2019-01-11 16:38:47.075740500 CHKUSER accepted sender: from
 remote <[192.168.1.100]:unknown:xxx.xxx.xxx.xx> 
rcpt

<> : sender accepted
2019-01-11 16:38:47.129749500 CHKUSER rejected relaying: from
 remote <[192.168.1.100]:unknown:xxx.xxx.xxx.xx> 
rcpt

 : client not allowed to relay

and this is the lines from my submission log

2019-01-11 15:31:07.454431500 CHKUSER accepted sender: from
 remote
<[192.168.1.100]:unknown:xxx.xxx.xxx.xx> rcpt <> : sender accepted
2019-01-11 15:31:07.505012500 CHKUSER relaying rcpt: from
 remote
<[192.168.1.100]:unknown:xxx.xxx.xxx.xx> rcpt  : 
client

allowed to relay


So why is the senders address  in the SMTPS log
and  in the Submission log

I'm almost certain this is my issue because :: is not in the rcpthosts
file (I have tried a lot of different settings - and properly 
running in

cirkles now so please -HELP)  - I have not tried, yet, to change
tcp.smtp to include ip-address:allow

Cheers Finn von B





-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] chkusr settings

[Tonix - Antonio Nati]

Eric,

as far as I remember, no.

I usually suggest to use different smtp servers for public MX server and 
authenticated users server, and disable chkuser on server for 
authenticated users.


Sorry for my bad remembering, but I've dismissed my email servers five 
years ago (going to use a collegue which relies on qmail, and for which 
I've written additional code), so I don't have anymore the day by day 
feeling.


Regards,

Tonino

Il 19/09/2017 15:43, Eric Broch ha scritto:


Rajesh,Tonino:

Without even modifying qmail wouldn't chkuser be disabled completely 
with the RELAYCLIENT setting:


RELAYCLIENT=""

Eric


On 9/19/2017 3:57 AM, Tonix - Antonio Nati wrote:

Rajesh,

I don't know which version of chkuser is included in qmailtoaster.
Behaviour has changed sometimes. I always tried to configurations 
stable, but sometimes evolutions lead to a change.

So, which is the version in qmailtoaster?

About forcing to authenticate, you need the 
*CHKUSER_EXTRA_MUSTAUTH_VARIABLE* feature, but it exists from 2.0.9.


Check documentation in 
http://opensource.interazioni.it/qmail/chkuser/documentation/chkuser_settings.html.


Regards,

Tonino

Il 19/09/2017 11:39, Rajesh M ha scritto:

Tonino,

thanks for the detailed information

just wanted a final clarification

i require chkuser for smtp authentication purpose only on port 587 for my 
customers who need unrestricted email sending with authentication.

I have compiled a separate cdb file called tcp.smtp.587.cdb exclusively for 
port 587.

in my chkuser_settings.h i have uncommented and recompiled qmailtoaster

#define CHKUSER_STARTING_VARIABLE "CHKUSER_START"

so in my tcp.smtp, if i set

CHKUSER_START="NONE"

it should allow my customers to authenticate and send out emails without any 
chkuser checks other than smtp authentication, right ?

thanks,
rajesh



will that disable all other aspects for


- Original Message -----
From: Tonix - Antonio Nati [mailto:to...@interazioni.it]
To:qmailtoaster-list@qmailtoaster.com
Sent: Tue, 19 Sep 2017 09:23:01 +0200
Subject:

Eric,

it looks like I told and wrote wrong instructions (and I remembered
wrong sequences in last reply).

Let's say there is a potential bug in the application, which I'm seeing
only now, after years. It is not really a code bug. It is that I wrote
something in the code and something different in documentation.

Logic (in version 2.0.9 of chkuser code) says:

  1. if CHKUSER_ALWAYS_ON is declared, chkuser is always ON:
 starting_value = 1 (this option is not compatible in compilation
 with CHKUSER_STARTING_VARIABLE; only one of them may be defined).
  2. if CHKUSER_STARTING_VARIABLE (by default CHKUSER_START) is NOT
 declared checkuser works on domain base (starting_value = 0)
  3. if CHKUSER_STARTING_VARIABLE (by default CHKUSER_START) is declared
 and NOT assigned, checkuser is disabled (starting_value = -1)
  4. if CHKUSER_STARTING_VARIABLE is declared and assigned AND equal to
 ALWAYS, checkuser is always ON (starting_value = 1)
  5. if CHKUSER_STARTING_VARIABLE is declared and assigned AND equal to
 DOMAIN, checkuser works on domains base (starting_value = 0)
  6. if CHKUSER_STARTING_VARIABLE is declared and assigned with values
 different from ALWAYS and DOMAIN, checkuser works on domains bases
 (starting_value = 0)
  7. if CHKUSER_STARTING_VARIABLE (by default CHKUSER_START) is NOT
 declared checkuser works on domains base (starting_value = 0)

So, the real default is chekuser working on domains base. Other options
lead to different behaviours. If you want to disable it, you must
declare a variable and not assign it (not assign it is different than
assigning "" or empty value).

For a better code and a better usage, it should be (in red the code I
added):

 

 +#if defined CHKUSER_STARTING_VARIABLE
 +starting_string = env_get (CHKUSER_STARTING_VARIABLE);
 +if (starting_string) {
 +if (strcasecmp(starting_string, "ALWAYS") == 0) {
 +starting_value = 1;
 +} else if (strcasecmp(starting_string, "DOMAIN") ==
 0) {
 +starting_value = 0;
 +} else if (strcasecmp(starting_string, "NONE") == 0) {
 +starting_value = -1;
 +}
 +} else {
 +starting_string = "";
 +starting_value = -1;
 +}
 +#endif

 

In such a case value "NONE" and absence of variable assign would disable
chkuser. ALWAYS would enable it forever, any other value would enable it
on domain base.

Sorry, and thanks for forcing me to read again the code.

Tonino



Hi Tonino,

When CHKUSER_START is set, or not set, the ensuing logic of chkuser
keys on the value of 'starting_value', correct?

1) CHKUSER_START="NONE" (starting_v

Re: [qmailtoaster] chkusr settings

[Tonix - Antonio Nati]

Eric,

it looks like I told and wrote wrong instructions (and I remembered 
wrong sequences in last reply).


Let's say there is a potential bug in the application, which I'm seeing 
only now, after years. It is not really a code bug. It is that I wrote 
something in the code and something different in documentation.


Logic (in version 2.0.9 of chkuser code) says:

1. if CHKUSER_ALWAYS_ON is declared, chkuser is always ON:
   starting_value = 1 (this option is not compatible in compilation
   with CHKUSER_STARTING_VARIABLE; only one of them may be defined).
2. if CHKUSER_STARTING_VARIABLE (by default CHKUSER_START) is NOT
   declared checkuser works on domain base (starting_value = 0)
3. if CHKUSER_STARTING_VARIABLE (by default CHKUSER_START) is declared
   and NOT assigned, checkuser is disabled (starting_value = -1)
4. if CHKUSER_STARTING_VARIABLE is declared and assigned AND equal to
   ALWAYS, checkuser is always ON (starting_value = 1)
5. if CHKUSER_STARTING_VARIABLE is declared and assigned AND equal to
   DOMAIN, checkuser works on domains base (starting_value = 0)
6. if CHKUSER_STARTING_VARIABLE is declared and assigned with values
   different from ALWAYS and DOMAIN, checkuser works on domains bases
   (starting_value = 0)
7. if CHKUSER_STARTING_VARIABLE (by default CHKUSER_START) is NOT
   declared checkuser works on domains base (starting_value = 0)

So, the real default is chekuser working on domains base. Other options 
lead to different behaviours. If you want to disable it, you must 
declare a variable and not assign it (not assign it is different than 
assigning "" or empty value).


For a better code and a better usage, it should be (in red the code I 
added):


   

   +#if defined CHKUSER_STARTING_VARIABLE
   +starting_string = env_get (CHKUSER_STARTING_VARIABLE);
   +if (starting_string) {
   +if (strcasecmp(starting_string, "ALWAYS") == 0) {
   +starting_value = 1;
   +} else if (strcasecmp(starting_string, "DOMAIN") ==
   0) {
   +starting_value = 0;
   +} else if (strcasecmp(starting_string, "NONE") == 0) {
   +starting_value = -1;
   +}
   +} else {
   +starting_string = "";
   +starting_value = -1;
   +}
   +#endif

   

In such a case value "NONE" and absence of variable assign would disable 
chkuser. ALWAYS would enable it forever, any other value would enable it 
on domain base.


Sorry, and thanks for forcing me to read again the code.

Tonino



Hi Tonino,

When CHKUSER_START is set, or not set, the ensuing logic of chkuser 
keys on the value of 'starting_value', correct?


1) CHKUSER_START="NONE" (starting_value=1)
2) CHKUSER_START="ANYTHING ELSE" (starting_value=1)
3) CHKUSER_START="" (starting_value=0)
4) unset -v CHKUSER_START (starting_value=-1) *A situation where CHKUSER_START 
is not even specified in either either the smtpd run file or tcp.smtp.

In the code the logic falls out in a different manner for -1, 0, or 1.

So wouldn't CHKUSER_START="NONE" (starting_value=1) fall out differently than 
CHKUSER_START="" (starting_value=0) or CHKUSER_START not specified (starting_value=-1)?

Eric



On 9/18/2017 1:58 PM, Tonix - Antonio Nati wrote:

Eric,

you are right. I wrote "NONE" instead of "everything different from 
ALWAYS or DOMAIN" in order to semplify things, but the concept is 
clear: every value different from DOMAIN or ALWAYS will disable chkuser.


Note: everything is disabled except the 
*CHKUSER_EXTRA_MUSTAUTH_VARIABLE* functionality.


Regards,

Tonino

Il 18/09/2017 21:51, Eric Broch ha scritto:


Rajesh,

I apologize for the responses that have not been helpful. After 
looking at the settings (below) from here 
<http://opensource.interazioni.it/qmail/chkuser/documentation/chkuser_settings.html> 
and going through the code, I'm convinced that the "NONE" option 
will not be helpful or do what you expect or what the documentation 
even states (Tonix, please review):




CHKUSER_STARTING_VARIABLE 2.0.5 commented "CHKUSER_START"
Sets the variable that must be read, at qmail-smtpd start, in order 
to understand how to use chkuser for any domain. The variable must 
be filled with the following values:


NONE = chkuser will not work
ALWAYS = chkuser will work always
DOMAIN = chkuser will work depending on single domain settings

Any other value, or a missing value, will disable chkuser.
Incompatible with CHKUSER_ALWAYS_ON since 2.0.9



Since you've already defined 'CHKUSER_STARTING_VARIABLE' at compile 
time in chkuser_settings.h, I think simply leaving the variable 
CHKUSER_START (null) out of both the run file and the tcp.smtp file 
you will get what you've been expecting (stop and start qmail of 
c

Re: [qmailtoaster] chkusr settings

[Tonix - Antonio Nati]

Eric,

you are right. I wrote "NONE" instead of "everything different from 
ALWAYS or DOMAIN" in order to semplify things, but the concept is clear: 
every value different from DOMAIN or ALWAYS will disable chkuser.


Note: everything is disabled except the 
*CHKUSER_EXTRA_MUSTAUTH_VARIABLE* functionality.


Regards,

Tonino

Il 18/09/2017 21:51, Eric Broch ha scritto:


Rajesh,

I apologize for the responses that have not been helpful. After 
looking at the settings (below) from here 
 
and going through the code, I'm convinced that the "NONE" option will 
not be helpful or do what you expect or what the documentation even 
states (Tonix, please review):




CHKUSER_STARTING_VARIABLE 2.0.5 commented "CHKUSER_START"
Sets the variable that must be read, at qmail-smtpd start, in order to 
understand how to use chkuser for any domain. The variable must be 
filled with the following values:


NONE = chkuser will not work
ALWAYS = chkuser will work always
DOMAIN = chkuser will work depending on single domain settings

Any other value, or a missing value, will disable chkuser.
Incompatible with CHKUSER_ALWAYS_ON since 2.0.9



Since you've already defined 'CHKUSER_STARTING_VARIABLE' at compile 
time in chkuser_settings.h, I think simply leaving the variable 
CHKUSER_START (null) out of both the run file and the tcp.smtp file 
you will get what you've been expecting (stop and start qmail of 
course). The settings section indicates this as well:

"Any other value, or a missing value, will disable chkuser."
In fact, in my study of the code, I don't think the NONE option does 
anything. If Tonix is looking at this thread maybe he could help 
*fingers crossed*.


Please let me know how it goes.

Eric

On 9/18/2017 12:33 PM, Eric Broch wrote:


Rajesh,

Can you set this in /var/qmail/supervise/smtp/run

CHKUSER_START="NONE"
export CHKUSER_START

exec 
/usr/bin/softlimit




On 9/18/2017 12:10 PM, Eric Broch wrote:


Sorry, my mistake, Rajesh,

#define CHKUSER_STARTING_VARIABLE "CHKUSER_START"

sets CHKUSER_STARTING_VARIABLE to CHKUSER_START


On 9/18/2017 11:53 AM, Eric Broch wrote:


Rajesh,

In the code there is no check for 'CHKUSER_START' but there is for 
'CHKUSER_STARTING_VARIABLE'. So, in tcp.smtp use 
'CHKUSER_STARTING_VARIABLE' like so:


CHKUSER_STARTING_VARIABLE="NONE"

then stop and start qmail.

Here's the code and the environment variable chkuser checks:



starting_string = env_get (CHKUSER_STARTING_VARIABLE);
if (starting_string) {
if (strcasecmp(starting_string, "ALWAYS") == 0) {
starting_value = 1;
} else if (strcasecmp(starting_string, "DOMAIN") == 
0) {

starting_value = 0;
}
} else {
starting_string = "";
starting_value = -1;
}



Eric

On 9/18/2017 11:38 AM, Eric Broch wrote:

Sorry to ask this, but did you restart qmail after the change?

On 9/18/2017 8:52 AM, Rajesh M wrote:

hi eric

i wished to disable chkusr mx check, format check etc .. and turn off chkuser using 
CHKUSER_START="NONE"

the default installation of qmail always keeps chkuser on with no control
so i rebuild chkuser from source

CHANGES FOR CHK USER
EXTRA SOURCE FROM RPM
rpm -Uvh qmail-1.03-1.qt.src.rpm
nano /root/rpmbuild/SPECS/qmail.spec
put a sleep in this for 120 seconds

open 2nd window of ssh
service qmail stop

in first window run
rpmbuild -bb --define "dist .qt.el6" qmail.spec
the process will now for halt for 180 seconds which gives us time to modify 
chkuser_settings.h settings

in second window go to
cd /root/rpmbuild/BUILD/qmail-1.03
nano chkuser_settings.h

UNCOMMENT THIS
#define CHKUSER_STARTING_VARIABLE "CHKUSER_START"

comment out the following
/* #define CHKUSER_RCPT_MX */
/* #define CHKUSER_ENABLE_USERS_EXTENSIONS */
/* #define CHKUSER_USERS_DASH '-' */


now the problem is that even if I set CHKUSER_START="NONE" i get errors

here is my tcp.smtp file for submission port (i use separate tcp.smtp files for 
25 and 587)

:allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_START="NONE"

i still get errors as such

2017-09-18 11:48:08.810159500 CHKUSER rejected rcpt: 
from  remote 
 rcpt  : max number of 
recipients
2017-09-18 11:48:09.894092500 CHKUSER rejected intrusion: 
from  remote 
 rcpt  : rcpt ignored, 
session over intrusion threshold
2017-09-18 11:48:11.226284500 CHKUSER rejected intrusion: 
from  remote 
 rcpt  : rcpt ignored, 
session over intrusion threshold

help required please

rajesh

Re: [qmailtoaster] qmail - couldn't find any host named grupodecor.com

[Tonix - Antonio Nati]

It looks like nameservers of grupodecor.com do not answer to TCP queries.

http://dnscheck.pingdom.com/?domain=grupodecor.com=1498055971=1

Regards,

Tonino

Il 21/06/2017 14:01, Jeff Koch ha scritto:

Hi Boheme:

Sorry If I was rude - I do appreciate your response on 6/12 and I 
considered the two solutions you recommended.


With respect to routing the mail through mailcleaner - if I understand 
the purpose of this recommendation - I don't think the problem has 
anything to the contents of the email we are trying to send. Qmail is 
saying that it couldn't find any host named grupodecor.com. So it's an 
issue on the side of our sending mailserver and I'd really like to 
understand how our mailserver came to that conclusion - what exactly 
is qmail testing to determine that.


With respect to your second recommendation about installing djbdns we 
already have a BIND server running on our network and I prefer not to 
install another DNS server ( I will if I absolutely have to.)


The problem here does not seem to be related to Outlook 365 since we 
are able to send email to many other domains with email hosted by Outlook.


I really would like to understand what's going on in the qmail code 
that is causing qmail to come to the conclusion that it can't find 
this host. ( What exactly does qmail mean by 'host' ? Does this mean 
qmail can't find the DNS zone? Can't find an 'A' record or host? Can't 
find the MX record or host?)


Jeff



On 6/20/2017 11:34 PM, Boheme wrote:

I replied with two solutions to this problem on 6/12.

You never replied, so I have no idea whether you tried my suggestions.

-Sent from my Pip-Boy 3000

On Jun 20, 2017, at 8:10 PM, Jeff Koch > wrote:




I'm having trouble sending email to anyone at grupodecor.com 
. All of my qmail mailservers say:


Sorry, I couldn't find any host named grupodecor.com 
. (#5.1.2)


And yet I can send from my hotmail account and the MX host - 
grupodecor-com.mail.protection.outlook.com 
 - responds to 
smtp connections. Try sending an email to anyone at that domain ( 
like ab...@grupodecor.com  )


Anyone know why thisis happening?

Jeff





--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Sending outbound email works, but takes about 10 seconds.

[Tonix - Antonio Nati]

Check your dns. It looks like it takes time to solve client reverse ip.

Regards,

Tonino

Il 19/02/2017 17:59, CarlC Internet Services Service Desk ha scritto:


-Original Message-
From: Eric Broch


does this happen in your webmail, squirrelmail and roundcube?


Nope... Only with anything using smtp-ssl (port 465)...

Carl


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] catch all account and the spam

[Tonix - Antonio Nati]

Il 11/07/2016 20:16, CarlC Internet Services Service Desk ha scritto:


>*From:*Dan McAllister

>Now I can’t just reply to HOW without adding my 2-cents worth as to 
why I think “bounce-no-mailbox” is the WORST of the options:


>-It allows spammers to “mine” your domain for “good” email addresses 
(which then get sold!)… how? Send a note to a...@yourdomain.com 
, b...@yourdomain.com , 
etc. For each one that does NOT get a bounceback, you have a good 
address! SPAM IT!


>-Once your domain is “mature” (been around a few years), your 
“catchall” account will get thousands of emails a day – from spammers 
trying to mine your domain!


My question is, would this not lead spammer to try to use your domain 
name as a FROM? What I mean by that is, if you’re not bouncing the bad 
addresses, then a spammer can use your domain [I know, many don’t 
check SPF or where the domain is allowed to send email from records], 
to send email outbound. Most email servers will check to see if the 
return email address is valid, and qmail would say 
anth...@yourdomain.com  is valid. While 
it would get dumped into /dev/null since you have “delete” as the 
final destination, I’m not entirely sure allowing all email address 
for your domain to work is a good idea.


I know a few years ago, I did have a few customers this happened to. 
We had to disable the catch-all and instead, set it to 
bounce-no-mailbox. When we did that, the spammers stopped trying to 
use the domain as a “from” address [and yes, SPF records made no 
difference… it was the open catch-all that led the spammers to use the 
domain as a “from” address].




I agree. And, more, hiding addresses is not what our customers ask for.
Our customers want their counterparts to be correctly informed if an 
email is not being correctly delivered as well as they want to know if a 
message sent has been delivered. Business is business.


Like for phone or fax, they want a 'number not existing' to be shown to 
who's calling if number is not existing.
For the same reason, we disabled grey listings years ago, because every 
message must be delivered in seconds, and a ten minutes delay is no more 
acceptable.


Our job is to make our customer's work simple, figthing SPAM in every 
possible way which does not disturb their work.


Regards,

Tonino


Again, YMMV…

Carl




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] queue is flooding user

[Tonix - Antonio Nati]

It's a personal and business question, and it depends a lot on customer 
needs.


From my point of view, emails are my business but are property of 
customers, and I must make my best in order to let them control their 
emails or have the best communication with their business partners using 
emails.


Deleting messages to wrong recipients means to let senders believe their 
email has been delivered even if they mispelled the address, instead to 
advice them to correct the address.


We are working this way since 15 years, and we never had problems with 
this way of thinking.


Probably attacks may suggest temporary restrictions, but only in 
exceptional cases, not for normal usage.


Normal solution (for us) is to reject messages at SMTP level, as it is 
done with paper email (unknown recipient) and voice calls (sorry, I'm 
not the person you are looking for).


Regards,

Tonino


Il 09/10/2015 15:32, Dan McAllister ha scritto:

Rajesh:

I understand -- and if all the "players" in the email world were 
legitimate, kind, and thoughtful ... there wouldn't be QMail at all, 
because sendmail would still be doing a fine job and the 
configurations therein wouldn't be so hard after all.


But that is not the REAL world. In THIS world, people actively work to 
abuse mail servers -- and many seek little more than the "fun" of 
disabling or at least disrupting mail service... and we (as mail 
admins) need to be PROACTIVE (not just reactive) in mitigating the 
threats. If I wasn't clear in my initial response -- this is what 
brought you to ask the original question in the first place! (Your 
queues are filling up with invalid bounce messages).


That being said, the "bounce-no-mailbox" option is, in my opinion, the 
WORST of the 3 available options. It serves as an open invitation to:
 - shutdown your mail server at-will with bounce and double-bounce 
messages that will clog your queues for days
 - mine your system for valid email addresses (those that do not 
bounce) -- and sell the results to SPAM lists

 - multiple other "attacks" ... this isn't the point of this email...
Sadly, it is also the "default" for our vpopmail implementations.

But, _*there is another option*_ (other than "bounce-no-mailbox" or 
"delete").


If you fear that you may lose or miss something important, then
replace the last word with an _*email address*_ (preferably on
your server so delivery is local). This way messages sent to
non-existent mailboxes will arrive in a specified mailbox and NOT
bounce. You can periodically check that mailbox for misaddressed
messages -- but be prepared to get a LOT of SPAM!

This has the same benefits as "delete" (from the outside world
perspective, everything is accepted) but still gives you a place
to go to check for misdirected messages.

NOTE: When clients want this, I typically create a "mailbox" that
is NOT a legitimate Internet mail address. While it may not stay
that way forever, I use a "non-existent" (so far) *.mail* TLD for
these "catchall" accounts. So, for example, my client *abc.com*
wants a catchall account, I configure it as
*catch...@abc.com./mail/*//-- vpopmail has no issue creating the
accounts, and the client can access the mailbox just fine, but no
outside mailer will ever succeed in deliberately sending mail to
or from that account, and my client cannot accidentally send mail
from that account.

If I have learned anything from the past 18 years of being an email 
admin it is that nothing is as easy as it seems. AKA: The devil is in 
the details.


If you insist on keeping the "bounce-no-mailbox" option, get yourself 
some qmail queue handling tools (like qmHandle or qmqtool), not to 
mention qfixq -- all of which can be found with a simple google search.


Good luck!

Dan McAllister
IT4SOHO





On 10/9/2015 5:45 AM, Rajesh M wrote:

dan

sorry to contradict but in my personal opinion this is not a good idea  if 
a the sender makes a mistake then my customer will not receive the email and 
nobody will know.

rajesh

- Original Message -
From: Dan McAllister [mailto:q...@it4soho.com]
To:qmailtoaster-list@qmailtoaster.com
Sent: Thu, 8 Oct 2015 15:01:57 -0400
Subject: Re: [qmailtoaster] queue is flooding user

I suspect the queue messages that are stacking up are for the delivery
of the bounce -- which is also likely going to a non-existent user or
domain.

My STRONGEST suggestion is to NOT BOUNCE messages that are directed to
non-existent users!!!
To do this, cd to the top of the domain in vpopmail (e.g.:
/home/vpopmail/domains/)
Then examine the file .qmail-default.
You want the last word to be "delete" not "bounce-no-mailbox"

Dan


On 10/8/2015 2:51 PM, Eric Broch wrote:

No one should be able to get a message in your queue to a non-existent
user unless they're using an account that they've hacked.
Someone correct me if I'm wrong.

On 10/8/2015 12:37 PM, Eric Broch wrote:

Has someone hacked a 

Re: [qmailtoaster] queue is flooding user

[Tonix - Antonio Nati]

Il 08/10/2015 19:59, Rajesh M ha scritto:

spammer is emailing a non existent user on my server.

qmailtoaster is accepting the email and then trying to respond back

my queue is flooding because ot this

should'nt chkuser be directly bouncing the email during smtp transaction time 
when email id is not present on the server ?


Yes. If correctly enabled, it will do. It chkuser enabled?

Do you see any chkuser entry in smtp log, related to that recipient?

Tonino



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Forward to a Different Server

[Tonix - Antonio Nati]

Have also to delete/comment entry for that domain in users.

Tonino

Il 08/07/2015 18:50, Helmut Fritz ha scritto:


Put the domain in your smtproutes file with an entry like this:

domain.com newserver.domain.com

then all mail for that domain will be forwarded to the new server.  I 
believe this will work for you.


*From:*Gilbert Gutierrez [mailto:mailing-li...@phxinternet.com] *On 
Behalf Of *Gilbert T. Gutierrez, Jr.

*Sent:* Wednesday, July 08, 2015 9:28 AM
*To:* qmailtoaster-list@qmailtoaster.com
*Subject:* Re: [qmailtoaster] Forward to a Different Server

The MX records are changed. Some of the users are still using the old 
server for snmp and therefore their email goes into the accounts on 
the old server. Qmailtoaster looks locally before hitting DNS, right?


Gilbert

On 7/8/2015 9:13 AM, Edwin C wrote:

Just change your MX entry to the new email server.



Date: Wed, 8 Jul 2015 08:18:14 -0700
From: mailing-li...@phoenixinternet.net
mailto:mailing-li...@phoenixinternet.net
To: qmailtoaster-list@qmailtoaster.com
mailto:qmailtoaster-list@qmailtoaster.com
Subject: [qmailtoaster] Forward to a Different Server

I have a domain on my Qmail Server that I am migrating to another
server. I want both servers to be up as I am transitioning the
domain. My question is, how do I keep the old server up and have
it just forward new email destined to the domain to the new server
and not try to capture it locally?

Gilbert Gutierrez




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Forward to a Different Server

[Tonix - Antonio Nati]

Il 08/07/2015 18:58, Tonix - Antonio Nati ha scritto:

Have also to delete/comment entry for that domain in users.


Just to correct my quick (and wrong)  answer, after modifying 
smtproutes, you must be sure that domain is not in 
/var/qmail/control/virtualdomains and locals.


This is the best way to route safetly messages to a new server.

Regards,

Tonino





Tonino

Il 08/07/2015 18:50, Helmut Fritz ha scritto:


Put the domain in your smtproutes file with an entry like this:

domain.com newserver.domain.com

then all mail for that domain will be forwarded to the new server.  I 
believe this will work for you.


*From:*Gilbert Gutierrez [mailto:mailing-li...@phxinternet.com] *On 
Behalf Of *Gilbert T. Gutierrez, Jr.

*Sent:* Wednesday, July 08, 2015 9:28 AM
*To:* qmailtoaster-list@qmailtoaster.com
*Subject:* Re: [qmailtoaster] Forward to a Different Server

The MX records are changed. Some of the users are still using the old 
server for snmp and therefore their email goes into the accounts on 
the old server. Qmailtoaster looks locally before hitting DNS, right?


Gilbert

On 7/8/2015 9:13 AM, Edwin C wrote:

Just change your MX entry to the new email server.



Date: Wed, 8 Jul 2015 08:18:14 -0700
From: mailing-li...@phoenixinternet.net
mailto:mailing-li...@phoenixinternet.net
To: qmailtoaster-list@qmailtoaster.com
mailto:qmailtoaster-list@qmailtoaster.com
Subject: [qmailtoaster] Forward to a Different Server

I have a domain on my Qmail Server that I am migrating to another
server. I want both servers to be up as I am transitioning the
domain. My question is, how do I keep the old server up and have
it just forward new email destined to the domain to the new
server and not try to capture it locally?

Gilbert Gutierrez




--

 Inter@zioniInterazioni di Antonio Nati
http://www.interazioni.it   to...@interazioni.it




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] virtual SUB-domain on the VPOPAMAIL

[Tonix - Antonio Nati]

Sorry, I've read wrongly the lines you submitted.

You already used .qmail-hoge, as it sould be.

Check if you have valias enabled. In such a case these file aliases will 
not work, and you must use Mysql records.


Regards,

Tonino


Il 09/02/2015 00:54, Tonix - Antonio Nati ha scritto:
By default chkuser does not check for .qmail-xxx-default in virtual 
domains.

You must write the alias file name exactly: .qmail-hoge.

For enabling searching of default files (like .qmail-hoge-default) 
there is an option which must be enabled and compiled.


Tonino


Il 08/02/2015 09:34, NoriyukiHayashi ha scritto:

Hi,

I checked modified.
/var/qmail/alias/.qmail- is working.
But /home/vpopmail/domains/sub.domain/.qmail- is not working yet.

Anybody has idea?

Kind regards,
Noriyuki Hayashi




Hi,

Thank you for your advice.
I guess that I've done.
But I will confirm again on Monday.
The man always happen like this that I agree.

Thank you so much

Kind regards,
Noriyuki Hayashi





Hi.

Have You inserted the sub domain into rcpthosts and virtualdomains ?

Regards,
Finn

Den 07-02-2015 kl. 15:18 skrev Noriyuki Hayashi:

Hi,

Thank you for kindly support.
Let me know if you have any good idea.

Virtual SUB-domain with qmail-toaster and vpopmail.

Environment
CentOS-5.11 64bit
qmail-toaster works fine.

I added virtual sub domain on the vpopmail.
Real exist user works fine.
but .qmail-hoge-default can't receive as alias.

I am wondering some solution for this issue.

 below received message --
User and password not set, continuing without authentication.
192.168.1.11 does not like recipient.
Remote host said: 511 sorry, no mailbox here by that name (#5.1.1 
- chkuser)


 smtp/current log 
@400054d616341b297bcc tcpserver: pid 1443 from 192.168.1.11
@400054d616341b2a6244 tcpserver: ok 1443
sub.hoge.jp:192.168.1.11:25 :192.168.1.2::57139
@400054d616341d03e8ec CHKUSER rejected rcpt: from 
h...@hoge.jp::
remote main.hoge.jp:unknown:192.168.1.2 rcpt 
f-...@sub.hoge.jp :

not existing recipient
@400054d616351d2b470c tcpserver: end 1443 status 0
@400054d616351d2b4af4 tcpserver: status: 0/100

Kind regards,
Noriyuki Hayashi



-
To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com




-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com




--
NoriyukiHayashinhaya...@wats.gr.jp ibisMailで送信！

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com




--
NoriyukiHayashinhaya...@wats.gr.jp ibisMailで送信！

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com







--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] virtual SUB-domain on the VPOPAMAIL

[Tonix - Antonio Nati]

By default chkuser does not check for .qmail-xxx-default in virtual domains.
You must write the alias file name exactly: .qmail-hoge.

For enabling searching of default files (like .qmail-hoge-default) there 
is an option which must be enabled and compiled.


Tonino


Il 08/02/2015 09:34, NoriyukiHayashi ha scritto:

Hi,

I checked modified.
/var/qmail/alias/.qmail- is working.
But /home/vpopmail/domains/sub.domain/.qmail- is not working yet.

Anybody has idea?

Kind regards,
Noriyuki Hayashi




Hi,

Thank you for your advice.
I guess that I've done.
But I will confirm again on Monday.
The man always happen like this that I agree.

Thank you so much

Kind regards,
Noriyuki Hayashi





Hi.

Have You inserted the sub domain into rcpthosts and virtualdomains ?

Regards,
Finn

Den 07-02-2015 kl. 15:18 skrev Noriyuki Hayashi:

Hi,

Thank you for kindly support.
Let me know if you have any good idea.

Virtual SUB-domain with qmail-toaster and vpopmail.

Environment
CentOS-5.11 64bit
qmail-toaster works fine.

I added virtual sub domain on the vpopmail.
Real exist user works fine.
but .qmail-hoge-default can't receive as alias.

I am wondering some solution for this issue.

 below received message --
User and password not set, continuing without authentication.
192.168.1.11 does not like recipient.
Remote host said: 511 sorry, no mailbox here by that name (#5.1.1 - chkuser)

 smtp/current log 
@400054d616341b297bcc tcpserver: pid 1443 from 192.168.1.11
@400054d616341b2a6244 tcpserver: ok 1443
sub.hoge.jp:192.168.1.11:25 :192.168.1.2::57139
@400054d616341d03e8ec CHKUSER rejected rcpt: from h...@hoge.jp::
remote main.hoge.jp:unknown:192.168.1.2 rcpt f-...@sub.hoge.jp :
not existing recipient
@400054d616351d2b470c tcpserver: end 1443 status 0
@400054d616351d2b4af4 tcpserver: status: 0/100

Kind regards,
Noriyuki Hayashi



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



--
NoriyukiHayashinhaya...@wats.gr.jp ibisMailで送信！

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



--
NoriyukiHayashinhaya...@wats.gr.jp ibisMailで送信！

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] question concerning chkuser

[Tonix - Antonio Nati]

It is a known bug (or feature? :-) ).
Counters are not reset during same session. Probably all messages are 
sent in same session, that's to say client open 200 smtp session within 
same connection.


3 solutions:

 * raise the limit
 * tell the customer to force single message sessions
 * if the user is authenticated, disable chkuser for authenticated
   users (I stronly suggest this option).

Regards,

Tonino


Il 29/10/2014 21:14, Cecil Yother ha scritto:

Have you tried increaaing the limit to 200?

Rajesh M. wrote:

hi

i have a problem with one of my clients

the client composes multiple emails ie over 200 separate emails in his outbox 
and then sends them together.
each mail is addressed to one single recepient email id only.

in chkuser i had set the limit to : CHKUSER_RCPTLIMIT to 50
which i assumed that one single email may have upto 50 recepients

however while sending these 200 emails together my client gets chkuser error 
that :

The following recipient(s) cannot be reached:
'a...@b.com' on 14/10/2014 2:46 AM
550 5.7.1 sorry, you are violating our security policies (chkuser)

i wanted to know why this error comes since each email contains one single 
recepient only

rajesh




-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com


--



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Send/Receive quotas in QMT

[Tonix - Antonio Nati]

Il 09/10/2014 18:39, Dan McAllister ha scritto:

QMT Enthusiasts:

I am in DESPERATE need of a way to rate-limit certain users on my 
system. Not only would it help me stop a sometimes well-intentioned, 
but otherwise abusive user, but it would also help limit the impact of 
virus-infected clients as well.


Specifically, I would like for there to be a way to limit users to, 
say, 250 messages a day.  (We're talking outbound messages here, not 
inbound)


If it means moving this client away from QMT, so be it -- but I don't 
know of any other mail program that would do this either...


Any ideas?

Dan McAllister



I have some ideas on how to do that on qmail/vpopmail, but it means to 
add custom code to qmail or vpopmail (it should be a payed job).


Regards,

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: SMTP issue

[Tonix - Antonio Nati]

Il 07/10/2014 21:31, Eric Broch ha scritto:

On 10/4/2014 12:25 AM, Tonix - Antonio Nati wrote:

Il 02/10/2014 20:11, Cecil Yother, Jr. ha scritto:


On 10/02/2014 10:19 AM, Tonix - Antonio Nati wrote:

Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:

Il 02/10/2014 18:52, Eric Broch ha scritto:

On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:

Il 02/10/2014 18:02, Eric Broch ha scritto:

On 10/2/2014 9:10 AM, Eric Broch wrote:

On 10/2/2014 8:30 AM, Bharath Chari wrote:

On 10/02/2014 04:59 PM, Eric Broch wrote:

On 10/2/2014 1:32 AM, Bharath Chari wrote:

On 09/25/2014 06:44 PM, Bharath Chari wrote:

On 09/25/2014 05:50 PM, Eric Broch wrote:

H. Is it always exactly one minute from begin to end? That would

appear to indicate some timer cutting out. It could be spamdyke
closing the session depending on your idle-timeout-secs= value. I'm
guessing 60, which is probably ok. I've upped mine to 180, and I
don't
recall exactly why I did that. Wouldn't hurt to bump it up I
suppose.

Still, the other end should have replied to your 220 message
before 58
seconds elapsed.

I wonder if there's a routing table misconfigured somewhere along
the
way. I've seen instances where an errant routing table entry can
cause
every nth packet to get dropped along the way. Are you seeing
reliable
pings over a period of a minute or so? If not, I'd suspect a network
issue.

At this point, I'd guess that QMT may be terminating a little soon,
and there's also a network problem somewhere along the way.

Again, just a guess.

P.S. Nice to see such accomplished people as Tonino and Bharath
helping out. Thanks guys!


No, it is not always one minute, sometimes it is up to thirty seconds
longer. I don't think spamdyke is closing the session as my
idle-timeout-secs is set to 480, and I don't recall either why I set
mine so high. While telnet(ing) to their host on port 25 initially
and
it is 'trying' to connect, I can open another terminal and run the
same
telnet command and I'll get their greeting right away.

I agree, their host should have replied faster than 58 seconds after
the
SMTP greeting, unless the greeting is never getting to there host.
There
host does not have ICMP protocol turned on. I could ask them to do
so.

If I have spamdyke set to terminate after 480 seconds what else
would be
terminating the connection?

And, ditto. Thanks for the help Tonino and Bharath!!!


Thanks hardly required. The problem still remains :(
OK, since you're having a problem even when doing a RAW telnet (the
initial connection), the MTA related issue can be ruled out for now.
However, it would be great if you could telnet from ANOTHER network
and see if the pattern remains the same (of the initial connection
being slow, and the next connection being fast).

Are you doing the telnet using IP or hostname? Let's rule out DNS
lookup related issues.

Bharath

@Eric Broch: Curious to know how this issue panned out. Did it resolve
itself?

Bharath

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com


Bharath,

And, also, it doesn't matter whether I use the hostname of the IP
Address same results.

I can telnet on port 25 to the problem host from [an]other location(s)
and it works just fine.



There you go. There's probably nothing you can do from your end - it's
most likely a firewall at their end. However, as a last ditch test,
can you also try to telnet to port 25 on their mail server from
ANOTHER machine on the same network as the QMT machine.

Wishing you the best :)

Bharath

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com


Thanks again, Bharath

I've done that too (from ANOTHER machine on the same network) with the
same results--delay or no connection at all.

Eric


-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com


Hi Bharath,

I just received an email from the problematic mx host's IT department.
They've done a test with SmtpDiag from their mx host and they cannot
connect to our mx host from their side either.

Eric

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com




Tonino,
I suppose all your network comes out using the same IP, or more 
IP which are mapped to same domain.
Yes. On our end we have a NAT(ed) firewall. We also have an MPLS 
circuit for certain private address ranges on the WAN interface.


Check if you have reverse IP issues...

Reverse DNS checks out Okay on both ends.


You

Re: [qmailtoaster] Re: SMTP issue

[Tonix - Antonio Nati]

Il 08/10/2014 15:04, Eric Broch ha scritto:

On 10/8/2014 1:26 AM, Tonix - Antonio Nati wrote:

Il 07/10/2014 21:31, Eric Broch ha scritto:

On 10/4/2014 12:25 AM, Tonix - Antonio Nati wrote:

Il 02/10/2014 20:11, Cecil Yother, Jr. ha scritto:


On 10/02/2014 10:19 AM, Tonix - Antonio Nati wrote:

Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:

Il 02/10/2014 18:52, Eric Broch ha scritto:

On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:

Il 02/10/2014 18:02, Eric Broch ha scritto:

On 10/2/2014 9:10 AM, Eric Broch wrote:

On 10/2/2014 8:30 AM, Bharath Chari wrote:

On 10/02/2014 04:59 PM, Eric Broch wrote:

On 10/2/2014 1:32 AM, Bharath Chari wrote:

On 09/25/2014 06:44 PM, Bharath Chari wrote:

On 09/25/2014 05:50 PM, Eric Broch wrote:

H. Is it always exactly one minute from begin to end? That would

appear to indicate some timer cutting out. It could be spamdyke
closing the session depending on your idle-timeout-secs= value. I'm
guessing 60, which is probably ok. I've upped mine to 180, and I
don't
recall exactly why I did that. Wouldn't hurt to bump it up I
suppose.

Still, the other end should have replied to your 220 message
before 58
seconds elapsed.

I wonder if there's a routing table misconfigured somewhere along
the
way. I've seen instances where an errant routing table entry can
cause
every nth packet to get dropped along the way. Are you seeing
reliable
pings over a period of a minute or so? If not, I'd suspect a network
issue.

At this point, I'd guess that QMT may be terminating a little soon,
and there's also a network problem somewhere along the way.

Again, just a guess.

P.S. Nice to see such accomplished people as Tonino and Bharath
helping out. Thanks guys!


No, it is not always one minute, sometimes it is up to thirty seconds
longer. I don't think spamdyke is closing the session as my
idle-timeout-secs is set to 480, and I don't recall either why I set
mine so high. While telnet(ing) to their host on port 25 initially
and
it is 'trying' to connect, I can open another terminal and run the
same
telnet command and I'll get their greeting right away.

I agree, their host should have replied faster than 58 seconds after
the
SMTP greeting, unless the greeting is never getting to there host.
There
host does not have ICMP protocol turned on. I could ask them to do
so.

If I have spamdyke set to terminate after 480 seconds what else
would be
terminating the connection?

And, ditto. Thanks for the help Tonino and Bharath!!!


Thanks hardly required. The problem still remains :(
OK, since you're having a problem even when doing a RAW telnet (the
initial connection), the MTA related issue can be ruled out for now.
However, it would be great if you could telnet from ANOTHER network
and see if the pattern remains the same (of the initial connection
being slow, and the next connection being fast).

Are you doing the telnet using IP or hostname? Let's rule out DNS
lookup related issues.

Bharath

@Eric Broch: Curious to know how this issue panned out. Did it resolve
itself?

Bharath

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com


Bharath,

And, also, it doesn't matter whether I use the hostname of the IP
Address same results.

I can telnet on port 25 to the problem host from [an]other location(s)
and it works just fine.



There you go. There's probably nothing you can do from your end - it's
most likely a firewall at their end. However, as a last ditch test,
can you also try to telnet to port 25 on their mail server from
ANOTHER machine on the same network as the QMT machine.

Wishing you the best :)

Bharath

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com


Thanks again, Bharath

I've done that too (from ANOTHER machine on the same network) with the
same results--delay or no connection at all.

Eric


-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com


Hi Bharath,

I just received an email from the problematic mx host's IT department.
They've done a test with SmtpDiag from their mx host and they cannot
connect to our mx host from their side either.

Eric

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com




Tonino,
I suppose all your network comes out using the same IP, or 
more IP which are mapped to same domain.
Yes. On our end we have a NAT(ed) firewall. We also have an 
MPLS circuit for certain private address ranges on the WAN

Re: [qmailtoaster] Re: SMTP issue

[Tonix - Antonio Nati]

Il 02/10/2014 20:11, Cecil Yother, Jr. ha scritto:


On 10/02/2014 10:19 AM, Tonix - Antonio Nati wrote:

Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:

Il 02/10/2014 18:52, Eric Broch ha scritto:

On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:

Il 02/10/2014 18:02, Eric Broch ha scritto:

On 10/2/2014 9:10 AM, Eric Broch wrote:

On 10/2/2014 8:30 AM, Bharath Chari wrote:

On 10/02/2014 04:59 PM, Eric Broch wrote:

On 10/2/2014 1:32 AM, Bharath Chari wrote:

On 09/25/2014 06:44 PM, Bharath Chari wrote:

On 09/25/2014 05:50 PM, Eric Broch wrote:

H. Is it always exactly one minute from begin to end? That would

appear to indicate some timer cutting out. It could be spamdyke
closing the session depending on your idle-timeout-secs= value. I'm
guessing 60, which is probably ok. I've upped mine to 180, and I
don't
recall exactly why I did that. Wouldn't hurt to bump it up I
suppose.

Still, the other end should have replied to your 220 message
before 58
seconds elapsed.

I wonder if there's a routing table misconfigured somewhere along
the
way. I've seen instances where an errant routing table entry can
cause
every nth packet to get dropped along the way. Are you seeing
reliable
pings over a period of a minute or so? If not, I'd suspect a network
issue.

At this point, I'd guess that QMT may be terminating a little soon,
and there's also a network problem somewhere along the way.

Again, just a guess.

P.S. Nice to see such accomplished people as Tonino and Bharath
helping out. Thanks guys!


No, it is not always one minute, sometimes it is up to thirty seconds
longer. I don't think spamdyke is closing the session as my
idle-timeout-secs is set to 480, and I don't recall either why I set
mine so high. While telnet(ing) to their host on port 25 initially
and
it is 'trying' to connect, I can open another terminal and run the
same
telnet command and I'll get their greeting right away.

I agree, their host should have replied faster than 58 seconds after
the
SMTP greeting, unless the greeting is never getting to there host.
There
host does not have ICMP protocol turned on. I could ask them to do
so.

If I have spamdyke set to terminate after 480 seconds what else
would be
terminating the connection?

And, ditto. Thanks for the help Tonino and Bharath!!!


Thanks hardly required. The problem still remains :(
OK, since you're having a problem even when doing a RAW telnet (the
initial connection), the MTA related issue can be ruled out for now.
However, it would be great if you could telnet from ANOTHER network
and see if the pattern remains the same (of the initial connection
being slow, and the next connection being fast).

Are you doing the telnet using IP or hostname? Let's rule out DNS
lookup related issues.

Bharath

@Eric Broch: Curious to know how this issue panned out. Did it resolve
itself?

Bharath

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com


Bharath,

And, also, it doesn't matter whether I use the hostname of the IP
Address same results.

I can telnet on port 25 to the problem host from [an]other location(s)
and it works just fine.



There you go. There's probably nothing you can do from your end - it's
most likely a firewall at their end. However, as a last ditch test,
can you also try to telnet to port 25 on their mail server from
ANOTHER machine on the same network as the QMT machine.

Wishing you the best :)

Bharath

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com


Thanks again, Bharath

I've done that too (from ANOTHER machine on the same network) with the
same results--delay or no connection at all.

Eric


-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com


Hi Bharath,

I just received an email from the problematic mx host's IT department.
They've done a test with SmtpDiag from their mx host and they cannot
connect to our mx host from their side either.

Eric

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com




Tonino,
I suppose all your network comes out using the same IP, or more IP 
which are mapped to same domain.
Yes. On our end we have a NAT(ed) firewall. We also have an MPLS 
circuit for certain private address ranges on the WAN interface.


Check if you have reverse IP issues...

Reverse DNS checks out Okay on both ends.


You have the IP address which is connecting to external exchange 
server.

That IP should match

Re: [qmailtoaster] Re: SMTP issue

[Tonix - Antonio Nati]

Il 02/10/2014 18:02, Eric Broch ha scritto:

On 10/2/2014 9:10 AM, Eric Broch wrote:

On 10/2/2014 8:30 AM, Bharath Chari wrote:

On 10/02/2014 04:59 PM, Eric Broch wrote:

On 10/2/2014 1:32 AM, Bharath Chari wrote:

On 09/25/2014 06:44 PM, Bharath Chari wrote:

On 09/25/2014 05:50 PM, Eric Broch wrote:

H. Is it always exactly one minute from begin to end? That would

appear to indicate some timer cutting out. It could be spamdyke
closing the session depending on your idle-timeout-secs= value. I'm
guessing 60, which is probably ok. I've upped mine to 180, and I
don't
recall exactly why I did that. Wouldn't hurt to bump it up I
suppose.

Still, the other end should have replied to your 220 message
before 58
seconds elapsed.

I wonder if there's a routing table misconfigured somewhere along
the
way. I've seen instances where an errant routing table entry can
cause
every nth packet to get dropped along the way. Are you seeing
reliable
pings over a period of a minute or so? If not, I'd suspect a network
issue.

At this point, I'd guess that QMT may be terminating a little soon,
and there's also a network problem somewhere along the way.

Again, just a guess.

P.S. Nice to see such accomplished people as Tonino and Bharath
helping out. Thanks guys!


No, it is not always one minute, sometimes it is up to thirty seconds
longer. I don't think spamdyke is closing the session as my
idle-timeout-secs is set to 480, and I don't recall either why I set
mine so high. While telnet(ing) to their host on port 25 initially
and
it is 'trying' to connect, I can open another terminal and run the
same
telnet command and I'll get their greeting right away.

I agree, their host should have replied faster than 58 seconds after
the
SMTP greeting, unless the greeting is never getting to there host.
There
host does not have ICMP protocol turned on. I could ask them to do
so.

If I have spamdyke set to terminate after 480 seconds what else
would be
terminating the connection?

And, ditto. Thanks for the help Tonino and Bharath!!!


Thanks hardly required. The problem still remains :(
OK, since you're having a problem even when doing a RAW telnet (the
initial connection), the MTA related issue can be ruled out for now.
However, it would be great if you could telnet from ANOTHER network
and see if the pattern remains the same (of the initial connection
being slow, and the next connection being fast).

Are you doing the telnet using IP or hostname? Let's rule out DNS
lookup related issues.

Bharath

@Eric Broch: Curious to know how this issue panned out. Did it resolve
itself?

Bharath

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com


Bharath,

And, also, it doesn't matter whether I use the hostname of the IP
Address same results.

I can telnet on port 25 to the problem host from [an]other location(s)
and it works just fine.



There you go. There's probably nothing you can do from your end - it's
most likely a firewall at their end. However, as a last ditch test,
can you also try to telnet to port 25 on their mail server from
ANOTHER machine on the same network as the QMT machine.

Wishing you the best :)

Bharath

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com


Thanks again, Bharath

I've done that too (from ANOTHER machine on the same network) with the
same results--delay or no connection at all.

Eric


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com


Hi Bharath,

I just received an email from the problematic mx host's IT department.
They've done a test with SmtpDiag from their mx host and they cannot
connect to our mx host from their side either.

Eric

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



I suppose all your network comes out using the same IP, or more IP which 
are mapped to same domain.


Check if you have reverse IP issues...

You have the IP address which is connecting to external exchange server.
That IP should match the IP of the name declared in HELO (o EHLO).

Check also if name associated with that IP corresponds to HELO name 
(some servers are making paranoic controls).


Tonino




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: SMTP issue

[Tonix - Antonio Nati]

Il 02/10/2014 18:52, Eric Broch ha scritto:

On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:

Il 02/10/2014 18:02, Eric Broch ha scritto:

On 10/2/2014 9:10 AM, Eric Broch wrote:

On 10/2/2014 8:30 AM, Bharath Chari wrote:

On 10/02/2014 04:59 PM, Eric Broch wrote:

On 10/2/2014 1:32 AM, Bharath Chari wrote:

On 09/25/2014 06:44 PM, Bharath Chari wrote:

On 09/25/2014 05:50 PM, Eric Broch wrote:

H. Is it always exactly one minute from begin to end? That would

appear to indicate some timer cutting out. It could be spamdyke
closing the session depending on your idle-timeout-secs= value. I'm
guessing 60, which is probably ok. I've upped mine to 180, and I
don't
recall exactly why I did that. Wouldn't hurt to bump it up I
suppose.

Still, the other end should have replied to your 220 message
before 58
seconds elapsed.

I wonder if there's a routing table misconfigured somewhere along
the
way. I've seen instances where an errant routing table entry can
cause
every nth packet to get dropped along the way. Are you seeing
reliable
pings over a period of a minute or so? If not, I'd suspect a network
issue.

At this point, I'd guess that QMT may be terminating a little soon,
and there's also a network problem somewhere along the way.

Again, just a guess.

P.S. Nice to see such accomplished people as Tonino and Bharath
helping out. Thanks guys!


No, it is not always one minute, sometimes it is up to thirty seconds
longer. I don't think spamdyke is closing the session as my
idle-timeout-secs is set to 480, and I don't recall either why I set
mine so high. While telnet(ing) to their host on port 25 initially
and
it is 'trying' to connect, I can open another terminal and run the
same
telnet command and I'll get their greeting right away.

I agree, their host should have replied faster than 58 seconds after
the
SMTP greeting, unless the greeting is never getting to there host.
There
host does not have ICMP protocol turned on. I could ask them to do
so.

If I have spamdyke set to terminate after 480 seconds what else
would be
terminating the connection?

And, ditto. Thanks for the help Tonino and Bharath!!!


Thanks hardly required. The problem still remains :(
OK, since you're having a problem even when doing a RAW telnet (the
initial connection), the MTA related issue can be ruled out for now.
However, it would be great if you could telnet from ANOTHER network
and see if the pattern remains the same (of the initial connection
being slow, and the next connection being fast).

Are you doing the telnet using IP or hostname? Let's rule out DNS
lookup related issues.

Bharath

@Eric Broch: Curious to know how this issue panned out. Did it resolve
itself?

Bharath

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com


Bharath,

And, also, it doesn't matter whether I use the hostname of the IP
Address same results.

I can telnet on port 25 to the problem host from [an]other location(s)
and it works just fine.



There you go. There's probably nothing you can do from your end - it's
most likely a firewall at their end. However, as a last ditch test,
can you also try to telnet to port 25 on their mail server from
ANOTHER machine on the same network as the QMT machine.

Wishing you the best :)

Bharath

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com


Thanks again, Bharath

I've done that too (from ANOTHER machine on the same network) with the
same results--delay or no connection at all.

Eric


-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com


Hi Bharath,

I just received an email from the problematic mx host's IT department.
They've done a test with SmtpDiag from their mx host and they cannot
connect to our mx host from their side either.

Eric

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com




Tonino,
I suppose all your network comes out using the same IP, or more IP 
which are mapped to same domain.
Yes. On our end we have a NAT(ed) firewall. We also have an MPLS 
circuit for certain private address ranges on the WAN interface.


Check if you have reverse IP issues...

Reverse DNS checks out Okay on both ends.


You have the IP address which is connecting to external exchange server.
That IP should match the IP of the name declared in HELO (o EHLO).
There seems to be a Sonicwall email security appliance on their end 
between our hosts--which, I think, may be the problem

Re: [qmailtoaster] Re: SMTP issue

[Tonix - Antonio Nati]

Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:

Il 02/10/2014 18:52, Eric Broch ha scritto:

On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:

Il 02/10/2014 18:02, Eric Broch ha scritto:

On 10/2/2014 9:10 AM, Eric Broch wrote:

On 10/2/2014 8:30 AM, Bharath Chari wrote:

On 10/02/2014 04:59 PM, Eric Broch wrote:

On 10/2/2014 1:32 AM, Bharath Chari wrote:

On 09/25/2014 06:44 PM, Bharath Chari wrote:

On 09/25/2014 05:50 PM, Eric Broch wrote:

H. Is it always exactly one minute from begin to end? That would

appear to indicate some timer cutting out. It could be spamdyke
closing the session depending on your idle-timeout-secs= value. I'm
guessing 60, which is probably ok. I've upped mine to 180, and I
don't
recall exactly why I did that. Wouldn't hurt to bump it up I
suppose.

Still, the other end should have replied to your 220 message
before 58
seconds elapsed.

I wonder if there's a routing table misconfigured somewhere along
the
way. I've seen instances where an errant routing table entry can
cause
every nth packet to get dropped along the way. Are you seeing
reliable
pings over a period of a minute or so? If not, I'd suspect a network
issue.

At this point, I'd guess that QMT may be terminating a little soon,
and there's also a network problem somewhere along the way.

Again, just a guess.

P.S. Nice to see such accomplished people as Tonino and Bharath
helping out. Thanks guys!


No, it is not always one minute, sometimes it is up to thirty seconds
longer. I don't think spamdyke is closing the session as my
idle-timeout-secs is set to 480, and I don't recall either why I set
mine so high. While telnet(ing) to their host on port 25 initially
and
it is 'trying' to connect, I can open another terminal and run the
same
telnet command and I'll get their greeting right away.

I agree, their host should have replied faster than 58 seconds after
the
SMTP greeting, unless the greeting is never getting to there host.
There
host does not have ICMP protocol turned on. I could ask them to do
so.

If I have spamdyke set to terminate after 480 seconds what else
would be
terminating the connection?

And, ditto. Thanks for the help Tonino and Bharath!!!


Thanks hardly required. The problem still remains :(
OK, since you're having a problem even when doing a RAW telnet (the
initial connection), the MTA related issue can be ruled out for now.
However, it would be great if you could telnet from ANOTHER network
and see if the pattern remains the same (of the initial connection
being slow, and the next connection being fast).

Are you doing the telnet using IP or hostname? Let's rule out DNS
lookup related issues.

Bharath

@Eric Broch: Curious to know how this issue panned out. Did it resolve
itself?

Bharath

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com


Bharath,

And, also, it doesn't matter whether I use the hostname of the IP
Address same results.

I can telnet on port 25 to the problem host from [an]other location(s)
and it works just fine.



There you go. There's probably nothing you can do from your end - it's
most likely a firewall at their end. However, as a last ditch test,
can you also try to telnet to port 25 on their mail server from
ANOTHER machine on the same network as the QMT machine.

Wishing you the best :)

Bharath

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com


Thanks again, Bharath

I've done that too (from ANOTHER machine on the same network) with the
same results--delay or no connection at all.

Eric


-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com


Hi Bharath,

I just received an email from the problematic mx host's IT department.
They've done a test with SmtpDiag from their mx host and they cannot
connect to our mx host from their side either.

Eric

-
To unsubscribe, e-mail:qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:qmailtoaster-list-h...@qmailtoaster.com




Tonino,
I suppose all your network comes out using the same IP, or more IP 
which are mapped to same domain.
Yes. On our end we have a NAT(ed) firewall. We also have an MPLS 
circuit for certain private address ranges on the WAN interface.


Check if you have reverse IP issues...

Reverse DNS checks out Okay on both ends.


You have the IP address which is connecting to external exchange server.
That IP should match the IP of the name declared in HELO (o EHLO).
There seems to be a Sonicwall email security appliance on their end

Re: [qmailtoaster] Re: SMTP issue

[Tonix - Antonio Nati]

Il 25/09/2014 16:50, Eric Broch ha scritto:

On 9/24/2014 9:35 AM, Eric Shubert wrote:

On 09/24/2014 07:27 AM, Eric Broch wrote:

On 9/24/2014 8:08 AM, Tonix - Antonio Nati wrote:

Il 24/09/2014 15:01, Eric Broch ha scritto:

On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:

Il 23/09/2014 18:28, Eric Broch ha scritto:

On 9/22/2014 5:39 PM, Eric Broch wrote:

On 9/22/2014 4:43 PM, Eric Shubert wrote:

Nice info, Tonino. I know that SPF failures used to do that too,
but I
think we have a log message for that now.

Sounds to me like TLS may be failing. I'd turn on spamdyke's
detailed
logging. It'll show you the details of what's going on.


Thanks! I'll increase spamdyke log-level.

-

To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com


Hello list,

I implemented the log-level setting in spamdyke to 'excessive'
and the
log results are below:

@40005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
@40005421856d2ffa8244 tcpserver: ok 15364
mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
@40005421856d3029c004 spamdyke[15364]:
DEBUG(filter_rdns_missing()@filter.c:986): checking for missing
rDNS;
rdns: theirmail.theirdomain.com
@40005421856d302a21ac spamdyke[15364]:
DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
whitelist file(s); rdns: theirmail.theirdomain.com
@40005421856d302a9ac4 spamdyke[15364]:
DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
blacklist file(s); rdns: theirmail.theirdomain.com
@40005421856d302b0c0c spamdyke[15364]:
DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
file(s); ip: xxx.xxx.xxx.xxx
@40005421856d302bcb74 spamdyke[15364]:
DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
file(s); ip: xxx.xxx.xxx.xxx
@40005421856d302c9e64 spamdyke[15364]:
DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for
IP in
rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
theirmail.theirdomain.com
@40005421856d302d271c spamdyke[15364]:
DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for
IP in
rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
theirmail.theirdomain.com
@40005421856d302d5214 spamdyke[15364]:
DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
theirmail.theirdomain.com
@40005421856d33e291e4 spamdyke[15364]:
DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
delay: 1
@4000542185a9306b495c tcpserver: end 15364 status 0

The connection seems to stop after the 'earlytalker' filter, but
I'm not
sure this would be the cause. Any ideas?

Eric


Eric,

who is sending: a remote server, or a remote client?

Tonino



-

To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com


Hi Tonino,

I think I understand your question. The sender is an MS Exchange
server.

And, I don't think I've stated this  before, but we're having trouble
both sending and receiving email. When they send email from their
Exchange server it connects to our QMT host and disconnects right away
without delivering the mail only to be delivered some time later from
hours to up to a day and a half. And, this is true when we send
email to
them from our QMT host to their Exchange server. It makes me believe
something is going on in-between the two hosts. One email sat in
the QMT
queue for hours.

In testing, when I telnet to their Exchange server on port 25 there
is a
very long delay--up to 75 seconds, which indicates to me that
something
is wrong on their end or something is blocking the connection. Using
Wireshark to examine this test, our QMT host sends 5 SYN packets (when
there should only be one) and then is responded to with a SYN, ACK
packet by their Exchange server after the 5th; then our QMT host sends
an RST packet. During this delay if I open up another terminal and
telnet to their Exchange server on port 25, I receive their SMTP
greeting immediately. Upon subsequent telnet(s) on port 25 it always
connects. If I wait 5 minutes or more in between telnet(ing) on
port 25
their is a long delay, again.

I hope all of this makes sense to you. It is quite disconcerting to be
able to send and receive email from or to anywhere except one host.
Their IT staff claims the same thing, that is, that our QMT host is
the
only host they are having trouble with in send/receiving email.

I'm going to set up spamdyke as EricS has recommended and see what
happens.

Just thinking loudly...

1) It looks like they could have DNS problems. If first connection is
slow, and second is quick, it looks like a dns query slow in first
attempo, but already in cache in the second... and then again slow on
third attempot after a few

Re: [qmailtoaster] Re: SMTP issue

[Tonix - Antonio Nati]

Il 23/09/2014 18:28, Eric Broch ha scritto:

On 9/22/2014 5:39 PM, Eric Broch wrote:

On 9/22/2014 4:43 PM, Eric Shubert wrote:

Nice info, Tonino. I know that SPF failures used to do that too, but I
think we have a log message for that now.

Sounds to me like TLS may be failing. I'd turn on spamdyke's detailed
logging. It'll show you the details of what's going on.


Thanks! I'll increase spamdyke log-level.

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com


Hello list,

I implemented the log-level setting in spamdyke to 'excessive' and the
log results are below:

@40005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
@40005421856d2ffa8244 tcpserver: ok 15364
mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
@40005421856d3029c004 spamdyke[15364]:
DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
rdns: theirmail.theirdomain.com
@40005421856d302a21ac spamdyke[15364]:
DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
whitelist file(s); rdns: theirmail.theirdomain.com
@40005421856d302a9ac4 spamdyke[15364]:
DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
blacklist file(s); rdns: theirmail.theirdomain.com
@40005421856d302b0c0c spamdyke[15364]:
DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
file(s); ip: xxx.xxx.xxx.xxx
@40005421856d302bcb74 spamdyke[15364]:
DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
file(s); ip: xxx.xxx.xxx.xxx
@40005421856d302c9e64 spamdyke[15364]:
DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
theirmail.theirdomain.com
@40005421856d302d271c spamdyke[15364]:
DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
theirmail.theirdomain.com
@40005421856d302d5214 spamdyke[15364]:
DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
theirmail.theirdomain.com
@40005421856d33e291e4 spamdyke[15364]:
DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
delay: 1
@4000542185a9306b495c tcpserver: end 15364 status 0

The connection seems to stop after the 'earlytalker' filter, but I'm not
sure this would be the cause. Any ideas?

Eric



Eric,

who is sending: a remote server, or a remote client?

Tonino




-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: SMTP issue

[Tonix - Antonio Nati]

Il 24/09/2014 15:01, Eric Broch ha scritto:

On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:

Il 23/09/2014 18:28, Eric Broch ha scritto:

On 9/22/2014 5:39 PM, Eric Broch wrote:

On 9/22/2014 4:43 PM, Eric Shubert wrote:

Nice info, Tonino. I know that SPF failures used to do that too, but I
think we have a log message for that now.

Sounds to me like TLS may be failing. I'd turn on spamdyke's detailed
logging. It'll show you the details of what's going on.


Thanks! I'll increase spamdyke log-level.

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com


Hello list,

I implemented the log-level setting in spamdyke to 'excessive' and the
log results are below:

@40005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
@40005421856d2ffa8244 tcpserver: ok 15364
mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
@40005421856d3029c004 spamdyke[15364]:
DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
rdns: theirmail.theirdomain.com
@40005421856d302a21ac spamdyke[15364]:
DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
whitelist file(s); rdns: theirmail.theirdomain.com
@40005421856d302a9ac4 spamdyke[15364]:
DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
blacklist file(s); rdns: theirmail.theirdomain.com
@40005421856d302b0c0c spamdyke[15364]:
DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
file(s); ip: xxx.xxx.xxx.xxx
@40005421856d302bcb74 spamdyke[15364]:
DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
file(s); ip: xxx.xxx.xxx.xxx
@40005421856d302c9e64 spamdyke[15364]:
DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
theirmail.theirdomain.com
@40005421856d302d271c spamdyke[15364]:
DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
theirmail.theirdomain.com
@40005421856d302d5214 spamdyke[15364]:
DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
theirmail.theirdomain.com
@40005421856d33e291e4 spamdyke[15364]:
DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
delay: 1
@4000542185a9306b495c tcpserver: end 15364 status 0

The connection seems to stop after the 'earlytalker' filter, but I'm not
sure this would be the cause. Any ideas?

Eric


Eric,

who is sending: a remote server, or a remote client?

Tonino



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com




Hi Tonino,

I think I understand your question. The sender is an MS Exchange server.

And, I don't think I've stated this  before, but we're having trouble
both sending and receiving email. When they send email from their
Exchange server it connects to our QMT host and disconnects right away
without delivering the mail only to be delivered some time later from
hours to up to a day and a half. And, this is true when we send email to
them from our QMT host to their Exchange server. It makes me believe
something is going on in-between the two hosts. One email sat in the QMT
queue for hours.

In testing, when I telnet to their Exchange server on port 25 there is a
very long delay--up to 75 seconds, which indicates to me that something
is wrong on their end or something is blocking the connection. Using
Wireshark to examine this test, our QMT host sends 5 SYN packets (when
there should only be one) and then is responded to with a SYN, ACK
packet by their Exchange server after the 5th; then our QMT host sends
an RST packet. During this delay if I open up another terminal and
telnet to their Exchange server on port 25, I receive their SMTP
greeting immediately. Upon subsequent telnet(s) on port 25 it always
connects. If I wait 5 minutes or more in between telnet(ing) on port 25
their is a long delay, again.

I hope all of this makes sense to you. It is quite disconcerting to be
able to send and receive email from or to anywhere except one host.
Their IT staff claims the same thing, that is, that our QMT host is the
only host they are having trouble with in send/receiving email.

I'm going to set up spamdyke as EricS has recommended and see what happens.


Just thinking loudly...

1) It looks like they could have DNS problems. If first connection is 
slow, and second is quick, it looks like a dns query slow in first 
attempo, but already in cache in the second... and then again slow on 
third attempot after a few minutes because cache life is too short.

2) Check on exhange server
http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
3) if they have firewall, check command

Re: [qmailtoaster] Re: SMTP issue

[Tonix - Antonio Nati]

Il 24/09/2014 16:08, Tonix - Antonio Nati ha scritto:

Il 24/09/2014 15:01, Eric Broch ha scritto:

On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:

Il 23/09/2014 18:28, Eric Broch ha scritto:

On 9/22/2014 5:39 PM, Eric Broch wrote:

On 9/22/2014 4:43 PM, Eric Shubert wrote:
Nice info, Tonino. I know that SPF failures used to do that too, 
but I

think we have a log message for that now.

Sounds to me like TLS may be failing. I'd turn on spamdyke's 
detailed

logging. It'll show you the details of what's going on.


Thanks! I'll increase spamdyke log-level.

-
To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com


Hello list,

I implemented the log-level setting in spamdyke to 'excessive' and the
log results are below:

@40005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
@40005421856d2ffa8244 tcpserver: ok 15364
mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
@40005421856d3029c004 spamdyke[15364]:
DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
rdns: theirmail.theirdomain.com
@40005421856d302a21ac spamdyke[15364]:
DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
whitelist file(s); rdns: theirmail.theirdomain.com
@40005421856d302a9ac4 spamdyke[15364]:
DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
blacklist file(s); rdns: theirmail.theirdomain.com
@40005421856d302b0c0c spamdyke[15364]:
DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
file(s); ip: xxx.xxx.xxx.xxx
@40005421856d302bcb74 spamdyke[15364]:
DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
file(s); ip: xxx.xxx.xxx.xxx
@40005421856d302c9e64 spamdyke[15364]:
DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
theirmail.theirdomain.com
@40005421856d302d271c spamdyke[15364]:
DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
theirmail.theirdomain.com
@40005421856d302d5214 spamdyke[15364]:
DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
theirmail.theirdomain.com
@40005421856d33e291e4 spamdyke[15364]:
DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
delay: 1
@4000542185a9306b495c tcpserver: end 15364 status 0

The connection seems to stop after the 'earlytalker' filter, but 
I'm not

sure this would be the cause. Any ideas?

Eric


Eric,

who is sending: a remote server, or a remote client?

Tonino



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com





Hi Tonino,

I think I understand your question. The sender is an MS Exchange server.

And, I don't think I've stated this  before, but we're having trouble
both sending and receiving email. When they send email from their
Exchange server it connects to our QMT host and disconnects right away
without delivering the mail only to be delivered some time later from
hours to up to a day and a half. And, this is true when we send email to
them from our QMT host to their Exchange server. It makes me believe
something is going on in-between the two hosts. One email sat in the QMT
queue for hours.

In testing, when I telnet to their Exchange server on port 25 there is a
very long delay--up to 75 seconds, which indicates to me that something
is wrong on their end or something is blocking the connection. Using
Wireshark to examine this test, our QMT host sends 5 SYN packets (when
there should only be one) and then is responded to with a SYN, ACK
packet by their Exchange server after the 5th; then our QMT host sends
an RST packet. During this delay if I open up another terminal and
telnet to their Exchange server on port 25, I receive their SMTP
greeting immediately. Upon subsequent telnet(s) on port 25 it always
connects. If I wait 5 minutes or more in between telnet(ing) on port 25
their is a long delay, again.

I hope all of this makes sense to you. It is quite disconcerting to be
able to send and receive email from or to anywhere except one host.
Their IT staff claims the same thing, that is, that our QMT host is the
only host they are having trouble with in send/receiving email.

I'm going to set up spamdyke as EricS has recommended and see what 
happens.


Just thinking loudly...


Just to avoid confusion, all problems here listed are referred to 
exchange server side, not your side :-)




1) It looks like they could have DNS problems. If first connection is 
slow, and second is quick, it looks like a dns query slow in first 
attempo, but already in cache in the second... and then again slow on 
third attempot after a few

Re: [qmailtoaster] SMTP issue

[Tonix - Antonio Nati]

One event which is not logged is exceeded size of incoming message.

You see all initial logs, and then nothing more, like disappeared.

Regards,

Tonino



Il 22/09/2014 21:38, Eric Broch ha scritto:

Hello list,

I'm having and issue and am not sure of the source of the problem.

My client's QMT accepts email from all of their clients; however, there
is one client from which I know we are receiving a connection, per
Wireshark, but the mail is not being transferred. There is a record of
the connection in the SMTP server log, but again, there is no mail
transferred.

Does anyone have any ideas why the connection would be 'stopped' or
'dropped' or whatever?

Eric


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] CHKUSER_WRONGRCPTLIMIT

[Tonix - Antonio Nati]

If your desktop client is taliking directly with the SMTP server with 
chkuser enabled, is it high probable the problem is in the desktop client.


SMTP server with chkuser enabled should only taks with servers, because 
servers handle negative answer on one recipient, while desktop clients 
do not and stop on first negative answer.


Ciao,

Tonino

Il 29/08/2014 11:17, Michele Federici ha scritto:

Hi,

I need to enable a remote service (with a specific ip) to use my smtp 
server to send email to high number ( 300) of email account 
(internal/external).


I try with openrelay... all work fine but I've a big problem. If only 
one local email account is wrong then check user stop to send ALL emails.


So i tried to add CHKUSER_WRONGRCPTLIMIT like
xx.xx.xx.xx:allow,RELAYCLIENT=,RBLSMTPD=,SENDER_NOCHECK=1,CHKUSER_RCPTLIMIT=500,CHKUSER_WRONGRCPTLIMIT=30
but check user stop email like CHKUSER_WRONGRCPTLIMIT=1

The strange thing is that: CHKUSER_RCPTLIMIT work fine but 
CHKUSER_WRONGRCPTLIMIT not.


I also tried to replace RELAY and with authenticated sender but 
doesn't work.


Where am I wrong?


--
Michele
- 
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com 
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com 



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] CHKUSER_WRONGRCPTLIMIT

[Tonix - Antonio Nati]

I don't know if the variable you need is enabled in your 
distribution/version.


Actually you could put in place this solution:

   Enable (uncomment) the following define in checkuser_settings.h and
   recompile.

#define CHKUSER_DISABLE_VARIABLE RELAYCLIENT

   With such option, chkuser is disabled for every aythenticated or
   authorized sender which has RELAYCLIENT set (we reccomend this option).

As alternative if you want to disable chkuser from a specific IP:

   Enable (uncomment) the following define in checkuser_settings.h and
   recompile.

#define CHKUSER_DISABLE_VARIABLE DISABLE_CHECKUSER

   and put in your control file:

   xx.xx.xx.xx:allow,DISABLE_CHECKUSER=,RBLSMTPD=


Actually, all controls related to too many wrong or existing recipients, 
as well as not existin domains or other like that should be set only for 
public MX frontends, not for SMTP relays serving only authenticated users.


Ciao,

Tonino



Il 29/08/2014 15:25, Michele Federici ha scritto:
I understand so I want my qmailtoaster server will be a SMTP 
server which accept every recipient. But not for all ip but only for 
certain ip (xx.xx.xx.xx) to do this i think i need to have a open 
relay for xx.xx.xx.xx.


So... what i need to do to be SMTP server which accept every recipient?

I tried to disable checkuser replace
xx.xx.xx.xx:allow,RELAYCLIENT=,RBLSMTPD=,SENDER_NOCHECK=1,CHKUSER_RCPTLIMIT=500,CHKUSER_WRONGRCPTLIMIT=30
with
xx.xx.xx.xx:allow,RELAYCLIENT=,RBLSMTPD=,NOP0FCHECK=1,SENDER_NOCHECK=1

but doesn't work... checkuser still block incorrect email account

Maybe i've an old release? How i can check?

Ciao
--
Michele
Il 29/08/2014 12:40, Tonix - Antonio Nati ha scritto:
In this case your web application is like a desktop client. It's a 
client, trying to speak server language, but it it not able (common 
to all clients).


This has already been answered several times.

When a receiving SMTP server answers 'NEGATIVE' to an email sending 
server, the email sending server continues his job of sending, and 
takes note of the negative answer for the not existing recipient.


Instead a desktop client or a web application just stop at the first 
negative answer.


So, solution are: client desktops or web applications must send to 
SMTP server which accept every recipient, or must send messages for 
each recipient separately.


Ciao,

Tonino




Il 29/08/2014 12:31, Michele Federici ha scritto:
My remote service is not a desktop client but is a web 
application who send 1 email with N email account in BCC by 
qmailtoaster server.
If in bcc there is only one wrong address... the send will fail.  I 
want increase CHKUSER_WRONGRCPTLIMIT but seem it's ignored.

If is not possible, the solutions are
- web application loop to send 1 email to 1 email account and  
intercept single errors... (but send procedure will be more slowly 
with attachment).
- web application sent email to local *MTA * agent who will send 
email to my smtp server or to other external server


Ciao
--
Michele
Il 29/08/2014 11:21, Tonix - Antonio Nati ha scritto:
If your desktop client is taliking directly with the SMTP server 
with chkuser enabled, is it high probable the problem is in the 
desktop client.


SMTP server with chkuser enabled should only taks with servers, 
because servers handle negative answer on one recipient, while 
desktop clients do not and stop on first negative answer.


Ciao,

Tonino

Il 29/08/2014 11:17, Michele Federici ha scritto:

Hi,

I need to enable a remote service (with a specific ip) to use my 
smtp server to send email to high number ( 300) of email account 
(internal/external).


I try with openrelay... all work fine but I've a big problem. If 
only one local email account is wrong then check user stop to send 
ALL emails.


So i tried to add CHKUSER_WRONGRCPTLIMIT like
xx.xx.xx.xx:allow,RELAYCLIENT=,RBLSMTPD=,SENDER_NOCHECK=1,CHKUSER_RCPTLIMIT=500,CHKUSER_WRONGRCPTLIMIT=30
but check user stop email like CHKUSER_WRONGRCPTLIMIT=1

The strange thing is that: CHKUSER_RCPTLIMIT work fine but 
CHKUSER_WRONGRCPTLIMIT not.


I also tried to replace RELAY and with authenticated sender but 
doesn't work.


Where am I wrong?


--
Michele
- 
To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com For additional 
commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com 



--

 Inter@zioniInterazioni di Antonio Nati
http://www.interazioni.it   to...@interazioni.it



- To 
unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com 
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com 



--

 Inter@zioni

Re: [qmailtoaster] Re: CHKUSER_WRONGRCPTLIMIT

[Tonix - Antonio Nati]

Il 29/08/2014 16:58, Eric Shubert ha scritto:

On 08/29/2014 07:12 AM, Tonix - Antonio Nati wrote:

I don't know if the variable you need is enabled in your
distribution/version.

Actually you could put in place this solution:

Enable (uncomment) the following define in checkuser_settings.h and
recompile.

 #define CHKUSER_DISABLE_VARIABLE RELAYCLIENT

With such option, chkuser is disabled for every aythenticated or
authorized sender which has RELAYCLIENT set (we reccomend this 
option).


Unfortunately, I've missed this recommendation up to now, and this 
variable is not set. I'll see about getting this included in the next 
release of the qmail package.


I'm not sure all have the same needs, and it's a compiling option, so it 
could not be easy to make a solution for alls.


Actually we suggest to enable it on port 587 and on separate servers 
which act only as SMTP gateway.


Thinking better, there could be no reason not to use it on port 25 on 
public MX, percent of people using it instead of dedicated servers would 
be very small.


Actually, here in Italy, there is a good reason to push customers to use 
port 587: some important mobile network do no permit access to port 25 
on external network, so we suggest our customers to use port 587 also on 
our dedicated gateways.


So, dedicated SMTP gateways have this option on port 25, 465, 587.



Michele, are you running legacy (*-toaster) packages, or the new ones?


As alternative if you want to disable chkuser from a specific IP:

Enable (uncomment) the following define in checkuser_settings.h and
recompile.

 #define CHKUSER_DISABLE_VARIABLE DISABLE_CHECKUSER

and put in your control file:

xx.xx.xx.xx:allow,DISABLE_CHECKUSER=,RBLSMTPD=


Actually, all controls related to too many wrong or existing recipients,
as well as not existin domains or other like that should be set only for
public MX frontends, not for SMTP relays serving only authenticated 
users.




This brings up an interesting point. It'll be easy enough to disable 
these controls on port 587. Is there a way though that chkuser can 
tell if authentication has taken place or not on port 25?


chkuser uses RELAYCLIENT to check if sender is authorized to relay, 
despite of port.


There is another option which will refuse any message if sender is not 
authenticated (RELAYCLIENT not set):


CHKUSER_EXTRA_MUSTAUTH_VARIABLE

So I enable and set this option on port 587 and on servers which only 
play as SMTP gateway, and it will only accept messages from authorized 
senders.

*
*


Also, can you list the specific controls that you feel should be 
disabled for authenticated sessions?


Actually, I suggest disabling whole chkuser for each authenticated session.
Only in this way desktop clients may manage complex errors, and send 
anyway messages, receiving back from SMTP server detailed negative 
answers for singles failures.


In case of public MX frontend, instead, I'd esclude all formal controls, 
keeping on tarpitting, dns  MX checking on senders (on rcpt DNS and MX 
controls could be useless, as the right domain should always exist in 
rcptcontrol), and full recipients checking of course.



Cheers!

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: Bounced mail checking!

[Tonix - Antonio Nati]

Il 18/06/2014 19:43, Eric Shubert ha scritto:

On 06/09/2014 05:05 AM, Tonix - Antonio Nati wrote:

Il 09/06/2014 13:57, Tony White ha scritto:

Hi folks,
  Sorry but is there any way I can easily check to see if an email
was received and bounced?
  A client is telling me that someone sent them an email and it
bounced because the attachment was too large.
  I cannot see any in the log files but then again I have not had
to do this before. Maybe there is a trick or script to use!



Currently this is a qmail bug: qmail-smtpd does not write in log if
message is bounced because of size limit.

Regards,

Tonino


TIA






Hmmm. I should see about fixing that.

Tony, are you using spamdyke? If so, you should see a DENIED_OTHER 
message corresponding to the rejection.



Sorry, Eric, I don't use spamdyke.

qmail-smtpd send back a correct answer at smtp level, only forgets to 
log the error for local checking.


Fixing that in qmail-smtpd should bery very easy, just adding a log line.

Regards,

Tonino



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Bounced mail checking!

[Tonix - Antonio Nati]

Il 09/06/2014 13:57, Tony White ha scritto:

Hi folks,
  Sorry but is there any way I can easily check to see if an email
was received and bounced?
  A client is telling me that someone sent them an email and it
bounced because the attachment was too large.
  I cannot see any in the log files but then again I have not had
to do this before. Maybe there is a trick or script to use!



Currently this is a qmail bug: qmail-smtpd does not write in log if 
message is bounced because of size limit.


Regards,

Tonino


TIA




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: to catch all or no

[Tonix - Antonio Nati]

, 
and 5.x.x messages for solid rejects. Also, the x and x values are 
supposed to tell you the detailed REASON for the reject. Far too many 
ESPs use generic failure reject messages, or will reject a message 
with a 4.x.x result, or delay a message with a 5.x.x result... all in 
error.


Someone which doe not respect the guidelines is going to give problems 
to others. That does not means guidelines cannot be changed, but there 
should be a managed process for that. Guidelines may evolve in time.


I know quite well all what you say before, and that does not change my 
opinion about the added quality of service of electronic emails compared 
to paper mails.


People must use emails in the most simple way, and our job is to 
semplify their life.
Something can be complicated for us, but the goal is not semplify our 
job, the goal is to give a better service.




FINALLY: I'm not against users(senders) getting information back, but 
I'm also not about to _/facilitate /_/_abusers_ /in deceiving my 
clients/users either. The BOUNCE mechanism isn't solely about address 
phishing -- it is also abused by SPAMMERS who forge reply-to addresses 
so that the payload SPAM is delivered as a BOUNCE message from a 
legitimate server, even though the original source is illegitimate.


I adhere to some basic principles:
 - properly addressed messages are ALWAYS delivered (even if SA gives 
it a 100 score!).
 - the only exceptions are when the sender's domain provides a 
mechanism to validate the source  tells me to reject messages that 
don't meet that validation. (This is what SPF, DomainKeys, DKIM, etc. 
all try to do).


In that vein, I provide properly formatted and detailed REJECT 
messages (so that a user might know why I rejected him as a sender), 
but I do NOT provide BOUNCE messages.

The difference?
 - a REJECT is a reply back to the original *sender's server*. I can 
be reasonably certain I'm talking to the real server, as we're 
expecting to trade TCP messages back and forth
 - a bounce is a new message sent back to the person purporting to be 
the sender. I have NO FAITH in the sender's self-reported address, so 
I refuse to use it in ANY automated fashion - including, and 
especially, bounce messages.




REJECT is the reasonable way to stop unwanted emails. Bounces are a 
terrible solutions, but at the time Berstein wrote qmail there were no 
SPAM problems (but I feel he wanted to ignore this problem, because this 
could be a complication to his security model).



Again, all that is very clear, but I see a key point missing: who is the 
owner od emails? Me or my customers?
Before I take a decision about implementing a filtering /rejecting rule, 
I always ask if it is a necessary action, or if I'm going to damage the 
right to receive emails.


I have the feeling you make the same, so I don't see problems.


===
These are just my thoughts -- but after being an ESP (Email Service 
Provider) for more than 15 years now, I'm pretty strong in my 
opinions! Not that they haven't changed... they have! I used to have a 
single catchall account for ALL of my domains, and I used to have a 
paid staffer whose job was to cull through those emails to see if any 
could be forwarded to their legitimate recipients. What a naive little 
nave I was back then! :^)


I don't represent that I'm right  you're wrong -- I am only 
describing what I do, and attempting to explain why... I'm a firm 
believer in the free market (of ideas AND of money), and firmly 
believe that the Internet would have FAILED if people hadn't bent, 
poked, prodded, and occasionally broken things over the years in the 
name of improvements!




I agree generally with all you say, except one point: I don't believe in 
freedom to use personal  standards, as I've seen on net.
I believe in beeing tolerant with others, and being respectful of 
standards in my job.


For example: qmail rejects emails if they do not respect CR\LF, I put a 
patch to accept always messages despite of CR\LF, but my outgoing 
messages respect the standard.
I've seen ISP blocking email from Italy or from Russia or from China, 
just as their decision, and they were generating big problems only for 
semplifying their job. I think you do not agree with that behaviour.



Regards,

Tonino



Dan McAllister
IT4SOHO

Anyone else remember ROT13 as a way to encode NSFW content?
Abj vf gur orfg gvzr! :)

On 5/19/2014 5:05 PM, Tonix - Antonio Nati wrote:
Strange, I have an opposite opinion on the most of catch-all and 
delete usage I'm reading here in this thread.


Personally, and as provider of email business, I consider catch-all 
account useful only when you have a new domain, and customer does not 
know which mailboxes were running. So you set up a catchall account 
and start creating all necessary accounts, and stop catch-all when 
the most of accounts are created.


About deleting all email for not existing users, I consider it a bad 
service to customers, as they have legitimate raports

Re: [qmailtoaster] Re: to catch all or no

[Tonix - Antonio Nati]

Il 20/05/2014 23:36, Dan McAllister ha scritto:

Jim:

Per the discussion Antonio and I have been having on this same thread:
 - I say to set the invalid behavior to delete (which it appears 
you have done)
 - Antonio says to send a bounce message (I disagree and say that this 
is the WORST of the 3 options)


I never said to bounce messages.
I said to reject them at SMTP level, which is completely different from 
bouncing messages.


First option: reject at SMTP level (Save traffic, give the correct 
answer to sender)


rcpt to: f...@fakedomain.dom
511 sorry, no mailbox here by that name

Regards,

Tonino

--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: to catch all or no

[Tonix - Antonio Nati]

Strange, I have an opposite opinion on the most of catch-all and delete 
usage I'm reading here in this thread.


Personally, and as provider of email business, I consider catch-all 
account useful only when you have a new domain, and customer does not 
know which mailboxes were running. So you set up a catchall account and 
start creating all necessary accounts, and stop catch-all when the most 
of accounts are created.


About deleting all email for not existing users, I consider it a bad 
service to customers, as they have legitimate raports with business 
partners, and if someone writes to the wrong address it is correct and 
ethical to report them back that address is wrong, so they can use 
another way to contact the recipient, instead of waiting for never 
coming reply messages.
More, the abuse of deletion and missing respect for RFC forces users to 
ask always for delivery and read receipt, incrementing the volume of 
useless emails.


About signing headers with authenticating sender address, is a must 
because it makes senders responsable for what they are sending, and the 
most of our business customers wants their domain to be used only for 
legitimate emails,


Of course other opinions may be based on different needs, but I think 
respect of RFC should always be at first place, otherwise people will 
look soon for other stable and reliable message delivery methods.


Something I think often about: as email providers, we should look like 
real postmen: we cannot read (intentionally I mean), lose, damage others 
emails. Virus and SPAM must be fought, and apart real viruses and real 
spam all the remaining MUST be delivered. Any not valid damage or loss 
could be legally pursued.



Regards,

Tonino


Il 19/05/2014 21:10, Eric Shubert ha scritto:

On 05/19/2014 08:06 AM, Jim Shupert wrote:

How might one do - have a DELETE rule for badly addressed messages. I
just drop them and forget about it?

is it as easy as:  Set catchall email deletedfrom admin
in truth ... i thought you HAD to have a catch all account -- yes - i
would rather not.

thanks


Personally, I use a catchall account for my domain, and I don't get 
very much spam there at all. I do a few use a few tools for mitigating 
this.


1) the badmailto file can specify addresses with a regex. So for 
example, if your domain accounts don't contain numbers or whatever 
special characters, or your accounts always follow a certain pattern, 
you can write badmailto rules to reject these attempts. I used to get 
a lot of spam with numbers in the account name, and eliminated them 
witha few badmailto rules. This file can also be used to reject 
messages to defunct accounts.


2) use spamdyke to blacklist local domains. This seems counter 
intuitive, but so long as legit users always authenticate and only 
send email via your server, this works nicely.


That being said, I can see where some domains would want to simply 
delete these messages. While deleting messages goes against the RFCs, 
doing so certainly appears to be a best practice. Some rules, while 
well intended, have unintended consequences. I think this is one such 
rule.



also that strategy of :  giving each user a separate mailbox name and
e-mail address 
yes , that is interesting -- I can see how that would work
unfortunately in my current situation folks already have the
configuration  that we have.
but maybe for a new bunch of folks a new domain


This is a most excellent method of managing user accounts. I've 
considered doing this, but haven't actually implemented it yet. Along 
these lines, I've also considered modifying the header record qmail 
adds so that the authentication account isn't listed in its entirety. 
This would help to protect the actual account name.



thanks for the food for thought ,,, a hardy meal.

jim



Thanks as well.




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: to catch all or no

[Tonix - Antonio Nati]

Il 19/05/2014 23:26, Angus McIntyre ha scritto:

Tonix - Antonio Nati wrote:

About deleting all email for not existing users, I consider it a bad
service to customers, as they have legitimate raports with business
partners, and if someone writes to the wrong address it is correct and
ethical to report them back that address is wrong, so they can use
another way to contact the recipient, instead of waiting for never
coming reply messages.

I take your point, but the volume of attempted deliveries to non-existent
addresses is increasing continuously. Some of the domains I manage each
receive messages daily sent to literally hundreds if not thousands of
addresses that do not exist and have never existed.

Sometimes the bogus addresses are clearly the result of bad de-munging by
spamlist generators. For example, if you have a real address
'system-reports@', the spammer might try to send to 'reports@', having
mistakenly stripped off the first part. I've also seen attempts to deliver
to what were obviously once message IDs that have somehow been scraped up
by spammers and added to a list under the impression that they were email
addresses. Then there are the spammers who permute real addresses (i.e. if
you have someuser@, they might create a fake sender address of
'xyzsomeuser@') and these get fed back into the address collectors as
well. And some just seem to be invented by combining random characters.

If you bounce all these, then you will generate huge amounts of email,
much of it going back to real users whose addresses have been forged in
the 'From' line of the spam message.



Reject at SMTP level is the best practise, no traffic involved, and the 
email remain in charge of the sending server.

SPF should help avoiding emails to real recipients from forged senders.



More, the abuse of deletion and missing respect for RFC forces users to
ask always for delivery and read receipt, incrementing the volume of
useless emails.

I don't like read receipts, but I think the volume of worthless mail
generated is a fraction of what you'd get if you bounce every message to a
non-existent user.


Again, why do you bounce it instead of stopping  it at SMTP level?

Regards,

Tonino




Of course, I have to admit that the spammers who are targeting these
nonsense addresses are more likely than others to be rejected at
connection time by spamdyke's RDNS checks or SaneSecurity, so maybe the
bounce volume would be smaller than I expect. Still, the potential is
there.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: MX configuration for anti-spam

[Tonix - Antonio Nati]

Il 28/04/2014 18:12, Eric Shubert ha scritto:

On 04/27/2014 01:38 PM, Hasan Akgöz wrote:

Hi Eric,
The first time I heard you specify the subject. I think this method is
not a good idea. becuse If you mess around with MX records, you deserve
to have lost mails and angry co-workers/customer etc... :).


Are you suggesting that there are legit servers that can't handle such 
a configuration?



Before I quitted my email service (I migrated to a collegue wich manages 
a lot more accounts than me), I was considering to use this way to 
capture spam on my servers.


Only problem I see this high priority MX may be active only if another 
low level MX is active, otherwise it will classify everything as SPAM, 
and a simple reboot of main MX may be troublesome.


So, the main problem is to keep this spam MX up only when lower priority 
MX are up.


Tonino





Try ASSP ( Anti-Spam SMTP Proxy Server ).


I've looked at ASSP in the past. I don't see a point in having both 
ASSP and spamdyke. If someone can sell me on ASSP over spamdyke, I'd 
be happy to look at it again.


Is anyone out there using ASSP with QMT?


And DNSBL,SURBL,SBL,RBL (zen.spamhaus.org
http://zen.spamhaus.org and spamcop.org http://spamcop.org).


I presently use:
dns-blacklist-entry=b.barracudacentral.org
dns-blacklist-entry=zen.spamhaus.org

I dropped spamcop due to problems they've had with FPs.

Thanks Hasan.




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: MX configuration for anti-spam

[Tonix - Antonio Nati]

I don't understand what that has to do with using another fake MX to 
capture SPAM.


Instead, it worth the while to setup such MX only to evaluate if there 
is a consistent stream of emails which can be captured and tagged as 
SPAM (because they would be 100% SPAM) for improving spam assassin 
evaluation or forwarding to capture engines.


The most annoying SPAM we are having here is 'local SPAM', going to 
normal MX: small unsolicited mailing lists which are too small to be 
catched from big engines, but still very annoying.


Regards,

Tonino


Il 28/04/2014 19:54, Dan McAllister ha scritto:
OK, I'm johnny-come-lately to this discussion, but let me add my 
2-cents worth in here:


FIRST: Users who want to switch mail providers or mail server 
technologies -- but have no changes on the client end are 
/*dreaming*/. I tell my clients that I can minimize the changes, but 
the more I minimize the changes, the higher the cost. (It's kinda like 
buying a new car and expecting the dealer to move all the crap from 
your old car into the new one, including copying the radio station 
presets and getting all the trash located in just the same spots -- 
even though the new car has XM radio and a glove box, while the old 
one did not.


Converting from one mail server type to another can be tricky, and 
should be done with great care. Some of the gotcha's:
 - When you've switched from one MX server to another, some remote 
SMTP servers may still try to attach to the old server
RESOLUTION: Create a forward (or smtproute) on the old server to 
force delivery of new messages to the new server
 - When you're migrating IMAP folders, there can be different 
limitations (some IMAP servers allow a space as the first or last 
character in an IMAP folder, others do not. Some allow special 
characters, others do not... and so on)
RESOLUTION: Provide a method to allow users to copy their own 
folders from the old server to the new (alternatively, you can do it 
-- but then you're increasing your workload unnecessarily... or else 
charge for it.


There are plenty more, but those are the ones that quickly jump to mind.

Dan


On 4/28/2014 1:15 PM, Tonix - Antonio Nati wrote:

Il 28/04/2014 18:12, Eric Shubert ha scritto:

On 04/27/2014 01:38 PM, Hasan Akgöz wrote:

Hi Eric,
The first time I heard you specify the subject. I think this method is
not a good idea. becuse If you mess around with MX records, you 
deserve

to have lost mails and angry co-workers/customer etc... :).


Are you suggesting that there are legit servers that can't handle 
such a configuration?



Before I quitted my email service (I migrated to a collegue wich 
manages a lot more accounts than me), I was considering to use this 
way to capture spam on my servers.


Only problem I see this high priority MX may be active only if 
another low level MX is active, otherwise it will classify everything 
as SPAM, and a simple reboot of main MX may be troublesome.


So, the main problem is to keep this spam MX up only when lower 
priority MX are up.


Tonino





Try ASSP ( Anti-Spam SMTP Proxy Server ).


I've looked at ASSP in the past. I don't see a point in having both 
ASSP and spamdyke. If someone can sell me on ASSP over spamdyke, I'd 
be happy to look at it again.


Is anyone out there using ASSP with QMT?


And DNSBL,SURBL,SBL,RBL (zen.spamhaus.org
http://zen.spamhaus.org and spamcop.org http://spamcop.org).


I presently use:
dns-blacklist-entry=b.barracudacentral.org
dns-blacklist-entry=zen.spamhaus.org

I dropped spamcop due to problems they've had with FPs.

Thanks Hasan.







--
IT4SOHO, LLC
33 - 4th Street N, Suite 211
St. Petersburg, FL 33701-3806

CALL TOLL FREE:
   877-IT4SOHO

877-484-7646 Phone
727-647-7646 Local
727-490-4394 Fax

We have support plans for QMail!




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: 451 4.4.0 DNS temporary failure (chkuser)

[Tonix (Antonio Nati)]

Il 16/10/2013 21:46, Eric Shubert ha scritto:
I would normally answer pdns, because it's local. I'm not aware of any 
drawbacks to using pdns-recursor.


Is pdns running?
# chkconfig --list pdns-recursor
# service pdns status

Are you seeing any pdns errors in the log?
# grep pdns /var/log/messages | less

Regarding your error, I've seen this historically with QMT on rare 
occasions, and haven't been able to recreate the condition with any 
consistency. I haven't seen it personally in quite a while.


Are you using port 587 or 25 for these submissions? Are you seeing any 
corresponding log messages? (please post them if you can)


How busy is your QMT host when this happens? Might this be related to 
load?


I wonder if there's something a little quirky with chkuser's code, 
given that the message is coming from chkuser. That's a long shot. You 
might try building qmail-toaster with CHKUSER_RCPT_MX disabled (I 
don't think it's possible to do with environment variable). Please 
give this a try and see if that fixes things up for you.


This setting should probably be disabled in the stock QMT anyhow, as 
it makes little sense. On inbound messages, the RCPT_MX has already 
been found (otherwise no connection could be made), and on outbound 
messages, a missing MX would simply create a bounce back to the 
submitter, and thus eliminate the question of which recipient the 
error was for.


Tonino, what say you about this? We appreciate your input.


Hello Eric,

that part of chkuser code is well working and stable, and I do not see 
code problems; that error code means simply DNS is not answering.


I've not understood:

 * if problem is on sender or recipient (to know which domains have
   problems).
 * if error is immediate or delayed (to know if there are DNS loops on
   local domain or external domains)


About disabling chkuser, I'd try:

   Enable (uncomment) the following define, and set it to 'RELAYCLIENT'.

   #define CHKUSER_DISABLE_VARIABLE RELAYCLIENT

So, if RELAYCLIENT is set, chkuser should not work at all for that session.

Regards,

Tonino





Another thing, is there an entry in /etc/hosts which would correspond 
to one of your rcpthosts domains? I can imagine that causing a problem.





--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Outgoingip / Outgoingips

[Tonix (Antonio Nati)]

Il 24/09/2013 19:37, Nicholas Chua ha scritto:

Hi,
Have anything work with outgoingip / outgoiningips

Can any of these patches do what I want below.

I had binded 2 IPs to eth0 and eth0:1 respectively with IP 1.1.1.1 and 
1.1.1.2.
I would like to send emails to abc.com domain using  IP 1.1.1.1 all 
others with  1.1.1.2.


Is it possible?



I think none of existing patches will help you.

Probably you will have only one solution, but, due to qmail limits, you 
need a second machine:


 * setup another copy of qmail (or another MTA) on another machine (or
   another VM, or another OpenVZ container), used only for delivering
   using the alternative address using 1.1.1.1, while standard qmail
   configuration will use 1.1.1.2.
 * modify SMTP routes, and send the emails for abc.com domain to this
   alternative address (1.1.1.1), which will then deliver to end
   recipients.

You cannot do that two qmail installation in same machine, because qmail 
will manage each IP on the machine as a local IP for qmail, and will not 
deliver to the other MTA.
I was planning a patch to solve this problem (instead of checking for 
local IP, I would get the list of local IP from a file), before I 
stopped to make changes to qmail.


This is a real limit, and it alone its a good reason for building qmail 
within a jail, or a container, or a separated VM, in order to have more 
copies of indipendent qmails for solving such problems.



Regards,

Tonino



Regards
Nic



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] cannot configure email account in Thunderbird

[Tonix (Antonio Nati)]

Try authentication: plain password.

Regards,

Tonino


Il 13/09/2013 13:30, ChandranManikandan ha scritto:

Hi All,
Please find the attachment of my problem.
I was using courier imap and it was working perfect. After migrate 
from courier to dovecot.
I could not able to create email account in thunderbird 17.0.8 and 
it's showing always in this message. FYR attached screenshot.


How to fix this issue.
Please help me anyone.

--
*/Thanks  Best Regards,
Manikandan.C
/*


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: chkuser config and patch tweaks on fresh QTP install

[Tonix (Antonio Nati)]

Il 04/06/2013 20:11, Sven Miller ha scritto:


On Tue, Jun 4, 2013 at 1:26 PM, Eric Shubert e...@shubes.net 
mailto:e...@shubes.net wrote:


On 06/04/2013 09:38 AM, Sven Miller wrote:

Previously I stumbled my way through a qmailtoaster install,
and now I
have to do a fresh install on a RHEL 6.4 box.  I see
qmailtoaster-plus
is the new way to do things, but I don't know how to include the
install-time tweaks I made in the past.

For one I will need to tweak the chkuser configuration.  In
the past
this was done by pausing the build and editing the settings
file (per
http://wiki.qmailtoaster.com/index.php/Chkuser).  How will I
tweak the
chkuser config when using QTP?


Same way, for the most part. The build gets done in a chroot
environment though, so you'd need to chroot into it in order to
change the sources. I think it might be simpler to build your own
srpm with the modified sources. Then put your rpm in
/usr/src/qtp-upgrade/SRPMS/ and qtp-newmodel will use it.

You're likely not to need to do this though. Which settings were
you having to tweak? The stock settings work for just about
everyone now, including many special characters for various things
including blackberries (are people still using those?). ;) Here
are the current stock settings regarding special characters:
#define CHKUSER_ALLOW_SENDER_CHAR_1 '$'
#define CHKUSER_ALLOW_SENDER_CHAR_2 '%'
#define CHKUSER_ALLOW_SENDER_CHAR_3 '/'
#define CHKUSER_ALLOW_SENDER_CHAR_4 '?'
#define CHKUSER_ALLOW_SENDER_CHAR_5 '*'
#define CHKUSER_ALLOW_SENDER_CHAR_6 '^'
#define CHKUSER_ALLOW_SENDER_CHAR_7 '~'
#define CHKUSER_ALLOW_SENDER_CHAR_8 ''
#define CHKUSER_ALLOW_SENDER_CHAR_9 '#'
#define CHKUSER_ALLOW_SENDER_CHAR_10 '='


Unfortunately we've had to deal with addresses that contain 
apostrophes like april.o'n...@example.com 
mailto:april.o%27n...@example.com.  We initially just added it as a 
character but when forward slashes also caused problems (srs uses 
base64 encoding) so we ultimately enabled CHKUSER_STARTING_VARIABLE to 
let us bypass chkuser completely.  This time around I plan to just set 
CHAR_9 to '\'' and cross my fingers.



I suggest to keep chkuser enabled and comment these lines in configuration:

/*#define CHKUSER_RCPT_FORMAT */
/*#define CHKUSER_SENDER_FORMAT */

Regards,

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Relaying

[Tonix (Antonio Nati)]

Check if that account is enabled to relay in vpopmail. If it is, it will 
relay despite of tcprules settings.

Remove permission from that single account.

Regards,

Tonino


Il 27/03/2013 17:58, Rvaught ha scritto:


Is there a way to block relaying  for one email account ?

*From:*Helmut Fritz [mailto:hel...@fritz.us.com]
*Sent:* Wednesday, March 27, 2013 12:50 PM
*To:* qmailtoaster-list@qmailtoaster.com
*Subject:* RE: [qmailtoaster] Relaying

It may be that user has a worm/virus.

*From:*Rvaught [mailto:rvau...@libertycasting.com]
*Sent:* Wednesday, March 27, 2013 9:44 AM
*To:* qmailtoaster-list@qmailtoaster.com 
mailto:qmailtoaster-list@qmailtoaster.com

*Subject:* RE: [qmailtoaster] Relaying

I tried removing sender_nocheck=1 and I am still relaying outside mail 
on that account.


*From:*Helmut Fritz [mailto:hel...@fritz.us.com]
*Sent:* Wednesday, March 27, 2013 12:18 PM
*To:* qmailtoaster-list@qmailtoaster.com 
mailto:qmailtoaster-list@qmailtoaster.com

*Subject:* RE: [qmailtoaster] Relaying

I believe sender_nockeck=1 is the issue?  I think that turns off 
authentication for senders.  others with a lot more expertise in tcp 
rules than I will hopefully confirm.


*From:*Rvaught [mailto:rvau...@libertycasting.com]
*Sent:* Wednesday, March 27, 2013 8:54 AM
*To:* qmailtoaster-list@qmailtoaster.com 
mailto:qmailtoaster-list@qmailtoaster.com

*Subject:* [qmailtoaster] Relaying

Somehow I have something setup wrong  now and I am having spam being 
relayed thru my email server on  one email account . I have changed 
their password.   I think I have something wrong in my tcprules.d file 
. I want to allow local users to send mail but block relaying.


I have :

127.:allow,RELAYCLIENT=

192.:allow,RELAYCLIENT=

128.:allow,RELAYCLIENT=

:allow,BADMIMETYPE=,SENDER_NOCHECK=1,CHKUSER_RCPT_FORMAT=0,CHKUSER_SENDER_FORMAT=0,BADLOADERTYPE=M,CHKUSER_RCPTLIMIT=75,CHKUSER_WRONGRCPTLIMIT=50,QMAILQUEUE=/var/qmail/bin/simscan

192 and 128 are my local networks.

Rick




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: client gets you are breaking our security rules when sending 300 invoices to thier clients.

[Tonix (Antonio Nati)]

Il 24/12/2012 23:49, Eric Shubert ha scritto:
These are all good things to do to QMT, and I hope to have separate 
tcprules for smtp and submission ports in the stock QMT at some point.


Tony, from what you've indicated though, I expect it's the intrusion 
threshold rule that's biting you. I'm not certain what triggers this 
rule, and I could be wrong about this. Hopefully Tonino will clarify 
things in this regard.


Please let us know if changing the CHKUSER_RCPTLIMIT variable gets you 
going or not.


Hello Eric,

Actually there are basically two variables which provoke this message: 
max recipients, and max wrong recipients.
Reaching one of this limits sets the 'intrusion flag on', which display 
this message for any other following rcpt.


Regards,

Tonino




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: client gets you are breaking our security rules when sending 300 invoices to thier clients.

[Tonix (Antonio Nati)]

Il 27/12/2012 19:40, Eric Shubert ha scritto:

On 12/27/2012 02:58 AM, Tonix (Antonio Nati) wrote:

Il 24/12/2012 23:49, Eric Shubert ha scritto:

These are all good things to do to QMT, and I hope to have separate
tcprules for smtp and submission ports in the stock QMT at some point.

Tony, from what you've indicated though, I expect it's the intrusion
threshold rule that's biting you. I'm not certain what triggers this
rule, and I could be wrong about this. Hopefully Tonino will clarify
things in this regard.

Please let us know if changing the CHKUSER_RCPTLIMIT variable gets you
going or not.


Hello Eric,

Actually there are basically two variables which provoke this message:
max recipients, and max wrong recipients.
Reaching one of this limits sets the 'intrusion flag on', which display
this message for any other following rcpt.

Regards,

Tonino






It'd be nice if in a future revision each setting/rule had its own 
unique message, so admins could tell which limit was triggered. I 
don't think this is very urgent though.


To be totally honest, I expect that spamdyke will soon have pretty 
much all of the features of chkuser (I understand the forthcoming 
version will be able to check for the existence of user accounts). 
When spamdyke becomes part of the stock QMT, chkuser will likely no 
longer be needed. Chkuser has certainly served its purpose well, none 
the less.


Thanks Tonino.



You can already check for remote (which in this case means local :-) ) 
recipients using mailCleaner, which is indipendent of the mail server 
and can be installed as indipendent VM (doing also load balancing).


Regards,

Tonino

--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: client gets you are breaking our security rules when sending 300 invoices to thier clients.

[Tonix (Antonio Nati)]

Il 27/12/2012 21:17, Tonix (Antonio Nati) ha scritto:

Il 27/12/2012 19:40, Eric Shubert ha scritto:

On 12/27/2012 02:58 AM, Tonix (Antonio Nati) wrote:

Il 24/12/2012 23:49, Eric Shubert ha scritto:

These are all good things to do to QMT, and I hope to have separate
tcprules for smtp and submission ports in the stock QMT at some point.

Tony, from what you've indicated though, I expect it's the intrusion
threshold rule that's biting you. I'm not certain what triggers this
rule, and I could be wrong about this. Hopefully Tonino will clarify
things in this regard.

Please let us know if changing the CHKUSER_RCPTLIMIT variable gets you
going or not.


Hello Eric,

Actually there are basically two variables which provoke this message:
max recipients, and max wrong recipients.
Reaching one of this limits sets the 'intrusion flag on', which display
this message for any other following rcpt.

Regards,

Tonino






It'd be nice if in a future revision each setting/rule had its own 
unique message, so admins could tell which limit was triggered. I 
don't think this is very urgent though.


Actually messages are diversified (i'm quite sure) after the threshold 
is set.
As the threshold is reached, there should be a specific message. After 
that, always the same message (generic security rule message).


I have to check, but I'm sure 99%. Could be external message is always 
the same (do not want to give any advantage to intruders), while 
internally there should be the double phase.


Regards,

Tonino





To be totally honest, I expect that spamdyke will soon have pretty 
much all of the features of chkuser (I understand the forthcoming 
version will be able to check for the existence of user accounts). 
When spamdyke becomes part of the stock QMT, chkuser will likely no 
longer be needed. Chkuser has certainly served its purpose well, none 
the less.


Thanks Tonino.



You can already check for remote (which in this case means local :-) ) 
recipients using mailCleaner, which is indipendent of the mail server 
and can be installed as indipendent VM (doing also load balancing).


Regards,

Tonino

--

 Inter@zioniInterazioni di Antonio Nati
http://www.interazioni.it   to...@interazioni.it




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] delivery problem with apostrophe in sender's address

[Tonix (Antonio Nati)]

Il 04/12/2012 13:35, Rvaught ha scritto:


I am having a problem receiving mail from a customer who has an 
apostrophe in their email address. (LO'n...@somewhere.com). Here is 
the error message they are receiving :


5.1.0 - Unknown address error 550-'Requested action not taken: mailbox 
unavailable' (delivery attempts: 0)


We can send mail to the address ok. I have search old  posts and see 
that SENDER_NOCHECK='1'  after the :allow should fix this. I have 
added that to my tcp.smtp file and ran qmailctl cdb . I am still 
having the problem.


Is there something else I need to change ?

Rick Vaught

Liberty Casting

Error message says: 'mailbox unavailable', which should mean 'recipient 
address not existant'.


So, why do you think it should be a sender address problem?

What do you read in your local maillog about this incoming message?

Regards,

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] CHKUSER questions

[Tonix (Antonio Nati)]

Il 13/11/2012 11:09, Nikolay Mitev ha scritto:

Hi Team,

Please a little help, I activated RCPTCHECK = 1 in the tcp rules, but
continues to successfully receivefromlog emails to non-existent 
recipients.
How can you activate the check of local users and generate 
notification to sender.


Best regrads,
Nikolay


chkuser is activated for each domain if, using qmail-admin. you set 
bounce for not existing recipients.


or, in .qmail-default, you have:

| /yourpath/vdelivermail '' bounce-no-mailbox

Regards,

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Catch-all like Google Apps

[Tonix (Antonio Nati)]

Il 23/10/2012 17:13, Alessio Cecchi ha scritto:

Hi,

Google Apps has a special way to manage incoming emails to non 
existent users when catch-all is enabled. For example, mydomain.com is 
hosted at Google and have catch-all to a...@mydomain.com.


Somebody send me an email message with 2 (non existent) recipients 
1...@mydomain.com,2...@mydomain.com.


Normally qmail, but also postfix, delivered two email in 
a...@mydomain.com, but Google delivery only one email.


Is possibile to emulate this in qmail?



One note.
I feel this feature is not useful when using catchall accounts, because 
you'll miss to know which different recipients are used.


But I agree this feature is really interesting in all other cases.

First thing I'm thinking to is the speed for checking if the same 
message is already existing, and I do not think a text comparison is sane.


Probably, messages should be stored having as part of the name the 
internal message identifier set by the sender system.
In this case, a scan of folder (only new folder !) should check if 
message is already inside. Probably the sender recipient should be part 
of the name as well (in case message identifier is too simple).


Regards,

Tonino






--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Very Slow Server

[Tonix (Antonio Nati)]

If you are in a data center, use DNSes of your connectivity provider.

For sure it has more cache than your and is more updated.

Regards,

Tonino

Il 11/09/2012 16:58, Mike Tirpak ha scritto:
I would love to change the dns cache server, but it is in production 
and I don't want to mess it up.  I checked out the documentation and 
it seems like a good program.  When I setup my next server, I'll use 
PowerDNS instead of djbdns.  As of right now, it seems pretty fast. 
Just as fast as the servers that are running DNS.


Thanks for the advice,
Mike

On 9/11/2012 10:32 AM, Eric Shubert wrote:
You should realize that your server will perform best with a resolver 
running on the QMT host. It sounds to me as though your djbdns wasn't 
running quite properly, as you indicated.


I recommend ditching djbdns, and installing the pdns-recursor 
package. PowerDNS is a modern, efficient DNS server. To use it, you 
simply install the package via yum, and put 127.0.0.1 first in your 
/etc/resolv.conf file.


Of course your QMT will function ok with an external resolver, just 
not quite as efficiently.





-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com





--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] TAPS ISSUE

[Tonix (Antonio Nati)]

Ideally you shoould find three copies (including sender), but I remeber 
TAPS only backups first match it finds in configuration.


Probably, if you change the order of recipients (and use a different 
sender), you could check if only first recipient is backuped.


Regards,

Tonino

Il 17/05/2012 15:06, Manikandan Mariappan ha scritto:

Hi,

  I had a doubt in taps that four email ids has been 
created in server.That one email id is backup id and other three email 
ids are normal user ids.


Example : Four email ids are :-

t...@example.com mailto:t...@example.com
e...@example.com mailto:e...@example.com
inter...@example.com mailto:inter...@example.com
bac...@example.com mailto:bac...@example.com

vi /var/qmail/control/taps

t...@example.com:bac...@example.com mailto:ac...@example.com
e...@example.com:bac...@example.com mailto:ac...@example.com
inter...@example.com:bac...@example.com mailto:ac...@example.com

  When a mail has been send from t...@example.com 
mailto:t...@example.com to e...@example.com 
mailto:e...@example.com and put cc as inter...@example.com 
mailto:inter...@example.com. I login and check bac...@example.com 
mailto:bac...@example.com email id, send mail and incoming mail only 
one copy is delivered. But my questions is two mails should be 
delivered because two users should coming inside the mail but only one 
mail has been triggered in backup mail id. How it is possible...




--
Regards,
Manikandan.M





--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: TAPS ISSUE

[Tonix (Antonio Nati)]

http://www.inter7.com/qmailtap/README.tap

   qmail provides the ability to make a copy of each email that flows through 
the system.
   This is done using the QUEUE_EXTRA code. See qmail FAQ #8.2

   The qmail tap patch adds additional functionality:
   1) Specify which email addresses to tap using a regex style control file. 
With the
   regex function, you can specify full domains or individual email 
addresses.

   2) Specify which email address to send the emails to.

   3) Qmail does not need to be restated to when the taps control file is 
changed.

   The regex match is applied to both the to and from email addresses. So email
   sent to or from the addresses will be copied. Matching is case insensitive.
   If there are multiple matches, the first match is used.

Regards,

Tonino


Il 17/05/2012 16:00, Eric Shubert ha scritto:

It sounds to me as though TAPS is matching one sender and one recipient.

Is this a bug, or perhaps a misunderstanding of TAPS behavior? It 
seems logical to me that there would be one outbound tap and one 
incoming tap.


There can of course be only one sender on the outbound side. Why would 
someone want multiple copies of the same thing on the incoming tap?





--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] question concerning chkuser

[Tonix (Antonio Nati)]

That message has nothing to do with chkuser.
Check your permissions.

Regards,

Tonino

Il 04/04/2012 04:43, Rajesh M ha scritto:

hi

using qmailtoaster on centos. i have spamdyke and chkuser enabled

i got an error like this in my log file today which was quite puzzling

write_to_qmail-inject_failed:_32/system_error_calling_qmail-inject

what could be the reason for this ?

is chkuser supposed to reject such messages because the mail from
contains invalid characters ?


2012-04-04 07:07:25.929746500 new msg 71244066
2012-04-04 07:07:25.929767500 info msg 71244066: bytes 251598 from
prvs=434a6a0d6=statem...@rbs.com  qp 5047 uid 89
2012-04-04 07:07:25.939126500 starting delivery 93238: msg 71244066 to
local mydomain.com-fina...@mydomain.com
2012-04-04 07:07:25.949806500 delivery 93238: deferral:
qmail-inject:_fatal:_unable_to_parse_this_line:/To:_fina...@mydomain.com;;/write_to_qmail-inject_failed:_32/system_error_calling_qmail-inject/



thanks
rajesh





-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
 Vickers Consulting Group offers Qmailtoaster support and installations.
   If you need professional help with your setup, contact them today!
-
  Please visit qmailtoaster.com for the latest news, updates, and packages.

   To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
  For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com






--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] RENAMED - Hardware vs. Software RAID

[Tonix (Antonio Nati)]

Il 02/04/2012 23:55, Dan McAllister ha scritto:

From an earlier post:

Of course your hardware configuration can make a difference too.
You mentioned 2x2TB drives. I hope you have them configured as
raid-1 mirrors (software raid should do fine for raid-1). raid-1
will give you a little slower write, but faster read performance.

I'm a little bit of a stickler on RAID assumptions... so I am going to 
stick my nose into this (where it probably does not belong).

Indulge me or not -- I've been up-front about what I'm doing here! :-)

There are a *significant *PERFORMANCE differences between hardware and 
software RAID -- even RAID-1. There are several criteria to consider 
for each technology -- specifically, read performance and write 
performance under both normal and degraded conditions, so here goes:


  * Normal RAID-1 Read Times:

There is no benefit in software RAID-1 for read-times on good
(healthy) arrays -- whether you read from drive 1 or drive 0 won't
matter, except for the potential overlapping of seek times, which
compared to hardware RAID-1 is minimal. There is only the one I/O
channel on a standard controller, and so you can actually accept
the data (I/O from drive to controller) from only 1 drive at a time.

There /can be /a considerable performance *increase *in using
HARDWARE RAID-1, assuming your controller supports parallel reads
(see below on /cheap/ RAID cards). On small reads, the increase
can be anywhere from 25-40%, on larger file reads, the increase
can approach a /theoretical /max of 50%! (By increase, I mean
performance increase -- as measured by /decreases /in wait times
from the moment a read request is received to the moment it is
satisfied back to the calling routine).

  * Degraded RAID-1 Read Times:

In software RAID-1, a failed drive can essentially bring down a
server as the controller continually tries to access a failing or
failed drive (assuming the drive isn't unrecognizable) and blocks
other I/O as a result. The only fix is to reboot (often in single
user mode) and mark the bad drive as down or removed. MOST
software RAID (e.g. embedded motherboard controllers) cannot (or
more correctly, WILL not) do this automatically -- they just
continue to flail themselves against the failing drive, making the
system response time measured in minutes (vs. milliseconds).  Odd
side-note: Linux MD RAID-1 performs MUCH better in the degraded
mode, because it is much faster to mark a bad drive as down, thus
ending the I/O blocks that otherwise cripple the system.

In hardware RAID-1, a failed drive is usually taken offline
/automatically /by the controller (similar to the response time of
the Linux MD software solution, but NOT similar to the cheap or
motherboard RAID solution that tries repeatedly to access a bad
drive) -- so read times essentially revert to JBOD (single disk)
read performance levels. There can be some hiccups while the card
determines the good/bad status of the bad drive, but better
hardware RAID cards do this while continuing to read from the
good drive (making a new read request while it works on the
bad drive) -- and during this time, read performance can be
impacted, but usually only slightly, and NOT essentially blocking
the entire server behind the I/O waits then, once the drive
testing is done and it is marked down, the performance essentially
equals JBOD performance (as with the software solution, once the
bad drive is removed -- logically or physically).

  * Normal RAID-1 Write Times:

There is a *write-penalty* in software RAID-1, even on good arrays
-- because all data has to be written twice, and even with NCQ,
the controller has to talk to each drive independently (that is,
send the write data to each drive, one drive at a time). NCQ does
offset this somewhat (assuming you enabled it), but not during
heavy load times because there is really only one I/O channel on
the drive controller (even on SATA RAID controllers).

There is usually *_no write-penalty_* in hardware RAID-1, because
the controllers are designed to talk to each drive
independently. (NOTE: Some cheaper RAID cards use non-RAID
optimized controllers, in which case the performance is the same
as with the software RAID, except you're not spending the
processing time on the main system, you're using the on-board RAID
processor on the card.) If you're interested in write-performance
improvements, INSIST on a /_*REAL *_/hardware RAID solution!

  * Degraded RAID-1 Write Times:

Again, in software RAID-1, a failed drive can essentially bring
down a server as the controller continues to try to write to a
failing or failed drive (assuming the drive isn't unrecognizable).
As with the read function, the only reasonably fast fix is to

Re: [qmailtoaster] Re: RENAMED - Hardware vs. Software RAID

[Tonix (Antonio Nati)]

Il 03/04/2012 18:04, Eric Shubert ha scritto:

On 04/03/2012 01:09 AM, Tonix (Antonio Nati) wrote:

World is grey sometimes, between the white of HW raid and the black of
SW raid.

I am a fan of hardware raid, and we use at the most HP SmartArray cards,
as we feel they are very reliable and fast.

But, usage of ZFS in last installations put us in front of a new age of
thinking: ZFS reccomends to disable hardware raid and use JBOS instead.
ZFS will care about RAID. So, willing to use this new FS, we have no
other choice than have HW raid on boot disks (with UFS), and JBOD on
other disks (with ZFS).

At the same time, while we are currently using RAID 10 and RAID 5, I
still see very serious reasons to use RAID6 in some environments.

Disks are generally cheap, but serious disks are expensive, despite of
the huge size. So I don't blame is someone is putting 12 x 2TB disks in
a RAID6 configuration for slow speed or dedicated storage (like backups
or seldom used archives). 12 disks in RAID10 means 5 used disks (5 are
mirrored, 2 are hot spairs). 12 disks in RAID6 means 9 used disks (2 for
RAID6, one for hot spare). Difference in used storage is a lot.
I agree RAID10 is a lot faster, but in some environments this could not
be important, while price and reliability could be more important.

Regards,

Tonino


The times they are a changing. :)

I've heard great things about ZFS. I didn't realize that it's been 
making inroads with Linux.


Sorry, I'm speaking about FreeBSD world. But I feel distances are less 
than before between OSes.


Regards,

Tonino



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Questions on setting for the special e-mailaccount

[Tonix (Antonio Nati)]

I'm not following closely this thread, but I'm listening something odd.

For each define like CHKUSER_ALLOW_SENDER_CHAR_10 there is also in 
chkuser.c


   #if defined CHKUSER_ALLOW_SENDER_CHAR_10
(user-s[x] != CHKUSER_ALLOW_SENDER_CHAR_10)
   #endif


So, just adding another define in chkuser_setting.h is a waste of time, 
if you don't change chkuser.c too.


Tonino

P.S. I feel this check should not be used anymore, because as of today 
strange characters are widely used in email addresses.



Il 31/03/2012 09:27, q...@foxitsoftware.com ha scritto:

update.
Hi Eric,
I try the following steps,please help to check if it is OK.
1)vim /root/rpmbuild/BUILD/qmail-1.03/chkuser_settings.h
2)add
#define CHKUSER_ALLOW_SENDER_CHAR_11 ''' and  
#define CHKUSER_ALLOW_RCPT_CHAR_11 '''

/*
 * If you need more additional characters to be accepted within sender address
 * uncomment one of the following #define and edit the character value.
 * Be careful to use '*' (single hiphen) and NOT * (double hiphen) around the
 * wanted char.
 *
 * Remember: '#' and '+' are accepted by CHKUSER_ALLOW_SENDER_SRS
 *
 */
#define CHKUSER_ALLOW_SENDER_CHAR_1 '$'
#define CHKUSER_ALLOW_SENDER_CHAR_2 '%'
#define CHKUSER_ALLOW_SENDER_CHAR_3 '/'
#define CHKUSER_ALLOW_SENDER_CHAR_4 '?'
#define CHKUSER_ALLOW_SENDER_CHAR_5 '*'
#define CHKUSER_ALLOW_SENDER_CHAR_6 '^'
#define CHKUSER_ALLOW_SENDER_CHAR_7 '~'
#define CHKUSER_ALLOW_SENDER_CHAR_8 ''
#define CHKUSER_ALLOW_SENDER_CHAR_9 '#'
#define CHKUSER_ALLOW_SENDER_CHAR_10 '='
#define CHKUSER_ALLOW_SENDER_CHAR_11 '''
/*
 * If you need more additional characters to be accepted within rcpt address
 * uncomment one of the following #define and edit the character value.
 * Be careful to use '*' (single hiphen) and NOT * (double hiphen) around the
 * wanted char.
 *
 * Remember: '#' and '+' are accepted by CHKUSER_ALLOW_RCPT_SRS
 *
 */
#define CHKUSER_ALLOW_RCPT_CHAR_1 '$'
#define CHKUSER_ALLOW_RCPT_CHAR_2 '%'
#define CHKUSER_ALLOW_RCPT_CHAR_3 '/'
#define CHKUSER_ALLOW_RCPT_CHAR_4 '?'
#define CHKUSER_ALLOW_RCPT_CHAR_5 '*'
#define CHKUSER_ALLOW_RCPT_CHAR_6 '^'
#define CHKUSER_ALLOW_RCPT_CHAR_7 '~'
#define CHKUSER_ALLOW_RCPT_CHAR_8 ''
#define CHKUSER_ALLOW_RCPT_CHAR_9 '#'
#define CHKUSER_ALLOW_RCPT_CHAR_10 '='
#define CHKUSER_ALLOW_RCPT_CHAR_11 '''
3)
rpmbuild -bb --with fedora_1164 qmail-toaster.spec ---it is ok
Checking for unpackaged file(s): /usr/lib/rpm/check-files 
/root/rpmbuild/BUILDROOT/qmail-toaster-1.03-1.3.22.x86_64
Wrote: /root/rpmbuild/RPMS/x86_64/qmail-toaster-1.03-1.3.22.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/qmail-pop3d-toaster-1.03-1.3.22.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.9XekqK
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd qmail-1.03
+ '[' -n /root/rpmbuild/BUILDROOT/qmail-toaster-1.03-1.3.22.x86_64 -a 
/root/rpmbuild/BUILDROOT/qmail-toaster-1.03-1.3.22.x86_64 '!=' / ']'
+ rm -rf /root/rpmbuild/BUILDROOT/qmail-toaster-1.03-1.3.22.x86_64
+ '[' -d /root/rpmbuild/BUILD/qmail-1.03 ']'
+ rm -rf /root/rpmbuild/BUILD/qmail-1.03
+ exit 0
4)
[root@demo6 x86_64]# rpm -Uvh --replacefiles --replacepkgs qmail-*.rpm
Preparing...### [100%]
 Adding qmailtoaster users and groups.
groupadd: group 'nofiles' already exists
groupadd: group 'qmail' already exists
   1:qmail-toaster  warning: /var/qmail/control/servercert.pem created 
as /var/qmail/control/servercert.pem.rpmnew
### [ 50%]
 Creating queue/lock/trigger named pipe.
 Compiling badmimetypes.
 Compiling badloadertypes.
 Making tlsserverciphers.
 Linking tlsserverciphers to tlsclientciphers.
 Making dh_keys.
Generating RSA private key, 512 bit long modulus

...
e is 65537 (0x10001)
Generating DH parameters, 512 bit long safe prime, generator 2
This is going to take a long time
.+...+.++*++*++*++*++*++*
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
..++++..+..++*++*++*
   2:qmail-pop3d-toaster### [100%]
Regards
2012-03-31

q...@foxitsoftware.com

*???:* q...@foxitsoftware.com
*:* 2012-03-31  14:53:24
*???:* qmailtoaster-list
*??:*
*??:* Re: Re: [qmailtoaster] Re: Questions on setting for the special 
e-mailaccount

Hi Eric,
I try the following steps,please help to check if it is OK.
1)vim /root/rpmbuild/BUILD/qmail-1.03/chkuser_settings.h
2)add #define CHKUSER_ALLOW_SENDER_CHAR_11 '''
/*
 * If you need more additional characters to be accepted within sender address
 * uncomment one of the 

Re: [qmailtoaster] Fwd: pop3 port response very slow in private IP

[Tonix (Antonio Nati)]

High likely you have problems with DNS, as local IP are probably not 
resolved.


Regards,

Tonino

Il 08/03/2012 13:25, Manikandan Mariappan ha scritto:


Hi,
I have problem with my qmail server pop3 port(110) response 
very slow in private IP(192.168.1.20) only. Other ports response were 
very fast without any issues in qmail server private ip and public ip 
and localhost also. It mean time there is no restriction in hardware 
and software firewall.


Note: We are facing this problem for past one week,  we dont have any 
issues with port response before.




--
Regards,
Manikandan.M
9884439696









--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: chkuser rejecting mail to users with hyphens

[Tonix (Antonio Nati)]

Il 06/03/2012 20:37, Eric Shubert ha scritto:

On 03/06/2012 10:44 AM, Tonix (Antonio Nati) wrote:

Il 06/03/2012 18:29, Eric Shubert ha scritto:


Would you suggest we be using the
#define CHKUSER_ENABLE_USERS_EXTENSIONS
by default? It seems to me we should, as the -anything extension is
a standard part of qmail (unless I'm mistaken). If we should, can it
be enabled with an environment variable, or is it strictly a #define
setting?



Extensions are used for TMDA (I don't know if it is still used), ezml
maling lists, mailman lists, user extensions.

chkuser has different options:
- user extensions
- mailman lists
- ezmlm lists

you do not need user extension if you are in normal situations (I have
only ezmlm lists enabled).

You need the user extension if you use TMDA or in cases in which you
want to receive extensions.
In this case, chkuser checks for recipient existance, and if fails tries
again shifting towards left (using '-' as token to search).

With ezmlm and mailman lists enabled, it checks if recipient is
associated to a ezmlm/mailman list, and in such a case it accepts
extensions for that recipient.



Thanks for the great explanation Tonino. That clears things up for me. 
I still have a couple questions though.


What's the down side of enabling user extensions? qmail provides this 
capability by default. It seems to me that QMT should as well. No?


This is up to you.
With extensions DJB probably wanted to extend recipients possibilities, 
giving different address (i.e. eric, eric-test, eric-lab, eric-sales) 
and handle ezmlm extensions (ezmlm works heavily with extensions).


In my situation, extensions are not needed, and I prefer to keep a 
'standard' situation (only real account/aliases/lists work).

Other situations may be different.



Regarding mailman extensions, I have a QMT host running mailman with 
chkuser's mailman extensions disabled. This domain also has a catchall 
account. If I were to set catchall to bounce, I would also need to 
enable mailman list extensions for mailman to continue to work. Correct?


Yes, correct.
Catchall does not benefit of chkuser capabilities, while user-extensions 
or mailman features  do.





If I understand correctly, applying this setting would fix Russ's
problem. Or I suppose he could set a catchall account. Correct?



catchall is to be avoided if possible, as it accept always any recipient
and does not give any advantage to traffic/workload.
It should be used when you setup a new domain (coming from another ISP)
on which you don't know which accounts exist. So, for some time, you
accept all recipients and create accounts as you understand which
accounts are needed. At end of all you kill the catchall feauture and
enable 'bouncing'.


While I understand your scenario for when it should be used, I 
disagree that it should be avoided if possible. That may be the case 
for a service provider which has hundreds if not thousands of 
accounts, but not in all cases.


I agree, it depends on situations. In my case, when a user need an 
extension, he adds an alias.
I suggest only expert people should use catchall, as no error message is 
sent back, so senders are not notified about not existing recipients.





In situations where a domain is more private, a catchall account 
allows a large degree of flexibility regarding how email addresses are 
used. For instance, when I shop at SomeStore and they want my email 
address, I give them somest...@mydomain.com, and the mail is 
delivered. I then typically set up a forward for that address to a 
real account once I receive an email to that address in my catchall 
account. If I happen to start receiving spam to that address, I can 
discontinue use of that address by adding to the badmailto file, or if 
I'm in a bad mood, forward the spam back to the store who I gave the 
address to. :) BL, the catchall account saves me from having to 
remember to create a forward for every email address I happen to hand 
out. As is the case so many time, one size does not fit all. ;)




It is true, but in this situation you are not really using chkuser, as 
any recipient is accepted for your domain.
You (system manager) may change badmailfrom, but normal users or 
qmailadmin administrators cannot.
As conseguence, all spam messages become real traffic instead of being 
stopped at SMTP level.


I didn't mean to suggest using a catchall account was a good solution 
to this problem, only a quick and dirty workaround.



I suggest to create aliases if cases are a few, otherwise enable user
extensions.


I'm not seeing much of a down side to enabling all 3 of these settings 
by default. What is the down side in your view? I'm inclined to change 
the QMT default configuration to allow all 3 by default, which brings 
QMT in line with qmail's default behavior. However I certainly 
wouldn't do this without consulting you, as well as anyone else who'd 
like to chime in on this.




It is pretty normal to enable all three

Re: [qmailtoaster] Re: chkuser rejecting mail to users with hyphens

[Tonix (Antonio Nati)]

Il 05/03/2012 21:04, Eric Shubert ha scritto:

On 03/05/2012 12:37 PM, Tonix (Antonio Nati) wrote:

Il 05/03/2012 20:10, Eric Shubert ha scritto:

On 03/05/2012 11:47 AM, Tonix (Antonio Nati) wrote:

Il 05/03/2012 19:28, Eric Shubert ha scritto:

I'm not so sure of this, Tonino. I have the latest qmail-toaster
package installed, which does not have 
CHKUSER_ENABLE_USERS_EXTENSIONS
enabled (it's still commented out). I just ran a test, and when I 
sent

from eric@ to eric-test@ it works fine.

What am I missing?


are eric and eric-test two different accounts? If yes, it is ok.


No.


Extensions are native qmail extensions to single accounts. So eric
account will receive also messages for eric-trial, eric-lab, and so 
on.


Right.


I was just wondering if, given the names used, that was the case.


Correct. This is what's happening on my system, as it should.



But now I'm in confusion.


At least we're together in that aspect. ;)


Did you send to eric-test using the submission port without chkuser, or
using the public MX with chkuser?


Submission port, but with chkuser enabled. It was an authenticated 
session.


I just did a 2nd test from an external source (yahoo), and eric-test@ 
(no account by that name) is delivered to the eric@ account. As it 
should be.




I've made some telnets to your email server, and it looks like accepting 
all for @yourdomain.

Is bouncing enabled?

Tonino



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: chkuser rejecting mail to users with hyphens

[Tonix (Antonio Nati)]

Il 06/03/2012 16:28, Eric Shubert ha scritto:

On 03/06/2012 07:40 AM, Tonix (Antonio Nati) wrote:

I've made some telnets to your email server, and it looks like accepting
all for @yourdomain.
Is bouncing enabled?


No, I have a catchall account defined. That account is different than 
the eric-test account I was using.


Perhaps you're on to something though.

catchall account disables chkuser checking, as it receives emails for 
not existing recipients.


Regards,

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: chkuser rejecting mail to users with hyphens

[Tonix (Antonio Nati)]

Il 06/03/2012 16:47, Tonix (Antonio Nati) ha scritto:

Il 06/03/2012 16:28, Eric Shubert ha scritto:

On 03/06/2012 07:40 AM, Tonix (Antonio Nati) wrote:
I've made some telnets to your email server, and it looks like 
accepting

all for @yourdomain.
Is bouncing enabled?


No, I have a catchall account defined. That account is different than 
the eric-test account I was using.


Perhaps you're on to something though.

catchall account disables chkuser checking, as it receives emails for 
not existing recipients.


of course not all checking is disabled, only recipients.

Tonino



Regards,

Tonino


--

 Inter@zioniInterazioni di Antonio Nati
http://www.interazioni.it   to...@interazioni.it




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: chkuser rejecting mail to users with hyphens

[Tonix (Antonio Nati)]

Il 06/03/2012 18:29, Eric Shubert ha scritto:

On 03/06/2012 08:57 AM, Tonix (Antonio Nati) wrote:

Il 06/03/2012 16:47, Tonix (Antonio Nati) ha scritto:

Il 06/03/2012 16:28, Eric Shubert ha scritto:

On 03/06/2012 07:40 AM, Tonix (Antonio Nati) wrote:

I've made some telnets to your email server, and it looks like
accepting
all for @yourdomain.
Is bouncing enabled?


No, I have a catchall account defined. That account is different than
the eric-test account I was using.

Perhaps you're on to something though.


catchall account disables chkuser checking, as it receives emails for
not existing recipients.


of course not all checking is disabled, only recipients.

Tonino



That explains things.



:-). We are not crazy, finally.


Would you suggest we be using the
#define CHKUSER_ENABLE_USERS_EXTENSIONS
by default? It seems to me we should, as the -anything extension is 
a standard part of qmail (unless I'm mistaken). If we should, can it 
be enabled with an environment variable, or is it strictly a #define 
setting?




Extensions  are used for TMDA (I don't know if it is still used), ezml 
maling lists, mailman lists, user extensions.


chkuser has different options:
- user extensions
- mailman lists
- ezmlm lists

you do not need user extension if you are in normal situations (I have 
only ezmlm lists enabled).


You need the user extension if you use TMDA or in cases in which you 
want to receive extensions.
In this case, chkuser checks for recipient existance, and if fails tries 
again shifting towards left (using '-' as token to search).


With ezmlm and mailman lists enabled, it checks if recipient is 
associated to a ezmlm/mailman list, and in such a case it accepts 
extensions for that recipient.



If I understand correctly, applying this setting would fix Russ's 
problem. Or I suppose he could set a catchall account. Correct?




catchall is to be avoided if possible, as it accept always any recipient 
and does not give any advantage to traffic/workload.
It should be used when you setup a new domain (coming from another ISP) 
on which you don't know which accounts exist. So, for some time, you 
accept all recipients and create accounts as you understand which 
accounts are needed. At end of all you kill the catchall feauture and 
enable 'bouncing'.


I suggest to create aliases if cases are a few, otherwise enable user 
extensions.


Hope this helps!


Thanks.




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] chkuser rejecting mail to users with hyphens

[Tonix (Antonio Nati)]

It looks like you have names extensions on (like accepting 
russ-*@tidewins.com).


If true, you must enable in chkuser_settings.h 
CHKUSER_ENABLE_USERS_EXTENSIONS.


Regards,

Tonino


On 3/3/2012 10:13 AM, Russ Goodwin wrote:

Hi-

I just upgraded our QMT install using the qtp-newmodel script and 
found that mail to users' virtual addresses (e.g. 
russ-t...@tidewinds.com) is getting rejected with the following message:

SMTP error from remote mail server after RCPT TO:russ-t...@tidewinds.com  
https://webmail.tidewinds.com/webmail/src/compose.php?send_to=russ-treg%40tidewinds.com:
 host mail.tidewinds.com [63.251.133.5]: 550 5.1.1 sorry, no mailbox here 
by that
name (chkuser)
Mail sent to my actual mailbox (r...@tidewinds.com) goes through just 
fine.


I'm looking around but can't tell what needs to change to bring this 
functionality back.  Any pointers would be greatly appreciated!


Thanks.

-Russ




--

IT4SOHO, LLC
PO Box 507
St. Petersburg, FL 33731-0507

CALL TOLL FREE:
   877-IT4SOHO

We have support plans for QMail!




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: qmail-toaster-1.03-1.3.21 now available

[Tonix (Antonio Nati)]

Errata corrige!

Il 05/03/2012 19:18, Tonix (Antonio Nati) ha scritto:

Il 05/03/2012 19:03, Eric Shubert ha scritto:

Sometimes you guys make me crazy.

This version of qmail-toaster fixes the problems we've had in the 
past with special characters in email addresses. If you upgrade to 
this version, you should be fine with leaving chkuser enabled.


At some point in the future we may set up separate tcp.smtp file for 
submissions which will have chkuser disabled, which I believe is what 
Tonino (the chkuser author) recently recommended in another thread. 
IOW, use chkuser for inbound messages, but not submissions.



I confirm, but not for chkuser problems.
SMTP is a server protocol, and some email clients do no manage 
correctly errors due to not existing recipients or other errors in 
acceptance phase, so it is better to accept always those messages, and 
send back later error messages. In this way some clients, which 
actually stop any sending if one recipients does not exist, will send 
all messages with no problems, and will receive a message back for any 
error.



While it would be nice if spamdyke were to disable spamdyke for 
authenticated users, this is technically not possible (environment 
variables cannot be changed once a process has started).




Every possible feature has been implemented as patch or pipe to qmail, 
*now* it is time to improve directly qmail.


Regards,

Tonino





--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: chkuser rejecting mail to users with hyphens

[Tonix (Antonio Nati)]

Il 05/03/2012 19:28, Eric Shubert ha scritto:
I'm not so sure of this, Tonino. I have the latest qmail-toaster 
package installed, which does not have CHKUSER_ENABLE_USERS_EXTENSIONS 
enabled (it's still commented out). I just ran a test, and when I sent 
from eric@ to eric-test@ it works fine.


What am I missing?


are eric and eric-test two different accounts? If yes, it is ok.

Extensions are native qmail extensions to single accounts. So eric 
account will receive also messages for eric-trial, eric-lab, and so on.


I was just wondering if, given the names used, that was the case.

Regards,

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: chkuser rejecting mail to users with hyphens

[Tonix (Antonio Nati)]

Il 05/03/2012 20:10, Eric Shubert ha scritto:

On 03/05/2012 11:47 AM, Tonix (Antonio Nati) wrote:

Il 05/03/2012 19:28, Eric Shubert ha scritto:

I'm not so sure of this, Tonino. I have the latest qmail-toaster
package installed, which does not have CHKUSER_ENABLE_USERS_EXTENSIONS
enabled (it's still commented out). I just ran a test, and when I sent
from eric@ to eric-test@ it works fine.

What am I missing?


are eric and eric-test two different accounts? If yes, it is ok.


No.


Extensions are native qmail extensions to single accounts. So eric
account will receive also messages for eric-trial, eric-lab, and so on.


Right.


I was just wondering if, given the names used, that was the case.


Correct. This is what's happening on my system, as it should.



But now I'm in confusion.
Did you send to eric-test using the submission port without chkuser, or 
using the public MX with chkuser?


If chkuser is enabled, and CHKUSER_ENABLE_USERS_EXTENSIONS is commented, 
eric-test should be bounced by chkuser.


Regards,

Tonino

I believe that Russ's problem is that this should be happening but is 
not.





--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Per Session Limit Question

[Tonix (Antonio Nati)]

Il 24/02/2012 21:03, Eric Shubert ha scritto:

On 02/24/2012 12:24 PM, Joel Eddy wrote:

That's kinda what I figured it did. Just wasn't 100% on that decision.
Thanks for the info.
I think what's happening is the client uses Peachtree accounting to send
invoices. And from what
I remember of Peachtree is it sends the invoice to the email client  of
choice and sends through it.
Since the client uses Outlook 2007 I'm thinking it isn't sending the 
message

right away. Instead I think it probably
Cues the message in Outlook until you hit send and receive. If that's 
the

case, and I believe that is the default
for Outlook it could very well be holding a rather large number of 
messages

to send.

Hence, causing the per session limit pop up. I've got to go over to the
clients place of business and check that
to know for sure however.



That's a good possibility. I can't honestly say if Outlook (any 
version) uses a separate session for each messages or not, but I would 
guess that it likely sends them all in a single smtp session. No 
reason not to that I can see. What I said earlier about this is 
probably wrong.




I do know that Outlook doesn't leave an smtp session going continually 
though. That would eventually time out. However, if a slew of messages 
were waiting to go out, as in the case where Outlook was offline for a 
period of time, they could all be sent in a single smtp session. 
If/when this happens, I honestly don't know what chkuser would do. I 
expect that it would apply the limits to each messages individually, 
but I'm not certain of that. Tonino?


It is per TCP session. It means when several messages are sent in 
different message sessions but within a unique SMTP connection, limit is 
global.


I planned to make it become per message session, but honestly in years 
I've received no complains, so I'm uncertain if to make it.


I suggest to keep this tarpitting action only on public MX, disabling it 
on server used for authenticated relaying.


Let me repeat again: public and relay servers must be different 
(different IP or different ports), mainly because many email lients do 
not handle error messages, so I enable chkuser on public MX, and disable 
chkuser on authenticated relay servers, where users get back messages of 
not existing (local) users from qmail.


Regards,

Tonino





Generally speaking, I'm not aware of any limits that are placed on 
multiple messages in a single smtp session. This doesn't mean that 
there aren't any though.


Sorry for the disinformation earlier. Please keep us posted.




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Per Session Limit Question

[Tonix (Antonio Nati)]

Il 23/02/2012 19:35, Eric Shubert ha scritto:

On 02/23/2012 11:17 AM, Joel Eddy wrote:

As an example the client has a group that is mailed to. The group has 62
addresses. When the client tries to send to that group the per 
session limit

pops up.

My first reaction was that it's a Norton Issue as well. But I don't 
know of

anywhere in Norton AV that sets a limit.

Joel


Your best option is probably to use an ezmlm list. The user should be 
able to manage this on their own once you show them the ropes.


If you really need to bump the limit to 65 or so, I would suggest 
creating a separate tcp.smtp file for submissions, and simply change 
the limit there. This way you're not exposing all of your inbound 
messages to the upper limit, and only authenticated sessions get the 
new limit. Of course, the user should be using port 587 for sending.


FWIW, QMT *may* have a separate tcp.smtp file in some future release. 
I think this simply makes sense.



I agree with Eric.
If you can have separate servers, I suggest to use this limit on public 
MX, and not to have this limit on RELAY smtp (for authenticated users).


Regards,
Tonino

--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Authentication methods

[Tonix (Antonio Nati)]

My point of view is related to extra QMT features, so it could be out of 
topic.


We are willing to integrate some assistance trouble ticketing and/or 
other web services for e-mail users, so we plan to use the same vpopmail 
auth table also for other external packages.
From this point of view, a clear text password column is needed, as we 
don't know which kind of auth is needed outside.


Probably, this column should be hidden for any vpopmail function, except 
setting a new password. We are thinking if/how enable this column only 
using a MySQL stored procedure... but this is behind this topic!


Regards,

Tonino



Il 15/02/2012 18:26, Eric Shubert ha scritto:
As part of the upgrade to vpopmail, we're considering removing clear 
text passwords from the database. This will improve security, but at 
the same time remove some (somewhat insecure) capabilitiy.


The biggest impact I think this will have is that admins will no 
longer be able to look up someone's password. In the event that a user 
loses their password, the administrator would reset the password to 
something temporary, and the user would subsequently change it to 
whatever they like. This is the practice followed in many (if not 
most) other environments.


The other impact will be the elimination of cram-md5 as an 
authentication option. While this doesn't really make QMT any less 
secure, it might mean that some clients that were formerly configured 
to use cram-md5 would fail to work until their configuration options 
were changed.


I honestly do not have a good feel for which or how many devices may 
be using cram-md5. There's also a chance that there exists some older 
devices (old Nokia phones perhaps?) that use cram-md5 and are unable 
to use TLS/SSL. I do doubt that such devices exist, but there's always 
that possibility.


In any case, I think it would be prudent for QMT to provide SMTPS 
(port 465) before or at the same time that cram-md5 support is 
removed. This is something we've talked about already, so assume that 
there will be SMTPS capability should cram-md5 (and clear text 
passwords) be removed.


That's all I have on this at the moment. Any thoughts?
shubes ducks




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Authentication methods

[Tonix (Antonio Nati)]

Il 16/02/2012 13:45, Bharath Chari ha scritto:

On Thursday 16 February 2012 05:42 PM, Tonix (Antonio Nati) wrote:
My point of view is related to extra QMT features, so it could be out 
of topic.


We are willing to integrate some assistance trouble ticketing and/or 
other web services for e-mail users, so we plan to use the same 
vpopmail auth table also for other external packages.
From this point of view, a clear text password column is needed, as 
we don't know which kind of auth is needed outside.
I think that the MySQL implementation of vpopmail is unique in that it 
allows for storing clear text passwords. I run other mail systems 
which use Postfix/Dovecot with a mysql backend. Almost all of them DO 
NOT display/store clear text passwords. The commonly used encryptions 
are crypt, sha1 and md5, AFAIK, and most CRM packages do support them.



I used Radius in the past, for giving PSTN access to email users, and it 
wants clear passwords.
The same if you want particular kinds of authentication: send md5 of 
(password + time string), you need clear password to check result.


Regards,

Tonino




Bharath

- 

Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and 
installations.

 If you need professional help with your setup, contact them today!
- 

Please visit qmailtoaster.com for the latest news, updates, and 
packages.
 To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com







--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Migrating to new server

[Tonix (Antonio Nati)]

Il 06/02/2012 18:49, Eric Shubert ha scritto:

On 02/06/2012 10:21 AM, John Raley wrote:

One of my clients is moving from a Qmailtoaster server (setup by me) to
Exchange 2010 and has tasked me to perform the migration for them. The
problem I am having is that I have to manually change their Outlook
settings in order to switch them to their Exchange accounts. I need to
move the users over in groups and only a few at a time. I have tried
deleting their accounts on the Qmail server and their new emails show up
on their Exchange account.


How did you manage this?


The problem I have is that users still on the
Qmail server cannot send email to users that have already moved to the
Exchange server and vice versa.

Thoughts or suggestions on how to accomplish this?


I don't know of a way for a single domain to be split across two 
servers. Other than creating a subdomain to act as a bridge between 
the two servers (which I'm not entirely sure how that would work), I 
think your best approach is probably to get all the accounts over to 
Exchange asap.


I think it should work if you could use two subdomains.
- sub1 on qmail
- sub2 on exchange

alias sub1 to domain.com on qmail
alias sub2 to domain.com on exchange

any account moved away from qmail should still exist on qmail, with a 
forward - same_acco...@sub2.domain.com
any account still working on qmail should have a forward on exchange - 
acco...@sub1.domain.com (if you can tell exchange to send mail for 
unkown recipients of domain to qmail you can avoid these forwards).


Regards,

Tonino






You have my sympathies.




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Hypervisor recommendations for virtualizing QMT

[Tonix (Antonio Nati)]

If you speak about Linux preferences, I don't know... We use FreeBSD.
If you speak about the best virtual environment, no doubt... VMware.

Stable, stable, stable... Indipendent from OS... No need to have custom 
kernels.


We use VMware, hosting FreeBSD, Linux, Windows... every version of them 
can run, despite of kernel or age.
And with FreeBSD we are using jails, so we have jails within virtual 
machines... for us is the best solution.


For us (for others can be different).

Regards,

Tonino


Il 28/01/2012 00:08, Eric Shubert ha scritto:

On 01/27/2012 03:53 PM, Dan McAllister wrote:

To be honest, this is akin to asking which Linux Distro is best... ask
100 people, and get 102 different answers!

I used Xen in CentOS 5, and now use KVM in CentOS 6 (yes, I like CentOS
better than the more popular Debian-based distros).

I found little difficulty in migrating from my knowledge of Xen to
getting some knowledge about KVM. I've been quite happy with both, and
even successfully migrated a hosted Windows 2003 client from an older
Xen host to a newer KVM one (with faster networking too!). In fact, I
found the CLI interface for managing clients easier in KVM than I did
with Xen... a big plus for me, as I tend to prefer a non-GUI server 
install!


I suspect there will be some performance preferences for one or the
other (and my understanding is that Xen has gained entrance to the base
kernel, so KVM is no longer the only kernel-based VM option).

Just my thoughts... they're as personal (and unique) as any of the 
others...


Dan
IT4SOHO



Thanks for sharing that Dan. I think you're right on target.

I'm in the process of migrating to (and learning) KVM from VMware 
Server2. While I don't necessarily follow the crowd, I do tend to 
apply the saying When in Rome  ;)





--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: how to SMTPS submission/port 587

[Tonix (Antonio Nati)]

There is something I don't understand.

An autenticated user, using relay, has no spam control, no grey list, as 
he is already authenticated. Only antivirus check.
If the same user wants to send using MX, he gots spam control, grey 
list, etc...


So, which is the advantage of using public mx?
public mx is the most controlled I don't understand which a user 
should have adavantage using it.


Tonino

Il 21/01/2012 03:19, Michael J. Colvin ha scritto:

If I understand you correctly though  If I was clever enough of a user
to figure out the IP of your incoming e-mail server, either on purpose or
simply by accident, I could user port 25, authenticate, and send mail...
Now, this isn't a big deal, I understand, but it provides the opportunity
for someone to circumvent (Either intentionally or by accident) what the
original poster was trying to block.

Mike


-Original Message-
From: Tonix (Antonio Nati) [mailto:to...@interazioni.it]
Sent: Friday, January 20, 2012 5:11 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] Re: how to SMTPS submission/port 587

Il 21/01/2012 01:39, Eric Shubert ha scritto:

On 01/20/2012 01:07 PM, Michael J. Colvin wrote:

I believe you could use SpamDyke to block your users from sending

via

port
25...  You could block via the domain name, you could block by IP
address
and rDNS, assuming your users have specific IP's (Or range of IP's)
or rDNS
information...  You could do all three too...  Or does

authentication

bypass
SpamDyke?  I forget.

Authenticated connections bypass all filters. Sorry. ;)


If it does, set up two servers...  One for incoming mail, one for
outgoing
mail.  Turn port 25 off on the outbound server, forcing users to use
a port
that's active, like 587.  Inbound mail will come in via port 25 from
outside
mail servers, use smtproutes to forward it to your inside mail
server via
port 587, use SpamDyke to block your users' domain's in the From

field

(Works great for stopping a lot of SPAM too!) and then remove the
ability to
authenticate on 25 (No e-mail addresses on the server)...  If server
count
is an issue, use a VM and put both servers on one physical server...

Mike


This took me a couple reads, but you know what? I think I get it, and
I kinda like it! :)

This definitely deserves to be hashed around a bit. Having 2 separate
(QMT) hosts, one for outbound (submission) and one for inbound (smtp)
makes some sense, if for no other reason than it's simply logical.

One of QMT's weaknesses in the past has been that everything is
tightly wound and interdependent, aka highly coupled (as we used to
say about modules in structured programs). This is clearly a place
where roles can, and probably should be delineated. Along the same
lines as MUA, MSA, MTA, MDA. (see Nov'07 RFC5068 entitled Best
Current Practice - Email Submission:
http://tools.ietf.org/html/rfc5068)

While I was looking for that RFC specifically, I came across this

one:

http://tools.ietf.org/html/rfc6409 from Nov'11. It's not easy keeping
up with the times. :) I still need to read this one, but I'll go

ahead

and post this reply for the time being.

If you have a thought or idea you'd like to share about this, please
chime in!

Eric, while I like this model (and we are already using it), I don't
understand the request originatin this thread.

We simply told our customers which address they could use for relaying
(relay.yourdomain.com), with no antispam, and they all are using this
relay, with their internal communication faster and trouble free.

Probably our success point is we are using two different IP addresses
for this purpose:
- we receive mx on mx.yourdomain.com (free), port 25
- we accept relaying on relay.yourdomain.com (must auth), ports 25 and
587

Probably having two different addresses is much better then simply
using
different ports.
Just tell your customers which address must be used for relaying, and
use an mx name without telling them.

Regards,

Tonino






Thanks.



--

  Inter@zioniInterazioni di Antonio Nati
 http://www.interazioni.it  to...@interazioni.it



---
--
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
 Vickers Consulting Group offers Qmailtoaster support and
installations.
   If you need professional help with your setup, contact them
today!
---
--
  Please visit qmailtoaster.com for the latest news, updates, and
packages.

   To unsubscribe, e-mail: qmailtoaster-list-
unsubscr...@qmailtoaster.com
  For additional commands, e-mail: qmailtoaster-list-
h...@qmailtoaster.com




-
Qmailtoaster

Re: [qmailtoaster] Re: how to SMTPS submission/port 587

[Tonix (Antonio Nati)]

Correction: :-)
I don't understand *why* a user should have adavantage using it.

Tonino

Il 21/01/2012 12:08, Tonix (Antonio Nati) ha scritto:

There is something I don't understand.

An autenticated user, using relay, has no spam control, no grey list, 
as he is already authenticated. Only antivirus check.
If the same user wants to send using MX, he gots spam control, grey 
list, etc...


So, which is the advantage of using public mx?
public mx is the most controlled I don't understand which a user 
should have adavantage using it.


Tonino

Il 21/01/2012 03:19, Michael J. Colvin ha scritto:
If I understand you correctly though  If I was clever enough of a 
user
to figure out the IP of your incoming e-mail server, either on 
purpose or

simply by accident, I could user port 25, authenticate, and send mail...
Now, this isn't a big deal, I understand, but it provides the 
opportunity

for someone to circumvent (Either intentionally or by accident) what the
original poster was trying to block.

Mike


-Original Message-
From: Tonix (Antonio Nati) [mailto:to...@interazioni.it]
Sent: Friday, January 20, 2012 5:11 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] Re: how to SMTPS submission/port 587

Il 21/01/2012 01:39, Eric Shubert ha scritto:

On 01/20/2012 01:07 PM, Michael J. Colvin wrote:

I believe you could use SpamDyke to block your users from sending

via

port
25...  You could block via the domain name, you could block by IP
address
and rDNS, assuming your users have specific IP's (Or range of IP's)
or rDNS
information...  You could do all three too...  Or does

authentication

bypass
SpamDyke?  I forget.

Authenticated connections bypass all filters. Sorry. ;)


If it does, set up two servers...  One for incoming mail, one for
outgoing
mail.  Turn port 25 off on the outbound server, forcing users to use
a port
that's active, like 587.  Inbound mail will come in via port 25 from
outside
mail servers, use smtproutes to forward it to your inside mail
server via
port 587, use SpamDyke to block your users' domain's in the From

field

(Works great for stopping a lot of SPAM too!) and then remove the
ability to
authenticate on 25 (No e-mail addresses on the server)...  If server
count
is an issue, use a VM and put both servers on one physical server...

Mike


This took me a couple reads, but you know what? I think I get it, and
I kinda like it! :)

This definitely deserves to be hashed around a bit. Having 2 separate
(QMT) hosts, one for outbound (submission) and one for inbound (smtp)
makes some sense, if for no other reason than it's simply logical.

One of QMT's weaknesses in the past has been that everything is
tightly wound and interdependent, aka highly coupled (as we used to
say about modules in structured programs). This is clearly a place
where roles can, and probably should be delineated. Along the same
lines as MUA, MSA, MTA, MDA. (see Nov'07 RFC5068 entitled Best
Current Practice - Email Submission:
http://tools.ietf.org/html/rfc5068)

While I was looking for that RFC specifically, I came across this

one:

http://tools.ietf.org/html/rfc6409 from Nov'11. It's not easy keeping
up with the times. :) I still need to read this one, but I'll go

ahead

and post this reply for the time being.

If you have a thought or idea you'd like to share about this, please
chime in!

Eric, while I like this model (and we are already using it), I don't
understand the request originatin this thread.

We simply told our customers which address they could use for relaying
(relay.yourdomain.com), with no antispam, and they all are using this
relay, with their internal communication faster and trouble free.

Probably our success point is we are using two different IP addresses
for this purpose:
- we receive mx on mx.yourdomain.com (free), port 25
- we accept relaying on relay.yourdomain.com (must auth), ports 25 and
587

Probably having two different addresses is much better then simply
using
different ports.
Just tell your customers which address must be used for relaying, and
use an mx name without telling them.

Regards,

Tonino






Thanks.



--

  Inter@zioniInterazioni di Antonio Nati
 http://www.interazioni.it  to...@interazioni.it



---
--
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
 Vickers Consulting Group offers Qmailtoaster support and
installations.
   If you need professional help with your setup, contact them
today!
---
--
  Please visit qmailtoaster.com for the latest news, updates, and
packages.

   To unsubscribe, e-mail: qmailtoaster-list-
unsubscr...@qmailtoaster.com
  For additional commands, e-mail

Re: [qmailtoaster] how to SMTPS submission/port 587

[Tonix (Antonio Nati)]

You can lock port 25 to your users only if you can control their network.

If they come from external networks you can't control if they use port 
25 (without authentication) for delivering to your domains.


Correct usage of port 25 should be forced by access providers, which 
should deny any outgoing connection to external ports 25.
Any network should allow own users to use port 25/465/587, while access 
to external ports 25 should be permitted only to SMTP servers.


But this is a self limitation which is not very used.

Regards,

Tonino



Il 20/01/2012 20:02, Kalil Costa - Brasilsite ha scritto:


Thks Dan,




I understand completely, I think I'll work with 465.


And how to lock my users for doesn't to use port 25 ? I want to 
receive only external mails in port 25 and my clients to use port 465. 
Is it the correct way ?




thks again Dan.






Em 20-01-2012 15:41, Dan McAllister escreveu:

Kalil (aka: Kalz):

Port 587 ususlly does NOT force the use of SSL/TLS -- the port is 
defined as a submission port and is most often used as a 
replacement for SMTP in environments that otherwise BLOCK port 25 
access (like some ISPs do -- allowing port 25 ONLY to their own SMTP 
servers and/or relays).


There is another port - 465 - that is another well-known port defined 
as SMTPS whose specifications match what you want: a port that only 
allows SSL/TLS connections.


OK, that part out of the way, here's how you add one or the other 
(NOTE: I take some shortcuts here -- like using tar pipes -- that 
some may object to... all I can say is that it works!)


Step 1:  Create the supervise folders to make qmail listen on the 
additional ports

 a) CD to the supervise folder
*  cd /var/qmail/supervise*
 b) copy the smtp directory tree into a new tree called submission 
(for port 587) and then another called smtp-ssl (for port 465)

*  for DIR in submission smtp-ssl ; do
mkdir $DIR
chown qmaill:qmail $DIR
chmod 1700 $DIR
tar cvf - -C smtp . | tar xvf - -C $DIR
  done*
 c) Modify the *run* scripts in the new folders as below
 In the SUBMISSION folder:
BEFORE the exec line at the bottom, add (or modify if they 
already exist) the lines:

*  export REQUIRE_AUTH=1
  export SMTPS=0
*ON the exec line at the bottom, change the *25 *(should be right 
after a 0) to *587*

  Notes:
1) the exec line usually has continuation marks (line 
ends with a \) -- this makes the last several ACTUAL lines one 
VIRTUAL line (and improves readability)
2) your installation MAY use a variable (e.g.: USEPORT) 
-- if so, look for the line above that ends in *=25* and change 
that one!

 In the SMTPS folder:
BEFORE the exec line at the bottom, add (or modify if they 
already exist) the lines:

*  export REQUIRE_AUTH=1
  export SMTPS=1
*ON the exec line at the bottom, change the *25 *(should be right 
after a 0) to *465*

  Notes:
1) the exec line usually has continuation marks (line 
ends with a \) -- this makes the last several ACTUAL lines one 
VIRTUAL line (and improves readability)
2) your installation MAY use a variable (e.g.: USEPORT) 
-- if so, look for the line above that ends in *=25* and change 
that one!

 d) OPTIONALLY:
  If you're UNLIKE like me and you trust users NOT to be the 
SOURCE of SPAM, then you can remove any SPAMDYKE or SPAMASSASSIN 
processing you may have configured for your standard (open) SMTP port


I hope this helps!

Dan McAllister
IT4SOHO



On 1/20/2012 12:09 PM, Kalil Costa - Brasilsite wrote:

Guys,



How to configure my qmailtoaster to use port 587 SMTPS Submission 
for my clients and port 25 for other servers from internet ?   Some 
like this




--CLIENTS- port smtp/587- **

*  SERVER  *

--OTHER INTERNET MAIL SERVERS --- port 25--- * QMAILTOASTER *

*   *

--CLIENTS - port 25 ***BLOCKED******



Thanks for help


Kalz

- 
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com) Vickers Consulting Group offers 
Qmailtoaster support and installations. If you need professional 
help with your setup, contact them today! 
- 
Please visit qmailtoaster.com for the latest news, updates, and 
packages. To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com For additional 
commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com 
- 
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com) Vickers Consulting Group 

Re: [qmailtoaster] Re: how to SMTPS submission/port 587

[Tonix (Antonio Nati)]

Il 20/01/2012 23:14, Eric Shubert ha scritto:


I think Tonino's post earlier was right on. Perhaps his spanish is 
better than mine. ;) ?




Your spanish is bad because the link is ... Portuguese :-)

Regards,

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: how to SMTPS submission/port 587

[Tonix (Antonio Nati)]

Il 21/01/2012 01:39, Eric Shubert ha scritto:

On 01/20/2012 01:07 PM, Michael J. Colvin wrote:
I believe you could use SpamDyke to block your users from sending via 
port
25...  You could block via the domain name, you could block by IP 
address
and rDNS, assuming your users have specific IP's (Or range of IP's) 
or rDNS
information...  You could do all three too...  Or does authentication 
bypass

SpamDyke?  I forget.


Authenticated connections bypass all filters. Sorry. ;)

If it does, set up two servers...  One for incoming mail, one for 
outgoing
mail.  Turn port 25 off on the outbound server, forcing users to use 
a port
that's active, like 587.  Inbound mail will come in via port 25 from 
outside
mail servers, use smtproutes to forward it to your inside mail 
server via

port 587, use SpamDyke to block your users' domain's in the From field
(Works great for stopping a lot of SPAM too!) and then remove the 
ability to
authenticate on 25 (No e-mail addresses on the server)...  If server 
count

is an issue, use a VM and put both servers on one physical server...

Mike



This took me a couple reads, but you know what? I think I get it, and 
I kinda like it! :)


This definitely deserves to be hashed around a bit. Having 2 separate 
(QMT) hosts, one for outbound (submission) and one for inbound (smtp) 
makes some sense, if for no other reason than it's simply logical.


One of QMT's weaknesses in the past has been that everything is 
tightly wound and interdependent, aka highly coupled (as we used to 
say about modules in structured programs). This is clearly a place 
where roles can, and probably should be delineated. Along the same 
lines as MUA, MSA, MTA, MDA. (see Nov'07 RFC5068 entitled Best 
Current Practice - Email Submission:

http://tools.ietf.org/html/rfc5068)

While I was looking for that RFC specifically, I came across this one:
http://tools.ietf.org/html/rfc6409 from Nov'11. It's not easy keeping 
up with the times. :) I still need to read this one, but I'll go ahead 
and post this reply for the time being.


If you have a thought or idea you'd like to share about this, please 
chime in!


Eric, while I like this model (and we are already using it), I don't 
understand the request originatin this thread.


We simply told our customers which address they could use for relaying 
(relay.yourdomain.com), with no antispam, and they all are using this 
relay, with their internal communication faster and trouble free.


Probably our success point is we are using two different IP addresses 
for this purpose:

- we receive mx on mx.yourdomain.com (free), port 25
- we accept relaying on relay.yourdomain.com (must auth), ports 25 and 587

Probably having two different addresses is much better then simply using 
different ports.
Just tell your customers which address must be used for relaying, and 
use an mx name without telling them.


Regards,

Tonino







Thanks.




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Help I am sending Spam

[Tonix (Antonio Nati)]

Get one of the offending messages, study headers and examine which is 
the way message is entering the system.

Do you have any web site which could send a malformed form to qmail?

Tonino

Il 25/11/2011 09:45, Mike Canty ha scritto:

To all,
I have a Qmail-Toaster server that is sending SPAM messages.  They
are from anonymous@my.domain and all are going to mailboxes in Italy.  The
message is always the same, subject PostePay Aggiornamento and it is a
HTML based messages that is definently a Phishing message.

Every time we stop Qmail and then empty the queue using qmHandle, then
restart Qmail, a similar thing happens.  Around 200 or so messages arrive,
then the server starts sending out these phishing messages.

On the server (Centos 5.6) I have checked the following
Rootkits - with rkhunter
Viruses - Sophos (found 7 viruses and removed)
Checked all the Cron files for anything unusual
Changed all users passwords
SSH was already secured (different port, no root access, etc.) but changed
all settings and passwords.
Checked and attempted a number of things in tcp/smtp
Turned of all user machines on the network, no effect
Stopped httpd

Nothing worked

So, basically I am looking for assistance in how to get rid if this.

Cheers
Mike Canty




-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
 Vickers Consulting Group offers Qmailtoaster support and installations.
   If you need professional help with your setup, contact them today!
-
  Please visit qmailtoaster.com for the latest news, updates, and packages.

   To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
  For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com






--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] smtp very slow...

[Tonix (Antonio Nati)]

99% is DNS problem.

Among other checks, check you have -l 'whatevername' in your qmail-smtpd 
run command.


Regards,

Tonino


Il 16/11/2011 23:48, Christian Clemmen ha scritto:

Hi,

The email sending on my qmail toaster is very slow... when I troubleshoot using
telnet, I found
that  it takes more than 30 sec to get the message Welcome message 220
serve...

[root@hostname /]# telnet server.domain.com 25
Trying 111.111.111.111...
Connected to server.domain.com (111.111.111.111).
Escape character is '^]'.
220 server.domain.com - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP


How can I know/find what's wrong with the config?

Best Regards,
Christian



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
 Vickers Consulting Group offers Qmailtoaster support and installations.
   If you need professional help with your setup, contact them today!
-
  Please visit qmailtoaster.com for the latest news, updates, and packages.

   To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
  For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com






--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Relaying email from client email address but not on my server!

[Tonix (Antonio Nati)]

Remote sender is authenticathing using correct username/password (I 
suppose you use smtp auth).

So, it is enabled to send everywhere, not only to local addresses.

If it is someone who stole username/password, change password 
imemdiately, and communicate new password to real customer.


Regards,

Tonino

Il 14/11/2011 13:28, Tony White ha scritto:

Hello all,
  I am not understanding what is happening on my server.
A remote server is sending email using a clients email
address. Relaying is allowed as it is a valid email address
but it is not my server!
  How does this work? Anyone any ideas please? Id there
a cure?

Example
2011-11-14 23:22:24.504944500 tcpserver: ok 26024 
mail.ycs.com.au:111.223.234.146:25 :190.252.139.148::14472
2011-11-14 23:22:34.461779500 CHKUSER accepted sender: from 
cli...@ycs.com.au:cli...@ycs.com.au: remote 
ycs.com.au:unknown:190.252.139.148 rcpt  : sender accepted
2011-11-14 23:22:35.779762500 CHKUSER relaying rcpt: from 
cli...@ycs.com.au:cli...@ycs.com.au: remote ycs.com.au:unknown:190. 
252.139.148 rcpt uligr...@cintek.com : client allowed to relay
2011-11-14 23:22:35.779783500 policy_check: local cli...@ycs.com.au - 
remote uligr...@cintek.com (AUTHENTICATED SENDER)

2011-11-14 23:22:35.779825500 policy_check: policy allows transmission
2011-11-14 23:22:35.779876500 spamdyke[26024]: ALLOWED from: 
cli...@ycs.com.au to: uligr...@cintek.com origin_ip: 190.252.139.148  
origin_rdns: (unknown) auth: cli...@ycs.com.au encryption: (none)




thanks in advance...

Tony White

- 

Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and 
installations.

 If you need professional help with your setup, contact them today!
- 

Please visit qmailtoaster.com for the latest news, updates, and 
packages.
 To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com







--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: commercial ESP for forwarded SMTP?

[Tonix (Antonio Nati)]

Il 13/09/2011 04:12, Eric Shubert ha scritto:

On 09/12/2011 05:39 PM, Quinn Comendant wrote:
We'll be deploying a mail server on a Rackspace cloud server, and 
they suggested that because their offering is 'utility computing' the 
IP addresses included are dirty (in a blacklist kind of way) and we 
should use a commercial ESP such as SendGrid, PostMark, CritSend, 
CloudSMTP, or the like.


Has anybody done research in this field? Any favorites?

We'll just be forwarding our outgoing SMTP traffic to their service 
for its quality of deliverability. I doubt we'll use any of reporting 
features, or even SPF/DKIM.


Quinn



Will they give you an appropriate rDNS for it (the static address 
you'll have)? If so, I think I'd simply go through the motions to get 
it cleaned up where needed.




I agree with Eric, but be sure to have a subnet for you and not only one IP.
Some blacklists deny all class C or subnets if a lot of IP from that 
class makes spam.
So, if IPs upper and below you make spam, you could have troubles 
because of them.


It is not necessary, but may help!

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Re: databytes limit diferent by domain‏

[Tonix (Antonio Nati)]

Il 13/09/2011 16:13, Eric Shubert ha scritto:

On 09/13/2011 03:34 AM, teclas sorianat wrote:

Hi:

I'm new in this list, but not in the use of qmail.

My question is about the databytes file. The number writed in this file
is used for all the domains in the server, but I need a different limit
for domain.

Is it possible?

Thanks in advance

Antonio


According to the man page, qmail-smtpd honors not only the value in 
the file, but also a DATABYTES environment variable, which overrides 
the value in the file. This makes it easy to set a different limit for 
inbound vs outbound (port 587) messages. Setting it based on domain 
would be more difficult though, and I expect would require modifying 
the qmail-smtpd source code. Could be done though.




Yes, code should be modified, but it would work only if there are 
recipients to a single domain.
If a message has more recipients for different domains, you must apply a 
general databytes.



Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] CHKUSER invalid rcpt MX domain

[Tonix (Antonio Nati)]

Il 07/09/2011 23:07, Carlos Herrera Polo ha scritto:

I have a problem with chkuser when send email, please help

tcp.smtp file :

192.168.3.233:allow,RELAYCLIENT=,RBLSMTPD=,NOP0FCHECK=1,SENDER_NOCHECK=1


The log :

09-07 15:50:58 CHKUSER rejected rcpt: from 
sugar...@micorreo.com:t...@rem.com mailto:e...@rem.com: remote 
s02-sis:unknown:192.168.3.233 rcpt c...@micorreo.com 
mailto:c...@micorreo.com : invalid rcpt MX domain


micorreo.com http://micorreo.com is not a real domain...but in my 
smtproutes file I have:


micorreo.com:10.10.10.100:25

Can qmailtoaster  disable CHKUSER rcpt when the domain is in 
smtproute ??





I suppose this domain to be internal, and used only from internal users.
So you should disable chkuser for internal users.

Regards,

Tonino



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] CHKUSER invalid rcpt MX domain

[Tonix (Antonio Nati)]

Il 07/09/2011 23:19, Tonix (Antonio Nati) ha scritto:

Il 07/09/2011 23:07, Carlos Herrera Polo ha scritto:

I have a problem with chkuser when send email, please help

tcp.smtp file :

192.168.3.233:allow,RELAYCLIENT=,RBLSMTPD=,NOP0FCHECK=1,SENDER_NOCHECK=1


The log :

09-07 15:50:58 CHKUSER rejected rcpt: from 
sugar...@micorreo.com:t...@rem.com mailto:e...@rem.com: remote 
s02-sis:unknown:192.168.3.233 rcpt c...@micorreo.com 
mailto:c...@micorreo.com : invalid rcpt MX domain


micorreo.com http://micorreo.com is not a real domain...but in my 
smtproutes file I have:


micorreo.com:10.10.10.100:25

Can qmailtoaster  disable CHKUSER rcpt when the domain is in 
smtproute ??





I suppose this domain to be internal, and used only from internal users.
So you should disable chkuser for internal users.


So you should disable chkuser's checking for rcpt mx when accepting from 
internal users.

In such case (internal smtp server) I suggest to disable chkuser at all.

Regards,

Tonino



Regards,

Tonino



--

 Inter@zioniInterazioni di Antonio Nati
http://www.interazioni.it   to...@interazioni.it




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] 451 DNS Temporary Failure: Issue that should be addressed in CHKUSER

[Tonix (Antonio Nati)]

If your problem is only with squirrelmail, solution is simpler.
You can disable chkuser for every connection coming from 127.0.0.1 (or 
squirrelmail) IP, as users sending from squirrelmail are authenticated.


Regards,

Tonino

Il 01/09/2011 01:28, Tim Pleiman ha scritto:

Tonino,

Aha! Thanks for clarifying this:

Mail clients like Outlook stop at first error, so it is a client problem
to manage.

and

Instead, clients stop sometimes at first error and do not know how to
manage errors; a server manages a 451 error, retrying later, while a
client does not manage it at all.

Eric, Jake,

I just did some testing with SquirrelMail vs. the eGroupware webmail
client, and it turns out that the issue with the dumb 451 DNS Temporary
Failure error is unique to how SquirrelMail is handling the error
response from CHKUSER in an insufficient manner. SquirrelMail returns the
message with the base error only without returning any other
information--e.g. the message does not process and the error does not
include the e-mail address that has failed in the error message. That is a
problem with the SquirrelMail webmail client.

On the other hand, the eGroupware mail client, sending outbound via the
exact same QMT qmail server with CHKUSER_RCPT_MX enabled also fails to
send the message, BUT IT DOES return an informative error message that
actually indicates WHICH e-mail address has failed, even when sending to
more than one recipient. This then allows the sender to correct the
outbound recipient list and resend. This is desirable behavior.

OK, so since QMT installs with SquirrelMail as the default web client,
either the issue may need to be fixed at squirrelmail.org or there might
need to be some sort of notation in QMT docs that SquirrelMail does not
handle the SMTP server error responses adequately in the above regard
(alternatively users should turn off CHKUSER_RCPT_MX in the manner that is
scheduled to be released with QMTv2). I would have expected Outlook to be
non-compliant in such regaurd, but I hadn't thought this would be an issue
with SquirrelMail (which I've used for years). Apparently, it is. For
clients that don't process the error properly, users will need to be able
to turn off these features.

So, the problem here is definitely with SquirrelMail.

This has been an informative discussion. As it turns out, I'm migrating
all my users to eGroupware over the next 6 months, so this should become a
moot issue for me anyway, but perhaps this will be helpful for someone
else.

Thanks everyone!

Tim

On Wed, August 31, 2011 5:22 pm, Tonix (Antonio Nati) wrote:

Sorry, but your analisys is partially wrong.

When chkuser has a negative answer from DNS, it sends back:

*CHKUSER_RCPTMX_STRING* 2.0.5   defined 511 sorry, can't find 
a valid
MX for rcpt domain (#5.1.1 - chkuser)\r\n


or

*CHKUSER_SENDERMX_STRING*   2.0.5   defined 511 sorry, can't find a
valid MX for sender domain (#5.1.1 - chkuser)\r\n


This is a definitive NO to accepting single recipient, as a working DNS
said there is no MX for recipient domain (same mechanism for sender
check).

Only when there is NO answer from DNS, that means NO DNS server is
answering our questions, chkuser sends back messages you are reporting,
which tell remote system to try later.


But main problem is another: how clients manage errors coming from
servers.

SMTP is for servers mainly, not for clients.

Mail clients like Outlook stop at first error, so it is a client problem
to manage.

CHKUSER respects how smtp protocol works: for each recipient say OK or KO.

So:

 * ok, recipient exists
 * ko, recipients does not exist
 * ko, mailbox full
 * ok, relayed
 * ko, not relayed
 * ko, dns error
 * ko, mx not existing
 * etc

You may have the same problem for a mailbox full (one mailbox full in a
twenty recipients list), or similar problems.

Servers do not stop at any error, but continue sending each remaining
recipient, and then play accordingly to all status received for each
recipient.

Instead, clients stop sometimes at first error and do not know how to
manage errors; a server manages a 451 error, retrying later, while a
client does not manage it at all.

So, my suggested (and personal) solution is:

 *  public MX, where all errors are handled fully, with remote
   servers having full errors back immediately.
 *  dedicated relay server (on different IP or port), where auth
   users can send/relay: here the most of checks are disabled, so the
   server will accept anything, and then will send back detailed
   e-mails for errors on single deliveries.

You should have two different qmail-smtp process listening: one on port
25 for MX and one on submission port (587) for authenticated customers,
and two servers should act in different ways, as said before.

Actually I use these design:

 * public MX, accepting only to my domains, with full CHKUSER.
 * auth relay on different IP

[qmailtoaster] OFF Topic: egroupware vs simple-groupware

[Tonix (Antonio Nati)]

Tim,

did you try both products? Actually I did not, and would like someone 
could share his experience.


Tegards,

Tonino

Il 01/09/2011 01:28, Tim Pleiman ha scritto:

Tonino,

Aha! Thanks for clarifying this:

Mail clients like Outlook stop at first error, so it is a client problem
to manage.

and

Instead, clients stop sometimes at first error and do not know how to
manage errors; a server manages a 451 error, retrying later, while a
client does not manage it at all.

Eric, Jake,

I just did some testing with SquirrelMail vs. the eGroupware webmail
client, and it turns out that the issue with the dumb 451 DNS Temporary
Failure error is unique to how SquirrelMail is handling the error
response from CHKUSER in an insufficient manner. SquirrelMail returns the
message with the base error only without returning any other
information--e.g. the message does not process and the error does not
include the e-mail address that has failed in the error message. That is a
problem with the SquirrelMail webmail client.

On the other hand, the eGroupware mail client, sending outbound via the
exact same QMT qmail server with CHKUSER_RCPT_MX enabled also fails to
send the message, BUT IT DOES return an informative error message that
actually indicates WHICH e-mail address has failed, even when sending to
more than one recipient. This then allows the sender to correct the
outbound recipient list and resend. This is desirable behavior.

OK, so since QMT installs with SquirrelMail as the default web client,
either the issue may need to be fixed at squirrelmail.org or there might
need to be some sort of notation in QMT docs that SquirrelMail does not
handle the SMTP server error responses adequately in the above regard
(alternatively users should turn off CHKUSER_RCPT_MX in the manner that is
scheduled to be released with QMTv2). I would have expected Outlook to be
non-compliant in such regaurd, but I hadn't thought this would be an issue
with SquirrelMail (which I've used for years). Apparently, it is. For
clients that don't process the error properly, users will need to be able
to turn off these features.

So, the problem here is definitely with SquirrelMail.

This has been an informative discussion. As it turns out, I'm migrating
all my users to eGroupware over the next 6 months, so this should become a
moot issue for me anyway, but perhaps this will be helpful for someone
else.

Thanks everyone!

Tim

On Wed, August 31, 2011 5:22 pm, Tonix (Antonio Nati) wrote:

Sorry, but your analisys is partially wrong.

When chkuser has a negative answer from DNS, it sends back:

*CHKUSER_RCPTMX_STRING* 2.0.5   defined 511 sorry, can't find 
a valid
MX for rcpt domain (#5.1.1 - chkuser)\r\n


or

*CHKUSER_SENDERMX_STRING*   2.0.5   defined 511 sorry, can't find a
valid MX for sender domain (#5.1.1 - chkuser)\r\n


This is a definitive NO to accepting single recipient, as a working DNS
said there is no MX for recipient domain (same mechanism for sender
check).

Only when there is NO answer from DNS, that means NO DNS server is
answering our questions, chkuser sends back messages you are reporting,
which tell remote system to try later.


But main problem is another: how clients manage errors coming from
servers.

SMTP is for servers mainly, not for clients.

Mail clients like Outlook stop at first error, so it is a client problem
to manage.

CHKUSER respects how smtp protocol works: for each recipient say OK or KO.

So:

 * ok, recipient exists
 * ko, recipients does not exist
 * ko, mailbox full
 * ok, relayed
 * ko, not relayed
 * ko, dns error
 * ko, mx not existing
 * etc

You may have the same problem for a mailbox full (one mailbox full in a
twenty recipients list), or similar problems.

Servers do not stop at any error, but continue sending each remaining
recipient, and then play accordingly to all status received for each
recipient.

Instead, clients stop sometimes at first error and do not know how to
manage errors; a server manages a 451 error, retrying later, while a
client does not manage it at all.

So, my suggested (and personal) solution is:

 *  public MX, where all errors are handled fully, with remote
   servers having full errors back immediately.
 *  dedicated relay server (on different IP or port), where auth
   users can send/relay: here the most of checks are disabled, so the
   server will accept anything, and then will send back detailed
   e-mails for errors on single deliveries.

You should have two different qmail-smtp process listening: one on port
25 for MX and one on submission port (587) for authenticated customers,
and two servers should act in different ways, as said before.

Actually I use these design:

 * public MX, accepting only to my domains, with full CHKUSER.
 * auth relay on different IP, working both on port 25 and 587, with
   CHKUSER disabled.

About disabling chkuser, with version

Re: [qmailtoaster] 451 DNS Temporary Failure: Issue that should be addressed in CHKUSER

[Tonix (Antonio Nati)]

Sorry, but your analisys is partially wrong.

When chkuser has a negative answer from DNS, it sends back:

*CHKUSER_RCPTMX_STRING* 	2.0.5 	defined 	511 sorry, can't find a valid 
MX for rcpt domain (#5.1.1 - chkuser)\r\n



or

*CHKUSER_SENDERMX_STRING* 	2.0.5 	defined 	511 sorry, can't find a 
valid MX for sender domain (#5.1.1 - chkuser)\r\n



This is a definitive NO to accepting single recipient, as a working DNS 
said there is no MX for recipient domain (same mechanism for sender check).


Only when there is NO answer from DNS, that means NO DNS server is 
answering our questions, chkuser sends back messages you are reporting, 
which tell remote system to try later.



But main problem is another: how clients manage errors coming from servers.

SMTP is for servers mainly, not for clients.

Mail clients like Outlook stop at first error, so it is a client problem 
to manage.


CHKUSER respects how smtp protocol works: for each recipient say OK or KO.

So:

   * ok, recipient exists
   * ko, recipients does not exist
   * ko, mailbox full
   * ok, relayed
   * ko, not relayed
   * ko, dns error
   * ko, mx not existing
   * etc

You may have the same problem for a mailbox full (one mailbox full in a 
twenty recipients list), or similar problems.


Servers do not stop at any error, but continue sending each remaining 
recipient, and then play accordingly to all status received for each 
recipient.


Instead, clients stop sometimes at first error and do not know how to 
manage errors; a server manages a 451 error, retrying later, while a 
client does not manage it at all.


So, my suggested (and personal) solution is:

   *  public MX, where all errors are handled fully, with remote
 servers having full errors back immediately.
   *  dedicated relay server (on different IP or port), where auth
 users can send/relay: here the most of checks are disabled, so the
 server will accept anything, and then will send back detailed
 e-mails for errors on single deliveries.

You should have two different qmail-smtp process listening: one on port 
25 for MX and one on submission port (587) for authenticated customers, 
and two servers should act in different ways, as said before.


Actually I use these design:

   * public MX, accepting only to my domains, with full CHKUSER.
   * auth relay on different IP, working both on port 25 and 587, with
 CHKUSER disabled.

About disabling chkuser, with version 2.0.9 I suggest using

*CHKUSER_DISABLE_VARIABLE * 2.0.9   commented   CHKUSER_MUSTAUTH


and

*CHKUSER_EXTRA_MUSTAUTH_VARIABLE*   2.0.9   undefined   
CHKUSER_MUSTAUTH


for having a server accepting only authenticated users (any port or 
submission port).



For version 2.0.8 you may use (recompiling)  both:

*CHKUSER_SENDER_NOCHECK_VARIABLE *  2.0.5   commented   SENDER_NOCHECK


*CHKUSER_STARTING_VARIABLE* 2.0.5   commented   CHKUSER_START


Playing with those settings, you may enable or disable chkuser 
accordingly to variable settings.


For such scopes, I sugges not to put variables inside tcp.smtp, but 
directly within running command, because behaviour is per server and not 
per IP.


Regards,

Tonino



Il 31/08/2011 21:00, Tim Pleiman ha scritto:

Eric,

Over the last couple of years working with qmailtoaster, I've come to both
love and hate this particular CHKUSER check.

I keep copies of all the messages from the qmt list, and searching for the
string 451 DNS Temporary Problem, it seems to me that people have many
problems with it that could be addressed with some simple fixes to the
CHKUSR code--e.g. more detailed error responses from CHKUSER that better
define the nature of the problem.

Unlike the posts I've read over the last year or so, I'm not having any
trouble with my caching nameserver, DJBDNS. It's working properly, has
always been working properly. I love DJBDNS. However, here's the problem
that I have with this particular CHKUSER check:

When a sender tries to send a message to a single u...@domain.com, if
the domain MX is unresolveable in DNS as follows:

2011-08-31 12:56:25.14400 servfail nc-mail.nchicago.org. input/output
error

CHKUSR will return the 451 DNS Temporary Failure error indicative of the
issue. In this case today, the above particular domain has no MX record
for it's e-mail--their problem, not mine.

So, this immediately prevents queuing of messages in QMail that cannot
currently be delivered immediately to that one particular domain. This is
a good thing as it alerts the sender that the message cannot be delivered
now--e.g. QMail is not going to queue the message now because it would
just sit there, either waiting for the MX to become available or, if it
does not, bouncing the message after the queuelifetime expires.

Now, aside from the fact that the average person doesn't know what this
means, I can deal with it, albeit it is not ideal (the average user-sender
does not know what the heck 451 DNS Temporary Failure 

Re: [qmailtoaster] Re: Updated more info[Fwd: [qmailtoaster] 451 DNS Temporary Failure: Issue that should be addressed in CHKUSER]

[Tonix (Antonio Nati)]

Il 01/09/2011 00:15, Eric Shubert ha scritto:

On 08/31/2011 02:46 PM, Tim Pleiman wrote:

Is that this tcp.smtp rule?

SENDER_NOCHECK=1

It's possible that I may have dealt with this before on a different 
server

and have simply forgotten. I implemented the above setting on another
system due to some other similar issue as I recall. I'm thinking that 
the

above disables a bunch of different MX checks by CHKUSER, possibly
including this one.

However, is this the more specific rule?

CHKUSER_RCPT_MX=0


I think so. Tonino (the chkuser author, who hangs around here 
occasionally) can say for sure.


As said in other email, DNS is only one of things clients do not manage. 
Also full mailboxes or not existing (local) recipients can make problems.


I think the question should be:

MX: chkuser full on
ACCEPTING/RELAYING SERVER: chkuser off (except submission port feature - 
version 2.0.9)






I can't seem to find a list over at interazioni.it for all the tcp.smtp
rule settings.


I'm not quite clear on that either. They're not tcp.smtp rule settings 
so much as they are simply environment variables. They can be set in 
other places (think run file) as well, although that would be more 
global, and not IP specific as the tcp.smtp settings can be.


Tonino, can you clarify this please?


Exactly Eric, this are (usually) server behaviours, so should go in run 
commands (unless you are going to write them for any IP inside 
TCP.SMTP). Of course they can also be used for some senders IP, but I 
feel it a rare case.


Regards,

Tonino




These servers are all at CHKUSER 2.0.8, so I'm thinking I should be able
to turn this off then in tcp.smtp provided I choose the right rule
setting.


Yes.


However, in 2.0.8, according to interazioni.it, the CHKUSER_RCPT_MX
setting is undefined which should mean that it's off by default, 
correct?

So, that's confusing me as to why the check is happening at all.


It is off by default for chkuser, but it's on by default with QMT. 
Jake felt it was better to keep things consistent with previous QMT 
behavior. However, I think Jake created a version (I have 
qmail-toaster-1.03-1.3.21) which has CHKUSER_SENDER_MX turned off by 
default. The CHKUSER_RCPT_MX setting is still enabled though. See 
/var/qmail/doc/chkuser_settings.h file for settings that are in effect 
for your QMT.



Ideas?


Jake will likely clarify.


Thanks,
Tim


On Wed, August 31, 2011 3:42 pm, Eric Shubert wrote:

I believe that the default chkuser settings will be used in QMTv2.
According to
http://www.interazioni.it/opensource/chkuser/documentation/chkuser_settings.html 


the MX checks are now off by default. I believe that they can be turned
on with an environment variable set in the tcp.smtp or run file if
desired, so no rebuilding will be needed.

On 08/31/2011 12:19 PM, Tim Pleiman wrote:

Here's the troublesome feature:

CHKUSER_RCPTMX_TMP_STRING 2.0.7 defined 451 DNS 
temporary failure

(#4.5.1 - chkuser)\r\n
String emitted if there is a soft DNS error on recipient domain.

 Original Message

Subject: [qmailtoaster] 451 DNS Temporary Failure: Issue that 
should be

addressed in  CHKUSER
From:Tim Pleimantplei...@bravosystemstech.net
Date:Wed, August 31, 2011 2:00 pm
To:  qmailtoaster-list@qmailtoaster.com
-- 



Eric,

Over the last couple of years working with qmailtoaster, I've come to
both
love and hate this particular CHKUSER check.

I keep copies of all the messages from the qmt list, and searching for
the
string 451 DNS Temporary Problem, it seems to me that people have 
many

problems with it that could be addressed with some simple fixes to the
CHKUSR code--e.g. more detailed error responses from CHKUSER that 
better

define the nature of the problem.

Unlike the posts I've read over the last year or so, I'm not having 
any

trouble with my caching nameserver, DJBDNS. It's working properly, has
always been working properly. I love DJBDNS. However, here's the 
problem

that I have with this particular CHKUSER check:

When a sender tries to send a message to a single 
u...@domain.com, if

the domain MX is unresolveable in DNS as follows:

2011-08-31 12:56:25.14400 servfail nc-mail.nchicago.org.
input/output
error

CHKUSR will return the 451 DNS Temporary Failure error indicative of
the
issue. In this case today, the above particular domain has no MX 
record

for it's e-mail--their problem, not mine.

So, this immediately prevents queuing of messages in QMail that cannot
currently be delivered immediately to that one particular domain. This
is
a good thing as it alerts the sender that the message cannot be
delivered
now--e.g. QMail is not going to queue the message now because it would
just sit there, either waiting for the MX to become available or, 
if it

does not, bouncing the message after the queuelifetime expires.

Now, aside from the 

Re: [qmailtoaster] Re: TLS on 587

[Tonix (Antonio Nati)]

Il 27/08/2011 01:15, Gilbert T. Gutierrez, Jr. ha scritto:
I have whitelisted my customer IPs so they can now send via port 25 if 
they desire. My support staff were starting to get frazelled by all 
the calls they were receiving. I do not assign rPTR records for most 
of my customers and with the default settings of spamdyke those emails 
are rejected.


The submission port though seems to be requiring TLS according to what 
my support techs (I don't talk directly to any of my customers 
anymore) are telling me, and you are correct that it does not go 
through spamdyke when using port 587. I am going to test at home and 
see if I can send unencrypted. I have some customers that still have 
versions of Outlook that do not support TLS.


port 587 is the submission port, and it should for sure require 
authentication (not TLS), and in such case spamdike is not necessary.


You may activate TLS optionally (in the client side setup should be 'use 
TLS if present' or 'do not use TLS').


Regards,

Tonino




Gilbert


- Original Message - From: Eric Shubert e...@shubes.net
To: qmailtoaster-list@qmailtoaster.com
Sent: Friday, August 26, 2011 3:45 PM
Subject: [qmailtoaster] Re: TLS on 587



On 08/26/2011 12:08 PM, Gilbert T. Gutierrez, Jr. wrote:
Getting used to using spamdyke. I have never used it before and it 
seems

to be causing problems for some of my customers. I have had to IP
whitelist a couple IPs for people who have always relayed their alarms
through my server..

The issue I still have not solved is my server requiring TLS on port
587. My old server did not (It was optional before and I cannot find 
the

setting to make it optional again). require TLS on 587. I am sure as I
look through Spamdyke files I will find that option.

Gilbert



- 



Let me see if I can clarify a couple things.

Port 587 requires authentication, but TLS is not required for smtp 
(although TLS is highly recommended).


Spamdyke operates on port 25, and is not connected to port 587 in any 
way. Running spamdyke on port 587 would be pointless, as port 587 
requires authentication, and spamdyke bypasses all filters on 
authenticated connections (in case any client program were to submit 
using port 25).


Whitelisting certain IPs for relaying operational emails is not 
uncommon. It's better to configure the client software to send with 
authentication (and TLS), although that's sometimes not practical.


With this in mind, would you like to try again? ;)

--
-Eric 'shubes'


- 

Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and 
installations.

 If you need professional help with your setup, contact them today!
- 

Please visit qmailtoaster.com for the latest news, updates, and 
packages.
To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com






- 

Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and 
installations.

 If you need professional help with your setup, contact them today!
- 

Please visit qmailtoaster.com for the latest news, updates, and 
packages.
 To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com







--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] CHKUSER rejects email due to apostrophe

[Tonix (Antonio Nati)]

Il 27/07/2011 13:24, Digital Instruments ha scritto:

Hi list,
I've got a huge problem here.


*CHKUSER rejected sender*: from Name.*O'Connor*@someserver.com:: 
remote blablabla.someserver.com:unknown:xxx.xxx.xxx.xxx rcpt  : 
*invalid sender address format*


Basically CHKUSER rejects email due to the ' apostrophe after O.
How can I fix this problem (step by step guide, please)? It affect 90% 
of the Ireland Country!!!



Thanks in advance,
/Cheers Alberto.




Disable formal checking of senders and recipients.

   * CHKUSER_RCPT_FORMAT
   * CHKUSER_SENDER_FORMAT

See 
http://www.interazioni.it/opensource/chkuser/documentation/chkuser_settings.html 
for more info.


Regards,

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] CHKUSER rejects email due to apostrophe

[Tonix (Antonio Nati)]

Il 27/07/2011 14:39, Digital Instruments ha scritto:

On 27/07/2011 13:28, Tonix (Antonio Nati) wrote:

Il 27/07/2011 13:24, Digital Instruments ha scritto:

Hi list,
I've got a huge problem here.


*CHKUSER rejected sender*: from Name.*O'Connor*@someserver.com:: 
remote blablabla.someserver.com:unknown:xxx.xxx.xxx.xxx rcpt  : 
*invalid sender address format*


Basically CHKUSER rejects email due to the ' apostrophe after O.
How can I fix this problem (step by step guide, please)? It affect 
90% of the Ireland Country!!!



Thanks in advance,
/Cheers Alberto.




Disable formal checking of senders and recipients.

* CHKUSER_RCPT_FORMAT
* CHKUSER_SENDER_FORMAT

See 
http://www.interazioni.it/opensource/chkuser/documentation/chkuser_settings.html 
for more info.


Regards,

Tonino


--

 Inter@zioniInterazioni di Antonio Nati
http://www.interazioni.it   to...@interazioni.it


Do I have to recompile ?


YES.

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] smtp very slow

[Tonix (Antonio Nati)]

But telnet localhost 25 is not pop.
Probably your localhost is not well defined.

Tonino


Il 20/07/2011 14:01, Neelesh ha scritto:

Hi Jens,

I checked DNS setting its proper. This is happen only with POP3 users.



On Wed, Jul 20, 2011 at 5:25 PM, Jens Galsgaard j...@gitservice.dk 
mailto:j...@gitservice.dk wrote:


Hi Neelesh,

I’d look at your DNS settings as the first thing.

//Jens

*From:*Neelesh [mailto:nile...@gmail.com mailto:nile...@gmail.com]
*Sent:* 20. juli 2011 13:54
*To:* qmailtoaster-list@qmailtoaster.com
mailto:qmailtoaster-list@qmailtoaster.com
*Subject:* [qmailtoaster] smtp very slow

Hi Jack,
What can I do if/qmail smtp/is extremely /slow/. When i do telnet
localhost 25 it takes long (around 1 min) to reply.

Kindly advise.

Thanks  Regards,

Neelesh




--
मनापासुन. मनापर्यंत.
निलेश पाटील




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] Sender rejected due to MX record

[Tonix (Antonio Nati)]

Il 14/06/2011 18:12, Alberto Maffini ha scritto:
Hello list, I wonder if someone of you can help me with this problem. 
I am not a qmail guru but I successfully installed qmailtoaster 3 year 
ago. In my server I have hylafax too. Now my problem.


I want to install hylafax on another machine. When I try to send a 
mail from the new server to qmailtoaster that handle my mailboxes I am 
refused with the following message: CHKUSER rejected sender: from 
r...@fax.sylcomed.com:: remote 
fax.sylcomed.com:unknown:192.168.1.253 rcpt  : invalid sender MX 
domain


I tried to insert a new line into my /etc/tcprules.d/tcp.smtp file 
192.168.1.:allow,RELAYCLIENT=,RBLSMTPD=,NOP0FCHECK=1 where 
192.168.1. is the class of the new machine


I rebuilt the cdb file with: tcprules /etc/tcprules.d/tcp.smtp.cdb 
/etc/tcprules.d/tcp.smtp.tmp  /etc/tcprules.d/tcp.smtp


But I'm still bouced.

The machine trying to send mails is fax.sylcomed.com with no MX record

As I'm not a guru I wouldn't recompile or something.

There is something I can do to allow only that machine ?


If you compiled chkuser with option

#define CHKUSER_SENDER_NOCHECK_VARIABLE  SENDER_NOCHECK

you can add in tcp.smtp:

192.168.1.:allow,SENDER_NOCHECK=, 
RELAYCLIENT=,RBLSMTPD=,NOP0FCHECK=1


Ciao!

Tonino



Thanks

Alberto




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re; max recipients

[Tonix (Antonio Nati)]

chkuser can have such options.

Regards,

Tonino

Il 03/05/2011 19:36, Joel Eddy ha scritto:

Besides the max-recipients=50 in spamdyke.conf is there somewhere else
that controls the max-recipients also. Qmail, Spamassassin or ?

I've got users with Norton AV that keep getting an error that they're
sending to too many even with only 27 recipients.

GR I HATE EMAIL ;-)

Joel


-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
 Vickers Consulting Group offers Qmailtoaster support and installations.
   If you need professional help with your setup, contact them today!
-
  Please visit qmailtoaster.com for the latest news, updates, and packages.

   To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
  For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com






--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
 If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.

 To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com

For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re; max recipients

[Tonix (Antonio Nati)]

There is another variable for max wrong recipients, which is the real 
anti-intrusion action.
See 
http://www.interazioni.it/opensource/chkuser/documentation/chkuser_settings.html.


Tonino

Il 03/05/2011 19:50, Joel Eddy ha scritto:


tcp.smtp has CHKUSER_RCPTLIMIT=50 so it and spamdyke.conf match on 
that point.


I'll see what I can find about chkuser.

Thanks.



*From:*Tonix (Antonio Nati) [mailto:to...@interazioni.it]
*Sent:* Tuesday, May 03, 2011 12:40 PM
*To:* qmailtoaster-list@qmailtoaster.com
*Subject:* Re: [qmailtoaster] Re; max recipients

chkuser can have such options.

Regards,

Tonino

Il 03/05/2011 19:36, Joel Eddy ha scritto:
 Besides the max-recipients=50 in spamdyke.conf is there somewhere else
 that controls the max-recipients also. Qmail, Spamassassin or ?

 I've got users with Norton AV that keep getting an error that they're
 sending to too many even with only 27 recipients.

 GR I HATE EMAIL ;-)

 Joel


 
-
 Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
  Vickers Consulting Group offers Qmailtoaster support and 
installations.

If you need professional help with your setup, contact them today!
 
-
   Please visit qmailtoaster.com for the latest news, updates, and 
packages.


To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com
   For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com






--

 Inter@zioniInterazioni di Antonio Nati
http://www.interazioni.it  to...@interazioni.it



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and 
installations.

  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and 
packages.


  To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com




No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 10.0.1209 / Virus Database: 1500/3612 - Release Date: 05/03/11




--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it

Re: [qmailtoaster] CHKUSR question

[Tonix (Antonio Nati)]

Il 18/04/2011 20:51, Scott Hughes ha scritto:


I have one Blackberry user on my QMT server.  He is having an issue 
when he attempts to send email via his Blackberry that he receives 
back a message from the server that reads, 5.1.0 - Unknown address 
error 571-'sorry, sender address has invalid format (#5.7.1 - chkuser)'.


Is this (from the QMT wiki) 
http://wiki.qmailtoaster.com/index.php/CHKUSR_-_Enable_characters_for_Blackberry_devices 
the only work around for this, or is there another that I haven't found?


Thanks,

Scott



Personally, I'm not using anymore this formal checking based on valid 
characters, because there are tools creating strange e-mail addresses 
for their purposes, and it is impossible to trace all of them. I feel 
this check was very useful years ago, but now things have changed a 
little bit.


Regards,

Tonino


--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it