Re: [xmail] SMTP external authentication is not worjing

[Bart Mortelmans via xmail]

I understand that you can be sure that your checkSmtpAuth.sh is indeed 
being called, because you see that the RFILE is created, with the 
contents you expect your script to put in there?


In that case my guess is that XMail is having trouble accessing your 
RFILE. If the exit code wasn't seen as "0", then you should either get 
"451 Requested action aborted" or "503 Authentication failed".
The error "550 Relay denied" most probably is based on the fact that it 
isn't finding "R" (for relaying) in the RFILE.
In theory, it should also delete the RFILE. So the fact that they're 
still there, also seems to indicate a problem with the RFILE.


- What would happen if you don't write this RFILE and don't specify the 
@@RFILE parameter in smtpextauth.tab? In theory the default from 
server.tab would be used.
- Anything strange about permissions of the RFILE's that have not been 
removed?
- Could it be that your script has somehow not finished writing the file 
yet by the time XMail tries to read it?




Bart



Op 5/03/19 om 07:41 schreef Spon Spon via xmail:

Hello,

I have a mixed setup with DOVECAT for IMAP access, and XMAIl 1.27 for 
the rest.  The relay is cosed until authentication is made In order to 
have a centralized place for authentication I used in XMAIL external 
authentication.  However seems it is not working as I receive 550 
Relay Denied when I try to send an email using this XMAIL server.


The setup is as following:

In smtpextauth.tab I put following line:

"LOGIN""/config/scripts/checkSmtpAuth.sh""@@AUTH""@@USER""@@PASS""@@RFILE"
In server tab I have:
"DefaultSmtpPerms""MRVZ"

In checkSmtpAuth.sh I always exit with 0 for testing.  However I 
received 550 Relay denied each time I tried to send an email.  If the 
script exits with 1 then the error is different, (Authentication error).


I tried also populating RFILE with Perms=MR but without success. I 
tried also with Perms=MRVZ . No change.


Also another issue is the fact that those RFILE files were never get 
deleted.  For each email, that file is created and stays there forever 
(need external action to delete it)


Is there any other settings that need to be made or is this a bug ?

Using internal authentication (smtpauth.tab or mailuser.tab) emptying 
smtpextauth.tab  there is no such error, and everything works as expected.


Unfortunately there is no debug log in application, so only way to 
figure out is DEBUG, and currently it is installed on an embedded 
router so no way to debug.


Thanks,
Spon


___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail





smime.p7s
Description: S/MIME-cryptografische ondertekening
___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] Catch All

[Bart Mortelmans via xmail]

Hi,

The easiest solution probably is putting this in aliases.tab:
“rpzdesign.com”[tab]”*”[tab]”rpzrpzrpzj...@gmail.com”

Obviously replacing [tab] with real tabs. And take into account that this is a 
file you can’t edit while XMailserver is running (so turn it off first or use 
CtrlClnt to edit it).

Sincerely,
Bart



> On 20 mrt. 2016, at 11:05, md--- via xmail  wrote:
> 
> How does one create a catch all for a given domain while still allowing 
> specific users to receive
> their messages?
> 
> For example:
> 
> My domain is rpzdesign.com
> 
> I want all messages sent specifically to m...@rpzdesign.com to come to my 
> inbox.
> 
> But I want ALL other email address like anyth...@rpzdesign.com to be sent to 
> an external email address
> at rpzrpzrpzj...@gmail.com
> 
> Mailproc.tab in domain?
> 
> I tried using aliases but it does not work like I want, to many 550 user 
> unkown errors.
> 
> Any help?
> 
> Marco
> 
> 
> ___
> xmail mailing list
> xmail@xmailserver.org
> http://xmailserver.org/mailman/listinfo/xmail

___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] BUG : XMAIL 1.27 with SSL

[Bart Mortelmans via xmail]

It might be difficult to determine if the problem is with XMail or with 
the client. And even if for example Tencent actually closes the 
connection incorrectly, it should be better if XMail would be able to 
handle such an improperly closed connection.
But I'm not sure if you'll find somebody in this forum that will be able 
to fix this problem. Maybe you could try to get K9 developers involved 
in this? That seems to be managed much more actively than XMail. With a 
bit of luck, they can at least find out what they are doing differently 
compared to for example Outlook and that could cause this problem.



Oversea Site via xmail schreef op 26/05/15 om 15:09:

Now I am using original XMAIL-1.27.tar.gz source without simultaneous POP3 
logins, no STUNNEL, use NATIVE XMAIL SSL. The problem still exists, K9-MAIL 
will report IllegalFormatConversonException when I receive more then 100-200 
emails. So It should be XMAIL SSL problem. Because When I reuse STUNNEL to do a 
POP3 tunnel again, the problem will fix.


 Original Message 
From: Bart Mortelmans b...@bim.be
To: t...@os.st, XMail Users Mailing List xmail@xmailserver.org
Sent: Tue, May 26, 2015, 3:13 PM
Subject: Re: [xmail] BUG : XMAIL 1.27 with SSL

Is there any way for you to test if the problem exists if you don't
allow simultaneous POP3 logins?


Oversea Site via xmail schreef op 26/05/15 om 08:14:

POP3Utils.cpp - ADD POP3 Concurrent Login. I used this function over 5 years.. 
I don't know C++ programming. Sorry :)


 }
  if (pPOPMD-ulFlags  POPF_MSG_DELETED) {
  UPopSendErrorResponse(hBSock, ERR_MSG_DELETED, 
pPOPSD-iTimeout);

  ErrSetErrorCode(ERR_MSG_DELETED);
  return ERR_MSG_DELETED;
  }

  UsrGetMailboxPath(pPOPSD-pUI, szMsgFilePath, sizeof(szMsgFilePath), 
1);
  StrNCat(szMsgFilePath, pPOPMD-szMsgName, sizeof(szMsgFilePath));
/*
   * ADDED CODE START
   */

FILE *pMsgFile = fopen(szMsgFilePath, rb);
if (pMsgFile == NULL) {
UPopSendErrorResponse(hBSock, ERR_FILE_OPEN, pPOPSD-iTimeout);

ErrSetErrorCode(ERR_FILE_OPEN);
return ERR_FILE_OPEN;
}
fclose(pMsgFile);

/*
   * ADDED CODE END
   */

  SysSNPrintf(szResponse, sizeof(szResponse) - 1,
  +OK  SYS_OFFT_FMT  bytes, pPOPMD-llMsgSize);
  if (BSckSendString(hBSock, szResponse, pPOPSD-iTimeout)  0)
  return ErrGetErrorCode();

  if (pPOPMD-llMsgSize  0 



 Original Message 
From: Oversea Site via xmail xmail@xmailserver.org
To: XMail Users Mailing List xmail@xmailserver.org
Sent: Tue, May 26, 2015, 1:56 PM
Subject: Re: [xmail] BUG : XMAIL 1.27 with SSL

FEDORA 4 X86_64 GLIBC 2.3.6-3 (I can't upgrade it to the lastest version.. 
Because I have a chiliasp 3.6.2 32-bit run ASP VBSCRIPT on APACHE 1.3 32-bit 
software, it need GLIBC 2.3.x and Kernel 2.6)

KERNEL 3.3 MOD FROM FC15 (It will display KERNEL 2.6.43 Number). Kernel is not 
a main problem. Because I have been test 2.6.32 or other. same problem was 
found.

REAL HARDWARE - INTEL B85M i3-4150 16G RAM SATA3 RAID 1 LINUX SOFTRAID1 MDADM

Corp. Email System is not heavily use when I test it in HK TIME midnight..

Anyway I will test this issue in other linux distribution in VM, such as 
CentOS. (You can give me any linux distribution, let's build the same platform 
in VM. I use virtualbox.

[root@bravo logs]# uname -a
Linux bravo 2.6.43-gcc402 #3 SMP Sun May 17 23:10:29 HKT 2015 x86_64 x86_64 
x86_64 GNU/Linux
[root@bravo logs]#
[root@bravo logs]# ldd /var/MailRoot/bin/XMail127v3
 linux-vdso.so.1 =  (0x77f0e000)
 libssl.so.0.9.8 = /usr/local/ssl/lib/libssl.so.0.9.8 
(0x7f43b00bc000)
 libcrypto.so.0.9.8 = /usr/local/ssl/lib/libcrypto.so.0.9.8 
(0x7f43afd35000)
 libdl.so.2 = /lib64/libdl.so.2 (0x003e1820)
 libpthread.so.0 = /lib64/libpthread.so.0 (0x003e1860)
 libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x7f43afa37000)
 libm.so.6 = /lib64/libm.so.6 (0x003e1800)
 libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x003e1940)
 libc.so.6 = /lib64/libc.so.6 (0x003e17d0)
 /lib64/ld-linux-x86-64.so.2 (0x003e17b0)

***
/var/MailRoot/bin/XMail127v3 -Md -Ms /var/MailRoot -Sl -Pl -Cl \
-SI 0.0.0.0:8025 -SI 0.0.0.0:25 \
-PI 0.0.0.0:8110 -PI 0.0.0.0:110 \
-BI 0.0.0.0:995 \
-XI 0.0.0.0:465 \
-Ql -Ln 256 -Pt 60 -St 150 -F- -SX 2048 -Mx 64 \
-Qn 64 -PX 2048 -Qr 1 -Qt 1 -QT 150 -Qg -CX 256
***


 Original Message 
From: U.Mutlu um4...@mutluit.com
To: t...@os.st, XMail Users Mailing List xmail@xmailserver.org
Sent: Tue, May 26, 2015, 1:06 PM
Subject: Re: [xmail] BUG : XMAIL 1.27 with SSL

Oversea Site via xmail wrote

Re: [xmail] Tip: Speeding up xmail by pointing envvar XMAIL_TEMP to a ramdisk

[Bart Mortelmans via xmail]

Are you sure this will actually speed up XMail? Have you been able to 
compare, specifically for XMail?


As far as I understand how XMail processes e-mails, it actually only 
creates a file one time and then moves that file around between 
temp-folder, spool folder and local POP3 folders. Moving a file on the 
same filesystem means the file isn't re-rewritten. If you move a file 
between different filesystems, it does need to be re-written. That could 
actually mean that having the temp folder on a RAM-disk might slow 
things down if there would be an event in which XMail moves a file from 
spool to temp to local POP3 folder. When they are all on the same 
filesystem, this would mean the file would need to be written only once 
(and then moved around). If the temp folder is on a different 
file-system, this would cause the file to be writting to the hard drive 
twice and to the RAM-drive once.


All mails will not only pass through the temp-folder, but will also end 
up in the spool-folder. If most mails only pass through the server (and 
don't need to be stored locally) then you might be able to see a speed 
improvement by also placing the spool folder on a ramdisk. But this 
would mean that all mails pending delivery are lost at server restart 
(so this isn't really recommended).


Sincerely,
Bart Mortelmans


U.Mutlu via xmail schreef op 25/05/15 om 01:09:

Tip: Speeding up xmail by pointing envvar XMAIL_TEMP to a ramdisk
(here on Linux using a 64 MB ramdisk mounted to /mnt/ramdisk )

mkdir -p /mnt/ramdisk

in /etc/fstab:
tmpfs  /mnt/ramdisk  tmpfs  nodev,size=64M  0  0

then either reboot or use this cmd:
mount /mnt/ramdisk

in xmail start script:
export XMAIL_ROOT=/var/MailRoot
export XMAIL_TEMP=/mnt/ramdisk
export 
PATH=$XMAIL_ROOT/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

...

and restart xmail.

The ramdisk size should be bigger than MaxMessageSize (unit KB) in 
server.tab.


This will speed up mail processing (at least incoming mails) 
significantly.

Here's more info about speed gains:
http://www.jamescoyle.net/knowledge/951-the-difference-between-a-tmpfs-and-ramfs-ram-disk 

The major benefit to memory based file systems is that they are very 
fast – 10s of times faster than modern SSDs. Read and write 
performance is massively increased for all workload types.


One can even copy the mostly called programs (for example filters) 
onto the ramdisk, but then one must use such a PATH line (instead of 
the above one):
export 
PATH=/mnt/ramdisk:$XMAIL_ROOT/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin




___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] thx to xmail and its author

[Bart Mortelmans via xmail]

Hi,

I have been using XMail for what must have been almost 15 years. I still prefer 
XMail for anything that does not need IMAP.

I made some small changes to the code. If anybody would be willing to pick up 
XMail and start development again, I hope that these changes can also get into 
the new version. If you need more details, let me know!

- Change the default error message for a failed pre-date or post-data filter to 
code 451 (by default this would otherwise be 554 which means there won’t be an 
other attempt). For me 451 makes much more sense. 

- Added basic support for LMTP. That way I can have XMail deliver mails to 
dovecot directly. For this, I just had to add the LHLO message next to the HELO 
and EHLO. This works for me, as with my configuration there shouldn’t be any 
event in which XMail tries to deliver one e-mail to multiple recipients via 
LTMP. I’m not sure if there might be other configurations for which more work 
would be needed for LMTP to work.

- Made XMail log a line to SMAIL log in case of delivery failure (posted 
details on this in an e-mail to this mailing list very recently).

If anybody is taking feature requests: I would be interested in a way of XMail 
talking to a “filter” via a socket. Now, for every e-mail to be filtered, a 
process has to be started. It would be much more efficient if XMail could talk 
a filter-server via a socket. That filter server could be anything, but maybe 
we could even get it to talk directly to spamd and clamd…

Sincerely,
Bart Mortelmans


___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] tls

[Bart Mortelmans]

Spyros Tsiolis schreef op 5/01/14 20:30:

Does XMail support TLS ?

yes
___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] reflecting config file changes

[Bart Mortelmans]

Hi,


(could some be only read at start of xmail, don't know, no info in
doc, perhaps server.tab ? in this case I always stop, change, start to be
sure)
server.tab can be changed while xmail is running. After a couple of 
seconds xmail will start using the new information (it does take a 
little bit of time, so don't pannic if after half a second things 
haven't changed).


For the indexed files: it's best to edit them through the CTRL-interface 
(either socket or command line). In that case there is no need to reload 
XMailserver to load the new configuration.


Sincerely,
Bart


Op 18/09/12 14:43, fcxmail schreef:

Hello

No reload option

Files change that need xmail 'reload' (in fact stop/start) BEFORE changing
them are whose that are 'indexed' (refer doc for complete list but if I
remember they are domains.tab, aliasdomain.tab mailusers.tab, aliases.tab
and extaliases.tab)
All others, can be changed on the fly without 'reload', as they are read on
each use (could some be only read at start of xmail, don't know, no info in
doc, perhaps server.tab ? in this case I always stop, change, start to be
sure)

Regards
Francis

-Message d'origine-
De : xmail-boun...@xmailserver.org [mailto:xmail-boun...@xmailserver.org] De
la part de U.Mutlu
Envoyé : mardi 18 septembre 2012 13:40
À : xmail@xmailserver.org
Objet : [xmail] reflecting config file changes

Does xmail have a reload option to just reload its config files into
memory without stopping/restarting the program?

Which of the config files (ie. the *.tab files) do not require a
restart/reload after modifying the file?


(using xmail 1.27 src distro on linux)
___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail



___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] Trash Can

[Bart Mortelmans]

 Where on earth did you find this documented? 

It sort of makes sense. Documentation mentions that, if mailproc.tab
exists, every line in it will be processed. And you actually need to put
MAILBOX in it in order to put an e-mail in the mailbox (if
mailproc.tab exists...). Most often, if you don't use MAILBOX, you
will be using REDIRECT or something else. But documentation doesn't
say that some sort of default beheaviour will apply of mailproc.tab is
empty. So by not mentioning such a default it somehow does document the
/dev/null behaviour :-)

Sincerely,
Bart Mortelmans



Op 15/04/12 21:07, md schreef:
 Where on earth did you find this documented?

 Thanks for the answer,

 Marco Diener

 On 4/15/2012 2:50 PM, Bart Mortelmans wrote:
 Hi,

 If you create an e-mail address in XMailserver that has a
 mailprob.tab, but the mailproc.tab is empty, then this will simply
 /dev/null the mails sent to that address.

 It is important to note that the mailproc.tab should exist (but be
 empty). Not having a mailproc.tab will default to mailbox.

 Sincerely,
 Bart Mortelmans


 On 15-apr.-2012, at 20:30, md wrote:

 Does anybody know how to route all mail not in the white list
 into the permanent trash can?

 For example, when we send out emails for a newsletter, we want the
 reply to address to be:  nore...@xmailserver.com

 in aliases.tab I have:

 xmailserver.comTAB*junk...@xmailserver.com

 But I do not want the XMAIL server to even store this email since it
 will not be picked up ever by an email client and I do not want
 these messages taking up disk space in some queue file or directory.

 Anybody have an idea on how to either accept the email into a black
 hole
 or reject the email outright.

 md
 ___
 xmail mailing list
 xmail@xmailserver.org
 http://xmailserver.org/mailman/listinfo/xmail

 ___
 xmail mailing list
 xmail@xmailserver.org
 http://xmailserver.org/mailman/listinfo/xmail

 ___
 xmail mailing list
 xmail@xmailserver.org
 http://xmailserver.org/mailman/listinfo/xmail


___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] Trash Can

[Bart Mortelmans]

Hi,

If you create an e-mail address in XMailserver that has a mailprob.tab, but the 
mailproc.tab is empty, then this will simply /dev/null the mails sent to that 
address.

It is important to note that the mailproc.tab should exist (but be empty). Not 
having a mailproc.tab will default to mailbox.

Sincerely,
Bart Mortelmans


On 15-apr.-2012, at 20:30, md wrote:

 Does anybody know how to route all mail not in the white list
 into the permanent trash can?
 
 For example, when we send out emails for a newsletter, we want the reply to 
 address to be:  nore...@xmailserver.com
 
 in aliases.tab I have:
 
 xmailserver.com TAB * junk...@xmailserver.com
 
 But I do not want the XMAIL server to even store this email since it will not 
 be picked up ever by an email client and I do not want these messages taking 
 up disk space in some queue file or directory.
 
 Anybody have an idea on how to either accept the email into a black hole
 or reject the email outright.
 
 md
 ___
 xmail mailing list
 xmail@xmailserver.org
 http://xmailserver.org/mailman/listinfo/xmail

___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

[xmail] OutBind in SmtpConfig

[Bart Mortelmans]

Hi,

I'm running XMailserver 1.27. I would like outgoing connections to come from a 
specific IP-address. While it looks to be undocumented, I thought I could do 
this with something like this in server.tab:
SmtpConfigOutBind=XX.XX.XX.XX

But the mails keep going out through the default IP-address. What am I doing 
wrong?
(If anybody asks: I triple checked: real tab in there!)

Thanks!

Sincerely,
Bart Mortelmans

___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] Mailbox on NAS

[Bart Mortelmans]

Hi,

I'm not sure why this doesn't work, but for the performance, It might
also not be a good idea to have the domains folder and the spool folder
in different locations. I do think XMail does move files between those
folders, which isn't the same as copying a file and then deleting the
original  file. If both folders are on the same partition, moving a file
doesn't require actually copying its contents, it simply is linked to a
different location. If you're moving a file from one partition to an
other, this however does result in making a copy and then deleting the
original. So if most mails on your mailserver end up in a mailbox, then
it would be better to have spool and domains folder on the same partition.

In the light of this: I would be interested to know when XMail moves
files and when it makes a copy. I have for example read that setting the
temp-folder in memory would be a good thing to do. But if files are
moved in and out of the temp folder instead of being copied there,
this might not be such a good idea. Does anybody have an insight on this?

Sincerely,
Bart Mortelmans



Op 08/09/11 13:26, Rittikorn L schreef:
 Update.

 If I mount MailRoot folder to storage it can work normally.
 but it include spool folder, I don't want process spool folder at storage
 because storage it low performance, May be if run in real environment
 will lose connection.

 someone has any idea?


 Regards,
 Rittikorn L.


 On 08/09/11 15:43, Rittikorn L wrote:
 Hello,


 I would like to move XMail mailbox data to storage.
 I mount nfs only domains folder to storage and copy all user folders
 to storage.
 mail client can connect to server and got old Email normally

 after that I check send Email to local users but no any Email
 receive, Email still remain in spool folder,
 but if I send Email to outside it can send normally,

 Help me please...

 Regards,
 Rittikorn L.
 ___
 xmail mailing list
 xmail@xmailserver.org
 http://xmailserver.org/mailman/listinfo/xmail


 ___
 xmail mailing list
 xmail@xmailserver.org
 http://xmailserver.org/mailman/listinfo/xmail


___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] ctrlclnt connect ssl

[Bart Mortelmans]

Together with Stefan, I have been looking into what would be needed for
the XMailServer Control Library to be able to talk over TLS. We ended
up creating a small peace of Java as test (didn't include it in
CtrlClnt.jar yet, but that shouldn't be too difficult). If anybody else
needs this, please find the example below.

And if anybody reading this has experience with SourceForge, please do
add this code to the current project on
http://sourceforge.net/projects/xmail-ctrlclnt/
I would expect the larger part of this to go into the connect method.

Greetings,
Bart

=

Socket socket = new Socket(127.0.0.1, 6017);

InputStream in = socket.getInputStream();
OutputStream out = socket.getOutputStream();
BufferedReader br = new BufferedReader(new InputStreamReader(in));

//Read the greeting from the server
String line = br.readLine();
System.out.println(line); //You might want to check here if it's what
you expected it to be

//Tell the server that we'll be using TLS
out.write(#!TLS\r\n.getBytes());
line = br.readLine();
System.out.println(line); //You might want to check if the response was
something like +0 Ready to start TLS mode

//set up everything to be able to talk over TLS
SSLContext ctx = SSLContext.getInstance(TLS);
SecureRandom rnd = null;
byte seed[] = new byte[1024];
FileInputStream is = new FileInputStream(/dev/urandom);
is.read(seed);
is.close();
rnd = java.security.SecureRandom.getInstance(SHA1PRNG);
rnd.setSeed(seed);
//Accept self signed certs, remove this if you don't want this
TrustManager[] trustAllCerts = new TrustManager[]{
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}

public void
checkClientTrusted(java.security.cert.X509Certificate[] certs, String
authType) {
}

public void
checkServerTrusted(java.security.cert.X509Certificate[] certs, String
authType) {
}
}
};
KeyManager[] km = null;
ctx.init(km, trustAllCerts, rnd);
SSLSocketFactory sslFactory = ctx.getSocketFactory();

//enable ssl for existing socket
socket = (SSLSocket) sslFactory.createSocket(socket, 127.0.0.1., 6017,
true);

//we'll need new streams from the new socket
in = socket.getInputStream();
out = socket.getOutputStream();

//Okay, now you can talk to the server as normal, first you'll need to
log-in

___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] suspicious mail behaviour; don't know what to make of it . . .

[Bart Mortelmans]

Hi,

Since there is X-AuthUser in the headers, it looks like a username and
password of one of your POP3 clients was used to be able to relay
through your mailserver. If you don't want this, you might want to check
on DefaultSmtpPerms in server.tab.

And I would advice to change the POP3 password of that user mentioned in
X-AuthUser.

Sincerely,
Bart


Op 25/02/11 10:55, Spyros Tsiolis schreef:
 Hello,

 Recently, I've found entries on my anti-spam mechanism of someone
 adding spam
 addresses in china to my whitelist.

 at first I thought it was the mechanism. However, take a look at this
 (this is a message
 that got back to the senders' mailbox after the receipient was not
 found from the
 actual mail server) :

 --
 From: offendeddomain.gr PostMaster [mailto:postmas...@offendeddomain.gr] 
 Sent: Friday, February 25, 2011 8:26 AM
 To: account_that_is_sending_s...@offendeddomain.gr
 Subject: Error sending message [1298614677647.b7bbcb90.3c2.7730e.jekyll]
 from [offendeddomain.gr]

 [00] XMail bounce: Rcpt=[gushizhijia...@yahoo.cn];Error=[554 delivery
 error: dd Sorry your message to gushizhijia...@yahoo.cn cannot be delivered.
 This account has been disabled or discontinued [#102]. -
 mta104..mail.cnh.yahoo.com]


 [01] Error sending message [1298614677647.b7bbcb90.3c2.7730e.jekyll] from
 [offendeddomain.gr].

 ID:SA2BAD8
 Mail From: account_that_is_sending_s...@offendeddomain.gr
 Rcpt To:   gushizhijia...@yahoo.cn
 Server:mta-v1.mail.vip.cnh.yahoo.com [203.209.250.248]


 [02] The reason of the delivery failure was:

 554 delivery error: dd Sorry your message to gushizhijia...@yahoo.cn cannot
 be delivered. This account has been disabled or discontinued [#102]. -
 mta104.mail.cnh.yahoo.com


 [05] Here is listed the initial part of the message:

 X-AuthUser: account_that_is_sending_s...@offendeddomain.gr
 Received: from jekyll.offendeddomain.gr
   by jekyll.offendeddomain.gr with [XMail 1.27 ESMTP Server]
   id SA2BAD8 for gushizhijia...@yahoo.cn from
 account_that_is_sending_spam
 @offendeddomain.gr;
   Fri, 25 Feb 2011 08:17:40 +0200
 Received: from pfptxuxa ([222.247.120.207] helo=pfptxuxa) with IPv4:25 by
   jekyll.offendeddomain..gr; 25 Feb 2011 08:16:08 +0200
 From: =?gb2312?B?zuLotOi0?= account_that_is_sending_spam
 @offendedomain.gr
 To: gushizhijia001 gushizhijia...@yahoo.cn
 Subject: =?gb2312?B?uaTJy8rCucq1xLSmwO3T67fnz9Ww0b/YRzY3VTI2MA==?=
 Date: Fri, 25 Feb 2011 14:17:39 +0800
 X-Mailer: Microsoft Outlook Express 6.00.2800.1106
 MIME-Version: 1.0
 Content-Type: multipart/mixed; boundary==ybr910_4932_200237205.485272
 X-Priority: 3
 X-Assp-Version: 1..7.5.7(1.0.07) on jekyll.offendeddomain.gr
 X-Assp-Passing: authenticated
 X-Assp-ID: jekyll.offendeddomain.gr 14660-17969
 X-Assp-Intended-For: gushizhijia...@yahoo.cn
 X-Assp-Envelope-From: account_that_is_sending_s...@offendeddomain.gr
 -

 Now, AFAIK, I've setup XMail in such fashion as to reject any relay
 attemps.
 I even checked on specialized sites if I've left any holes open.
 It looks fine. Still . . .

 Do you chaps have any ideas why is this happening ?

 I am about to backup the mailserver and re-install the anti-spam
 mechanism.
 Something very laborious and very time-consuming.

 Thank you all,

 spyros





 - I merely function as a channel that filters music through the
 chaos of noise - Vangelis


 ___
 xmail mailing list
 xmail@xmailserver.org
 http://xmailserver.org/mailman/listinfo/xmail

___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] Looking for a good tls example.

[Bart Mortelmans]

On 15-dec-09, at 21:13, Dale wrote:

I haven't actually implemented it.  The problem is that I'm not sure  
where to put the settings.  I'm not sure how to make my lack of  
understanding (or stupidity, your choice) any clearer.


I guess the difficult part is that things will actually already work  
the moment the certs are available in the correct location (and you  
didn't explicitly turn it off) :-) Give the implementation a go! It  
should be easier to get working than you assume.


___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] XMail 1.26-Pre05 prepends a white char to original header lines

[Bart Mortelmans]

Hi,

I think there still is a problem somewhere. An other destination 
mailserver responds with this (not sure what they're running):

 550 Requested action not taken: Nonstandard SMTP line terminator.

It seems there still is a wrong linefeed in there?

Again: tested without any filters.

I hope you can figure out what is causing this

Sincerely,
Bart Mortelmans


Davide Libenzi schreef:

On Mon, 9 Feb 2009, Bart Mortelmans wrote:

  

OK, lets try as attachment ...

  

That seems to have done the trick! I tested with an e-mail to Hotmail, and
that one did now correctly display.
I'll also test with Exim a.s.a.p.

Thanks again!



OK, thanks for testing. I'll make pre06 tomorrow...


- Davide


___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

  


___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] XMail 1.26-Pre05 prepends a white char to original header lines

[Bart Mortelmans]

Hi,

I've been using
tcpdump -X -q -s 2048 host XXX.XXX.XXX.XXX
to check out what might be going on. I'm rather sure that the second  
linebreak to make the empty line between the headers and the body  
consists only of a LF, no CR. In Hex I'm seeing 0d0a0a instead of the  
expected 0d0a0d0a.


I hope this helps you to solve this.

Sincerely,
Bart Mortelmans




On 9-feb-09, at 16:48, Bart Mortelmans wrote:


Hi,

I think there still is a problem somewhere. An other destination  
mailserver responds with this (not sure what they're running):

 550 Requested action not taken: Nonstandard SMTP line terminator.

It seems there still is a wrong linefeed in there?

Again: tested without any filters.

I hope you can figure out what is causing this

Sincerely,
Bart Mortelmans


Davide Libenzi schreef:


On Mon, 9 Feb 2009, Bart Mortelmans wrote:



OK, lets try as attachment ...


That seems to have done the trick! I tested with an e-mail to  
Hotmail, and

that one did now correctly display.
I'll also test with Exim a.s.a.p.

Thanks again!


OK, thanks for testing. I'll make pre06 tomorrow...


- Davide


___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail




___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail


___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

[xmail] XMail 1.26-Pre05 prepends a white char to original header lines

[Bart Mortelmans]

Hi,

When using XMail 1.26-Pre05 with redirect in the mailproc.tab to 
forward mails, the header lines that where in the e-mail before delivery 
at XMailserver, seem to be prepended with something that very much looks 
like a white space. At least that's what it looks like when delivered to 
an Exim mailserver.
Mails redirected to a hotmail address are interpreted incorrectly by 
hotmail. Hotmail shows parts of the headers of such an e-mail in the body.


The problem occurs with mails delivered by XMail 1.26-Pre05 to an Exim 
or hotmail mailserver (maybe also to other MTA's?)
The problem doesn't occur with mails delivered by XMail 1.26-Pre05 to an 
older version of XMail, to GMail, to QMail or to mails stored in the mailbox
The problem also doesn't occur with mails delivered by XMail 1.24 with 
the exact same configuration


The mails didn't pass by any filters or other plug-ins.

Could this have something to do with the change to the line endings, but 
I thought that only changed things when storing mails in the mailbox?


Is anybody else seeing this? Has anyone used this version for delivery 
to Hotmail or to a server running Exim?


Davide, do let me know if you need any more information to be able to 
investigate this.


Thanks!

Sincerely,
Bart Mortelmans


___
xmail mailing list
xmail@xmailserver.org
http://xmailserver.org/mailman/listinfo/xmail

Re: [xmail] XMail 1.26-Pre05 prepends a white char to original header lines

[Bart Mortelmans]

Hi Davide,

That was quick! :-)


I get this response when applying the patch:
===
patching file SMAILUtils.cpp
patch:  malformed patch at line 7: }
===

I didn't continue, because I assume that patch didn't do anything.
I've never tried to patch something, so it's a bit new to me. I  
simply copy-pasted the code to a file which I hapenned to name  
PATCH_FILE, placed it in the sourcode folder and then ran patch -p1   
PATCH_FILE within that folder...


If it's not something in the patch-code, could you maybe try to ad the  
code as an attachment, so I'm sure it's not my e-mail client  
malformatting the code.


Thanks!

Sincerely,
Bart Mortelmans



On 8-feb-09, at 21:20, Davide Libenzi wrote:


On Sun, 8 Feb 2009, Bart Mortelmans wrote:


Hi,

When using XMail 1.26-Pre05 with redirect in the mailproc.tab to  
forward

mails, the header lines that where in the e-mail before delivery at
XMailserver, seem to be prepended with something that very much  
looks like a
white space. At least that's what it looks like when delivered to  
an Exim

mailserver.
Mails redirected to a hotmail address are interpreted incorrectly  
by hotmail.

Hotmail shows parts of the headers of such an e-mail in the body.

The problem occurs with mails delivered by XMail 1.26-Pre05 to an  
Exim or

hotmail mailserver (maybe also to other MTA's?)
The problem doesn't occur with mails delivered by XMail 1.26-Pre05  
to an older
version of XMail, to GMail, to QMail or to mails stored in the  
mailbox
The problem also doesn't occur with mails delivered by XMail 1.24  
with the

exact same configuration

The mails didn't pass by any filters or other plug-ins.

Could this have something to do with the change to the line  
endings, but I

thought that only changed things when storing mails in the mailbox?

Is anybody else seeing this? Has anyone used this version for  
delivery to

Hotmail or to a server running Exim?

Davide, do let me know if you need any more information to be able to
investigate this.


Thank you Bart. I think I found the problem. Can you try the patch  
below

on top of 1.26-pre05?

$ cd XMAIL_SOURCE
$ patch -p1  PATCH_FILE
$ make -f MAKEFILE



- Davide



diff --git a/SMAILUtils.cpp b/SMAILUtils.cpp
index f7f5dba..6deef5d 100644
--- a/SMAILUtils.cpp
+++ b/SMAILUtils.cpp
@@ -932,12 +932,13 @@ int USmlGetMsgFileSection(SPLF_HANDLE hFSpool,  
FileSection FSect)

return 0;
}

-int USmlWriteMailFile(SPLF_HANDLE hFSpool, FILE *pMsgFile)
+int USmlWriteMailFile(SPLF_HANDLE hFSpool, FILE *pMsgFile, bool  
bMBoxFile)

{
SpoolFileData *pSFD = (SpoolFileData *) hFSpool;

/* Dump message tags */
-   if (USmlDumpHeaders(pMsgFile, pSFD-hTagList, SYS_EOL)  0)
+   if (USmlDumpHeaders(pMsgFile, pSFD-hTagList,
+   bMBoxFile ? SYS_EOL: \r\n)  0)
return ErrGetErrorCode();

fputs(SYS_EOL, pMsgFile);
@@ -949,19 +950,26 @@ int USmlWriteMailFile(SPLF_HANDLE hFSpool,  
FILE *pMsgFile)

ErrSetErrorCode(ERR_FILE_OPEN, pSFD-szMessFilePath);
return ERR_FILE_OPEN;
}
+
+   bool bWantCRLF = !bMBoxFile;
+
#ifdef SYS_CRLF_EOL
-   if (MscCopyFile(pMsgFile, pMessFile, pSFD-llMailDataOffset,
-   (SYS_OFF_T) -1)  0) {
-   fclose(pMessFile);
-   return ErrGetErrorCode();
-   }
-#else
-   Sys_fseek(pMessFile, pSFD-llMailDataOffset, SEEK_SET);
-   if (MscDos2UnixFile(pMsgFile, pMessFile)  0) {
-   fclose(pMessFile);
-   return ErrGetErrorCode();
-   }
+   if (!bWantCRLF)
+   bWantCRLF = true;
#endif
+   if (bWantCRLF) {
+   if (MscCopyFile(pMsgFile, pMessFile, pSFD-llMailDataOffset,
+   (SYS_OFF_T) -1)  0) {
+   fclose(pMessFile);
+   return ErrGetErrorCode();
+   }
+   } else {
+   Sys_fseek(pMessFile, pSFD-llMailDataOffset, SEEK_SET);
+   if (MscDos2UnixFile(pMsgFile, pMessFile)  0) {
+   fclose(pMessFile);
+   return ErrGetErrorCode();
+   }
+   }
fclose(pMessFile);

return 0;
@@ -1120,7 +1128,7 @@ int USmlCreateMBFile(UserInfo *pUI, const char  
*pszFileName, SPLF_HANDLE hFSpool

SysFree(pszReturnPath);

/* Write mail file */
-   if (USmlWriteMailFile(hFSpool, pMBFile)  0) {
+   if (USmlWriteMailFile(hFSpool, pMBFile, true)  0) {
ErrorPush();
fclose(pMBFile);
SysRemove(pszFileName);
diff --git a/SMAILUtils.h b/SMAILUtils.h
index 74c0f77..3e1bf73 100644
--- a/SMAILUtils.h
+++ b/SMAILUtils.h
@@ -77,7 +77,7 @@ const char *USmlSendRcptTo(SPLF_HANDLE hFSpool);
SYS_OFF_T USmlMessageSize(SPLF_HANDLE hFSpool);
int USmlSyncChanges(SPLF_HANDLE hFSpool);
int USmlGetMsgFileSection(SPLF_HANDLE hFSpool, FileSection FSect);
-int USmlWriteMailFile(SPLF_HANDLE hFSpool

[xmail] Old mail in spool

[Bart Mortelmans]

Hi,

We have a reasonably large amount of old mails in the spool-folder, all 
in the mess folders. They appair when running this:
find /var/MailRoot/spool -type f -mtime +30 | grep '/mess/'

I seem to remember that it has been hinted in the past that such a files 
might be left there because of a filter not having released the lock on 
the file (probably the filter crashed or took more time to complete then 
expected).
I looked up a couple of these mails in the logs and found that they have 
been delivered.

Would it be safe to delete these files, with something like this:
find /var/MailRoot/spool -type f -mtime +30 | grep '/mess/' | xargs rm -f

Our mailserver retry shedule should retry sending mails for up to 
maximum 7 days, so I assume that any file that has been in there for 30 
days isn't being retried anymore. But is it safe to simply delete them?


Thanks!
Bart Mortelmans


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: 1.26-pre04

[Bart Mortelmans]

Will the changes to linefeeds only change once the mail is in the  
mailbox-folder? We have software that is called in the mailproc.tab  
via a filter. This assumes the old linefeeds. Are linefeeds changed  
before the FILTER is called, or only once MAILBOX is called in the  
mailproc.tab?

Thanks!

Bart Mortelmans




Op 7-sep-08, om 20:55 heeft Davide Libenzi het volgende geschreven:

 1.26-pre04 is the same of 1.26-pre03, with a bug cirrected  
 (affecting Unix
 version). Because of that bug, message files were sent (via POP3)  
 with CR
 line termination instead of CRLF. I did not notice that because my  
 mail
 client doesn't really care and was handling such messages just fine.  
 I got
 a report though, that The Bat MUA does not actually like that. So  
 here we
 go:

 http://www.xmailserver.org/xmail-1.26-pre04.tar.gz
 http://www.xmailserver.org/xmail-1.26-pre04.win32bin.zip


 Changelog:

 - Changed the line termination used to store messages into the  
 mailboxes
  of Unix versions of XMail. Now messages are stored with the OS  
 native LF
  termination, instead of the RFC CRLF that was used before.
  This allows other Unix softwares working together with XMail to not  
 be
  confused by the extra CR present in the line termination.

 - The smtprelay behaviour with respect to 5xx responses from one  
 of the
  servers in the relay list, has been changed. Now a 5xx response will
  stop the processing, instead of iterating on the remaining servers of
  the list.

 - Avoid to crawl all the USER.TAB file during a userlist CTRL  
 command.

 - Fixed a bug that allowed non-RFC characters inside domain names.

 - Fixed OSX Leopard build error.

 - Added timeo option to flags execution.

 - Added NoAuth, EnableVRFY and EnableETRN settings inside IP  
 properties.


 The biggest change is the first. Since when XMail started delivering  
 to
 Maildir (long time ago), people started using XMail together with  
 other
 softwares that can get confused by the extra CR. How can this happen  
 is
 beyond my grasp, since handling both cases requires like one line of  
 extra
 code. But anyway.
 One of the reasons why I chose to save the mailbox file in CRLF  
 form, was
 due to the fact that the message could have been delivered with fast  
 OS
 primitives, if already in CRLF (and hence RFC) form. This avoided  
 creating
 extra copies of the message file during the SMAIL processing.
 In order to shove an extra file copy during the processing, I  
 changed the
 way temporary file are created when it comes to SMAIL local delivery.
 Before such files were created inside the system temporary directory  
 (/tmp
 or %TEMP%), and then a copy+delete was done to move the message  
 inside the
 mailbox. The copy+delete was needed, insated of a standard OS move/ 
 rename,
 because the mailbox mount/drive coulad have been located in another
 mount/drive WRT the temporary directory.
 Now things are changed and XMail will use a tmp directory inside
 MAIL_ROOT.
 What does it change for you? If you don't mount domain  
 subdirectories to
 other mount/drives (like 99% of XMail users), nothing. Xmail will
 automatically create the tmp subdirectory and the switch to the new
 version will be transparent.
 If you happen to mount domain subdirectories onto other mount/drives  
 WRT
 MAIL_ROOT, you simply have to remember to create a .tmp directory  
 at the
 root of the directory mount/drive.




 - Davide


 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Userlist hugging hard drive

[Bart Mortelmans]

Dear Davide,

Is this maybe something we can patch ourselves in the code? I would be 
very much interested in starting to use this since updates to accounts 
are very regular for us.

Thanks!

Sincerely,
Bart Mortelmans



Davide Libenzi schreef:
 On Mon, 16 Jun 2008, Bart Mortelmans wrote:

   
 I did some testing with strace. Running it on CtrlClnt didn't tell me 
 much, so I started XMail in debug through strace.

 As I understand the result correctly, then XMail forks to handle the 
 CTRL-request. The first files it opens in that fork seem reasonable: 
 ctrl.ipmap.tab, ctrlaccounts.tab, the ctrl-logfile, a temp-file and 
 mailusers.tab.

 After copying the contents of mailusers.tab into the temp-file (I 
 think), it however start opening each user.tab-file of every single user 
 in the system.

 I'm not sure why it's doing that, but I'm rather sure that it's this 
 that is causing the delay. It ended up opening almost 16000 files.

 Any ideas of why it would be doing this?
 

 Yep, you're right. There's a common function to load the user info, and 
 this one fetches the user.tab file too.
 I fixed it in the next version by adding a parameter to tell if the caller 
 wants user.tab info too, when loading it.



 - Davide


 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


   

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Userlist hugging hard drive

[Bart Mortelmans]

Davide Libenzi wrote:
 Yep, you're right. There's a common function to load the user info, and 
 this one fetches the user.tab file too.
 I fixed it in the next version by adding a parameter to tell if the caller 
 wants user.tab info too, when loading it.
   

Thanks! Looking forward to this new version.
-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Userlist hugging hard drive

[Bart Mortelmans]

I did some testing with strace. Running it on CtrlClnt didn't tell me 
much, so I started XMail in debug through strace.

As I understand the result correctly, then XMail forks to handle the 
CTRL-request. The first files it opens in that fork seem reasonable: 
ctrl.ipmap.tab, ctrlaccounts.tab, the ctrl-logfile, a temp-file and 
mailusers.tab.

After copying the contents of mailusers.tab into the temp-file (I 
think), it however start opening each user.tab-file of every single user 
in the system.

I'm not sure why it's doing that, but I'm rather sure that it's this 
that is causing the delay. It ended up opening almost 16000 files.

Any ideas of why it would be doing this?



decker schreef:
 Hey,

   
 ../CtrlClnt -s localhost -u *** -p ** userlist  
 test.domain.tld
 

 Just a shot in the dark, is it the same when using 127.0.0.1 rather than
 localhost ? Can you strace the CtrlClnt process to see where it's
 spending the most time at ?

 ~Darren
 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


   

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Userlist hugging hard drive

[Bart Mortelmans]

Dear Davide,

Thanks for your input! To check that I'm certainly not doing anything  
else time-consuming and that it's not a faulty hard drive with a bad  
cluster in mailusers.tab, I made this little shell script:

===
date
grep \test\.domain\.tld\ ../mailusers.tab
date
../CtrlClnt -s localhost -u *** -p ** userlist  
test.domain.tld
date
grep \test\.domain\.tld\ ../mailusers.tab
date
===

This is the result:
===
Sun Jun 15 15:06:15 CEST 2008
test.domain.tld   1 5421574   1 U
test.domain.tld   2 5721575   2 U
test.domain.tld   3 5621576   3 U
test.domain.tld   4 5121577   4 U
test.domain.tld   5 5021578   5 U
Sun Jun 15 15:06:15 CEST 2008
test.domain.tld   1 1 U
test.domain.tld   2 2 U
test.domain.tld   3 3 U
test.domain.tld   4 4 U
test.domain.tld   5 5 U
Sun Jun 15 15:06:30 CEST 2008
test.domain.tld   1 5421574   1 U
test.domain.tld   2 5721575   2 U
test.domain.tld   3 5621576   3 U
test.domain.tld   4 5121577   4 U
test.domain.tld   5 5021578   5 U
Sun Jun 15 15:06:30 CEST 2008
===

Getting the userlist via CtrlClnt took about 15 seconds while grep  
needed less then a second.

When getting a full list of all users (not only for one domain), the  
processing seems to stall now and again. It however stalls in  
different locations every next time I run it.

Any ideas of what might be going wrong? Could this be caused by some  
faulty setting somewhere?

Sincerely,
Bart Mortelmans



Op 15-jun-08, om 01:13 heeft Davide Libenzi het volgende geschreven:

 On Fri, 13 Jun 2008, Bart Mortelmans wrote:

 Hi all,

 When I run the CTRL-command userlist requesting users for one  
 domain,
 it seems to take an unreasonable amount of time before it returns  
 (20 to
 30 seconds). In between, when I monitor the server with the Linux
 command top, I notice that wa goes up to over 90%. Normal load
 average on this machine is around 0, but when running userlist this
 will go up to over 2.

 This is the same even if the userlist which is returned, should  
 contain
 no users or only a small amount.

 The total size of mailusers.tab is reasonably large (over 1Mb), but I
 would expect CTRL to at least be able to find the users in the list  
 as
 quicly as a simple grep for example?
 For the record: I'm not requesting the full userlist, I use the  
 command
 like this:
 userlist[TAB]domainCRLF

 The complete configuration of XMailserver is a copy/paste from an  
 other
 server. I'm seeing this both with XMailserver 1.24 and 1.25.

 The hard drive of this machine seems to be okay. I also seem to  
 notice
 something similar on an other machine, although not as extreme.

 I looked into many different possibilities to find the cause of this
 (including deleting tabindex), but am unable to find it. Or is this
 normal behaviour?

 Userlist should be very fast. The time of copying out the mailusers  
 file
 (that for 1MB size should be like 0.1s) and the time of reading each  
 line.
 Are you sure you're not issuing other commands, like, for example, the
 ones to query the mailbox/spool?
 Disk activity should be almost NIL for userlist.



 - Davide


 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Userlist hugging hard drive

[Bart Mortelmans]

Delays do indeed make me think of some sort of timeout. But using  
127.0.0.1 didn't make a difference...


Op 15-jun-08, om 19:04 heeft decker het volgende geschreven:

 Hey,

 ../CtrlClnt -s localhost -u *** -p ** userlist
 test.domain.tld

 Just a shot in the dark, is it the same when using 127.0.0.1 rather  
 than
 localhost ? Can you strace the CtrlClnt process to see where it's
 spending the most time at ?

 ~Darren
 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Userlist hugging hard drive

[Bart Mortelmans]

Hi all,

When I run the CTRL-command userlist requesting users for one domain, 
it seems to take an unreasonable amount of time before it returns (20 to 
30 seconds). In between, when I monitor the server with the Linux 
command top, I notice that wa goes up to over 90%. Normal load 
average on this machine is around 0, but when running userlist this 
will go up to over 2.

This is the same even if the userlist which is returned, should contain 
no users or only a small amount.

The total size of mailusers.tab is reasonably large (over 1Mb), but I 
would expect CTRL to at least be able to find the users in the list as 
quicly as a simple grep for example?
For the record: I'm not requesting the full userlist, I use the command 
like this:
userlist[TAB]domainCRLF

The complete configuration of XMailserver is a copy/paste from an other 
server. I'm seeing this both with XMailserver 1.24 and 1.25.

The hard drive of this machine seems to be okay. I also seem to notice 
something similar on an other machine, although not as extreme.

I looked into many different possibilities to find the cause of this 
(including deleting tabindex), but am unable to find it. Or is this 
normal behaviour?

Thanks for looking into this!

Sincerely,
Bart Mortelmans
-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Problem receiving mails from specific domain

[Bart Mortelmans]

 PS : Notice that the order in your post-data filters chain should be
 anti-virus filter then anti-spam filter as pure av scan engines are =
 generaly
 faster than a 'complex' anti-spam scan engine (so viruses will be as =
 soon as
 possible rejected without taking to much time)
   

I'm not sure if that is indeed the best order to put them in. Because 
the spamfilter is very likely to remove much more mails then your 
anti-virus, it can be better to first filter out spam, and only have 
the, reasonably small amount that is left, go through the virus-filter.
Let's say that the spamfilter is 10 times as slow as the virusfilter, 
but removes more then 10 times the amount of mails, then I think it's 
safe to say that you should first run the spamfilter.

-Bart

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Maximum DNS quesry depth exceeded

[Bart Mortelmans]

 Are you sure? Should be contrariwise in my opinion, the machine with problem 
 gets no MX record. Can you set the same DNS server on both XMail machines? 
 Preferably the working one as most likely is a DNS issue.
   

If no MX-records are found, then the A-record is used. So if there is an 
A-record for that name that happens to also point to the mailserver, 
then this would work...

Bart

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Dynamic DNS / Don't use SPF

[Bart Mortelmans]

SRS has a couple of problems, which make me assume that it's not going 
to really get anywhere:

1) If you implement SPF, then you have to rely on the fact that 
forwarding services of your recipients implemented SRS.
2) The from address gets mocked up. Making it not very user readable.
3) The from address SRS created would change from time to time (it 
includes a time stamp). So the same person sending me two mails, has two 
different addresses.
4) The from address SRS created is meant to expire (otherwise abuse via 
such an address would be possible). So replying to that e-mail you 
received last week, won't work. Sure, you know all about SRS, so you're 
able to find out what the real address of the sender was. But will your 
mom be able to do so?

Basically it comes down to this:
If you implement SPF, then you could assume that e-mails you send from 
servers that are trusted according to SPF and that don't get 
forwarded, are more likely to get through the spam filters.
But your SPF record is best to also allow mails from other servers 
simply because you never know if your recipient might be using forwarding.

Sincerely,
Bart Mortelmans



CLEMENT Francis wrote:
 This 'forwarding' issue is resolved with 'SRS' (Sender Rewriting =
 Scheme)
 that complements SPF.
 In fact SPF allways need SRS :)
 (except on final smtp servers that you are sure it's not possible to =
 forward
 to foreign servers that are not controlled by you)
 The couple SPF + SRS can be called 'new' SPF, and many products =
 implementing
 SPF implement SRS too.

 Some info on SRS here : http://www.openspf.org/SRS

 Francis


   
 -Message d'origine-
 De : [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] la part de Ivo Smits
 Envoy=E9 : vendredi 27 avril 2007 01:17
 =C0 : xmail@xmailserver.org
 Objet : [xmail] Re: Dynamic DNS / Don't use SPF


 Someone pointed out that SPF may cause other problems. A=20
 recent example:

 I ([EMAIL PROTECTED]) tried to email some abuse department,=20
 [EMAIL PROTECTED]
 This address was redirected to [EMAIL PROTECTED]
 My server delivers my email to MX1.example.com, which=20
 redirects the email.
 MX1.isp.com sees a mail from the IP of MX1.example.com, with=20
 the address=20
 [EMAIL PROTECTED],
 it then checks the SPF record for UFO-Net.nl and notices that=20
 MX1.example.com is not allowed to send this mail.

 So probably everyone will end up with a SPF record that tells=20
 the other=20
 mailserver to just accept email from everywhere (even GMail uses this=20
 record!).
 The only use of SPF may be to skip some resource-expensive checks like =
 

   
 spamassassin.

 Ivo

 
 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


   

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Dynamic DNS / Don't use SPF

[Bart Mortelmans]

Thanks for clearing that out!

Then my next question would be: is there something that would implement 
SRS in forwarding within XMailserver?

Sincerely,
Bart Mortelmans



CLEMENT Francis wrote:
 -Message d'origine-
 De : [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] la part de Bart Mortelmans
 Envoy=E9 : vendredi 27 avril 2007 09:41
 =C0 : xmail@xmailserver.org
 Objet : [xmail] Re: Dynamic DNS / Don't use SPF


 SRS has a couple of problems, which make me assume that it's not going =
 

   
 to really get anywhere:

 1) If you implement SPF, then you have to rely on the fact that=20
 forwarding services of your recipients implemented SRS.
 

 The mail from rewrite done by srs on forwarded mails will be used as =
 is by
 any no 'srs' intermediate server on any next hops in the route to the =
 final
 server (that have not to be 'srs' too)

   
 2) The from address gets mocked up. Making it not very user =
 
 readable.

 NO, it's the SMTP MAIL FROM that is changed NEVER the 'From' field in =
 the
 mail itself
 The 'user' never see the 'Mail From' in any mua 'normal' views, but =
 only
 when wanting to view de complete headers and if the smtp servers added =
 some
 info about the real 'mail from' used in the smtp transaction.
 The 'From' is not derived from the SMTP MAIL FROM, as the From is =
 allready
 in the mail header and written by the sender mua=20

   
 3) The from address SRS created would change from time to time (it=20
 includes a time stamp). So the same person sending me two=20
 mails, has two=20
 different addresses.
 

 Yes at smtp level, false at 'mua' level :)
 The final user see exactly the same address

   
 4) The from address SRS created is meant to expire (otherwise=20
 abuse via=20
 such an address would be possible). So replying to that e-mail you=20
 received last week, won't work. Sure, you know all about SRS,=20
 so you're=20
 able to find out what the real address of the sender was. But=20
 will your=20
 mom be able to do so?
 

 False, as said, the mua use the From and Reply-to 'mail header' fields, =
 not
 the smtp MAIL FROM that they dont know nothing.
 So replying is ok and never change.

   
 Basically it comes down to this:
 If you implement SPF, then you could assume that e-mails you send from =
 

   
 servers that are trusted according to SPF and that don't get=20
 forwarded, are more likely to get through the spam filters.
 But your SPF record is best to also allow mails from other servers=20
 simply because you never know if your recipient might be using=20
 forwarding.

 Sincerely,
 Bart Mortelmans



 

 Francis
 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


   

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Vanishing mails?

[Bart Mortelmans]

As far as I know, the SMAIL log will only show an SMTP-line for e-mails 
that where successfully delivered on the other end. So basically, the 
fact that your SMAIL log contains such a line, means that Yahoo accepted 
the email and that it was lost on their side...

Sincerely,
Bart Mortelmans


Tracy wrote:
 Local mail server configuration is reasonably correct. The HELO domain 
 setting is a valid FQDN and looking up that FQDN gives the IP address of 
 the mail server.

 I deliver mail from other users to Yahoo (no one else on my server sends 
 email to this particular user's place of business) without problem.

 I'm just looking for a way to prove that the mail isn't simply vanishing 
 into thin air on *my* server - once I can confirm it successfully left 
 my server, then I can start worrying about what happens to it on the 
 remote server.

 Ivo Smits wrote:
   
 This sounds like hotmail-policy. E-mail that may be spam, can just vanish, 
 even when it has been accepted by their SMTP server, and there was no 
 failure report at all.
 What can you do about this? I still don't really know. You should at least 
 check that the HELO-domain is valid, does not contain something that looks 
 like your IP address, and points back to the IP of the mailserver.

 Ivo

 - Original Message - 
 From: Tracy [EMAIL PROTECTED]
 To: xmail@xmailserver.org
 Sent: Thursday, April 26, 2007 1:13 PM
 Subject: [xmail] Vanishing mails?


 
 I have a user who is telling me that they attempted to send email to
 various places and the emails are simply vanishing. One of the places is
 to the place they work, and another was to Yahoo.

 I've looked in my logs, and I see the mail coming into my server
 (verified by the SMTP logs showing the sender as my local user and the
 recipient as the remote user), and I see the SMAIL entry showing the
 mail being delivered by SMTP - but I don't see any way to confirm that
 the mail was actually delivered to Yahoo or to their work machine.

 Where would I look to verify delivery? Does the fact that there's an
 entry in the SMAIL log with delivery method SMTP mean that the
 delivery attempt to the remote server was successful (meaning that there
 was no SMTP error generated during the protocol session and there was no
 DNS lookup or other transmission difficulty - I understand that mailbox
 delivery on the other side cannot be guaranteed)?

 Any ideas on where to look would be appreciated.
 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]

   
 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


 

 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


   

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] SMTP error: 451 Requested action aborted: (-100) local error in processing

[Bart Mortelmans]

Hello all,

I just installed XMailserver on a brand new machine running Fedora Core 
6. I now get this error when trying to connect via SMTP:

===
220 server.name.test [EMAIL PROTECTED] [XMail 
1.24 ESMTP Server] service ready; Thu, 22 Feb 2007 00:25:04 +0100
HELO something
451 Requested action aborted: (-100) local error in processing
===

I have done a couple of other successful XMailserver installations in 
the past and haven't seen this error before. Does anyone know what could 
be causing this?

Thanks!

Sincerely,
Bart Mortelmans

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: SMTP error: 451 Requested action aborted: (-100) local error in processing

[Bart Mortelmans]

 Duh!?! -100 is ERR_SHMAT and is never used in 1.24!?!
   


Regretfully, this is what I'm getting as a result.

I did a normal compilation from the source (make -f Makefile.lnx).
The only strange thing I can think of (different from what I'm used 
to) is that this server uses RAID 0 for the partition mounted under /.


In debug modus, I just see this:
 SMAIL thread [00] started
 SMAIL thread [01] started
 SMAIL thread [02] started
 SMAIL thread [03] started
 SMAIL thread [04] started
 SMAIL thread [05] started
 SMAIL thread [06] started
 SMAIL thread [07] started
 SMAIL thread [08] started
 SMAIL thread [09] started
 SMAIL thread [10] started
 SMAIL thread [11] started
 SMAIL thread [12] started
 SMAIL thread [13] started
 SMAIL thread [14] started
 [XMail 1.24 CTRL Server] started
 [XMail 1.24 CTRLS Server] started
 SMAIL thread [15] started
 [XMail 1.24 POP3 Server] started
 [XMail 1.24 POP3S Server] started
 [XMail 1.24 ESMTP Server] started
 [XMail 1.24 ESMTPS Server] started
 [XMail 1.24 PSYNC Server] started
 [XMail 1.24 FINGER Server] started
 LMAIL thread [00] started
 LMAIL thread [01] started
 LMAIL thread [02] started
 SMTP client connection from [192.168.1.116]
 SMTP client exit [192.168.1.116]

This is the script I use to start it with:

 #!/bin/sh

 XMAIL_ROOT=/var/MailRoot
 XMAIL_CMD_LINE=-Pl -Sl -Cl -Ll -Mm -Ql --debug -Md
 PATH=$XMAIL_ROOT/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 NAME=XMail
 DESC=XMail server
 set -e
 ulimit -c 2
 MAIL_ROOT=$XMAIL_ROOT
 export MAIL_ROOT
 MAIL_CMD_LINE=$XMAIL_CMD_LINE
 export MAIL_CMD_LINE
 export LD_ASSUME_KERNEL=2.6.19
 /var/MailRoot/bin/XMail -Pl -Sl -Cl -Ll -Mm -Ql --debug -Md


I'll try some more things, but am unsure where to look...

Sincerely,
Bart Mortelmans

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Nolisting

[Bart Mortelmans]

It is indeed a poor mans greylisting. Real greylisting is however much 
more effective. Reasonably large amounts of spam is targeted directly at 
the backup mailserver and will come through.

It doesn't seem have the drawback that greylisting has: possible large 
delays. But it did make me think of a possible solution for that in 
greylisting. What if you would have primary and secondary MX point to 
two different IP's on the same host. Both IP's do accept mail and run 
the same greylisting filter.
Currently, greylisting will only start accepting mail from one sender if 
it retries (for example) 15 or more minutes after the first attempt. And 
MTA's can take much longer before doing a second attempt on the same MX.
With both MX's pointing to one machine (two IP's), we could instruct 
Greylisting to accept mails without delay if we have first seen an 
attempt on the primary IP, and now get one on the sencondary. 
XMailserver has a *LOCALADDR-variable that will help with this.*
If the information on that site is correct, then most MTA's would retry 
on the second MX almost instantly after trying on the first one. So 
there basically is hardly any delay.

Do take into account that the delay does also has its benefits. Spam 
that is delayed, is more likely  to be captured by an other filter 
(blacklist, Pyzor, Razor, DCC, ...).

Any thoughts?

Sincerely,
Bart Mortelmans



Filip Supera wrote:
 Hello,

 Just heard about this in the Spamtools mailing list :

 http://www.joreybump.com/code/howto/nolisting.html

 Any thought ?
 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


   

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: Nolisting

[Bart Mortelmans]

 If the primary MX is accepting connections and telling it to try
 again later, don't SMTAs try the primary again before sending to a
 secondary, hence the need for the RST packet in the firewall in the
 nolisting info ? I might be totally wrong about that, but I was
 thinking the secondary was only used when the primary was unreachable
 or returning fatal errors ?
   

When an MTA get a fatal error (5xx) it normally shouldn't try again at 
all, also not on the secondary MX. A fatal error can for example by 
recipient unknown.

I don't know if there is a difference between the retry-schedule for no 
response from the primary MX, or a temporary error (4xx). I would assume 
that most MTA's would handle both the same way, but haven't tested this yet.

Sincerely,
Bart Mortelmans

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] Re: message altered bij filters.in/out.tab is unaltered in external command

[Bart Mortelmans]

Davide Libenzi wrote:
 If you change the message *and* you return 7, the next external will 
 find the modified messgae. XMail does not change the path neither changes 
 the file content upon 7, so if your previous external really changes it, 
 you'll find it changed.
   

Indeed... Totally my fault. Within some circumstances, my script 
wouldn't return 7 while it did modify the file. And that's what was 
happening here...

Sorry for the bother!

Sincerely,
Bart Mortelmans

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]

[xmail] message altered bij filters.in/out.tab is unaltered in external command

[Bart Mortelmans]

I've got a problem where my filter in filters.in.tab and filters.out.tab 
should have modified a message. But the message turns out not to be 
modified when presented to the script from the mailproc.tab:

I've basically got this in my mailproc.tab:
 external  0 10someScript.sh  @@FILE
 external  0 10anOherSchript.sh@@FROM
 @@MSGID   @@FILE

My filters.in.tab and filters.out.tab are set up to fire the same script 
for every e-mail. When I look into the logs my script writes, then I see 
that it gets fired twice (once for every line in the mailproc.tab).
The script might alter the message and return 7, or the message has to 
be deleted and it will exit with 4.

It seems that, when it exits returning 4, the external command from 
the mailproc.tab is (correctly) not called.
But when it returns 7, the unaltered message is found by the 
external command in the mailproc.

Does anyone know what might be going on here?

Thanks!

Sincerely,
Bart Mortelmans

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]