Re: [Dbmail] dbmail-lmtpd memory usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul J Stevens wrote: > James Greig wrote: >> Hi Guys, >> >> I'm not sure if this is a cause for concern or not. Our dbmail-lmtpd >> memory usage just seems to be creeping up and up to the extent that our >> boxes are running out of memory. It's a fairly heavily used mail >> cluster, so i'm torn between it just out growing its hardware or whether >> there's a possible memory leak in dbmail-lmtpd?? >> >> One of our boxes running dbmail-lmtpd has died two or three times in the >> past few months and it appears to have been down to memory usage. >> dbmail-lmtpd seems to always be on top, right now each process of >> dbmail-lmtpd is using approximately 40m-50m RES (Resident) memory, >> however, at times when the machine has exhausted memory, lmtpd has been >> using up to 130m RES per process, is this normal?? >> >> P.S we're running 2.2.7 > > James, not normal at all. Someone else reported possible leakage in the > lmtp daemon as well, so it's a definite suspect. > > Until someone tracks this down consider lowering the maxconnects setting > in dbmail.conf for lmtp. If necessary lower it to 1. > Paul could this be an issue? (in the 2.2.9 codebase) misc.c: 2336 dbmail_iconv_decode_field can get a non-null pointer returned from dbmail_iconv_str_to_utf8 and stored into tmp_raw, which is not freed before tmp_raw is destroyed. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHwnZdd4I3jTtt9EIRAvkKAKCYqF07+KGpIrW2dKMwE+ToGhfvuQCcDK9w lrLB3R553xm71J+o6JkQAjc= =qn7w -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] dbmail-lmtpd memory usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 one more potential issue that could affect more than lmtp, is that if db_connect in dbmodule.c is called on an already open connection, no free is done on the previuos connection. Although I expect that db_connect is supposed to be called only once, I did some tracing and it seems it can get called twice during program startup. Not sure at the moment how it ends up being called more than once. In any case it could be worthwhile to add a guard to db_connect. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHwpH6d4I3jTtt9EIRAhjLAJsGCxizrACVT+dCjQiN+uXIyVgT7gCgpC/2 N+uBoEp9xUD5gMVgElEohxk= =HBy+ -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] HMM got lmtp dupicate entries HOW and WHY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Rabbitson wrote: > Simon Lange wrote: >> >> >> > > I started getting the same errors that Simon describes right after > upgrading to 2.9. Worst part is that this error actually has some very > nasty consequences. Please look at bug #685. > > Thanks > > Peter seems that this problem happens whenever the mail being inserted already has a Return-Path header. dbmail also adds a return path header and if (as can happen) the value of that header is the same as the existing one, then there is the duplicate entry. I think that it would be a good idea to add a guard to dbmail to remove existing Return-Path headers so that this problem does not occur. In the meantime it is probably best to configure the MTA not to add the Return-Path header. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHzSnWd4I3jTtt9EIRAj8XAKDOXDMwMOzvv18s87mMMdOwF8Gn0QCfS1fL qpc3V/5wcqVm/OAMZDKeI+0= =nLaj -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] HMM got lmtp dupicate entries HOW and WHY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Rabbitson wrote: > John Fawcett wrote: >> I think that it would be a good idea to add a guard to dbmail to remove >> existing Return-Path headers so that this problem does not occur. > > E probably not add anything if a duplicate is detected. I definitely > do not want my headers tampered with unless necessary. There should only be one Return-Path header and that should be written by the final delivery agent, so there isn't much alternative here. > >> In the meantime it is probably best to configure the MTA not to add the >> Return-Path header. >> > > Email often passes through dbmail twice, so the MTA will not solve > anything. I have a number of dbmail forwards like: > > [EMAIL PROTECTED]: [EMAIL PROTECTED] > > so the email loops through the MTA and comes back to the correct > mailbox. This is to work against stupid forms/systems that do not > support '+' it would be a workaround to the current situation where dbmail freaks out on existing Return-Path headers (and because of that potentially does not store other headers - like the subject header not being stored as in bug 685). Return-Path headers should only be used for final delivery, so should not be added to forwarded messages. However MTAs should remove existing Return-Path headers, so I doubt this will be a problem. John > > ___ > DBmail mailing list > DBmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHzS/jd4I3jTtt9EIRAotQAKDgYckCVF5iPfIg24MreRMsaF4sCwCfdn2L 8tK3AdaFOX3ZCMO+qc/4U08= =VQJx -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: AW: AW: [Dbmail] HMM got lmtp dupicate entries HOW and WHY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul J Stevens wrote: > I looked at it. > > Something strange caught my eye. The headername_id values in the logs are > strictly ascending. That should not be the case because that implies the > message > inserted in the logs is very much like the first message you ever inserted > into > dbmail. Could you post another l5 log for a message that is *not* dbmail > related perhaps? > > Also, I noticed that in the logs, the collision only occurs on the > headername_id=16 insertion, which appears to be for 'return-path'. But the > return-path header doesn't even occur twice in that message. > Paul just to pick up on this. You saw from the log insert that there was only one Return-Path header. However from my limited experience the Return-Path header added by dbmail is only stored in dbmail_headervalues and never added to the phymessage. Up to now I was using cyrus and all my migrated messages have Return-Path in phymessage. New messages received with dbmail do not have Return-Path in phymessage, but there is always a value in dbmail_headervalues for Return-Path. It would be nice if the Return-Path also got added to the phymessage too, but though I would point out how dbmail is currently handling Return-Path since Simon's problem also looks like duplicate headers. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHzTIwd4I3jTtt9EIRAsfrAJ9S/zRK0BY6EgCr2lEZbrfakBLVOACeNHii yo9wxuopEaGtYF8O7WO9YEA= =qynZ -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: AW: AW: [Dbmail] HMM got lmtp dupicate entries HOW and WHY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Rabbitson wrote: > > Ah, I just wrote about this in another message. So to confirm - when > displaying in a MUA a message retrieved from dbmail, I see no return > path header (unless I add it at my MTA). Peter that's exactly what I get. However, if I do a select on dbmail_headervalues table, I find the Return-PAth value stored there. I'm not sure where MUAs are expecting to get this, from the message header or from the imap server directly, but I think it should go into the message header too. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHzTZpd4I3jTtt9EIRAlkqAJwIb5Vd1mUXJCQGXoz/YUU583A1qwCfZGeh uvngnGqOFjy0Rlcd2ZvBfGg= =Gu1o -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
[Dbmail] Another case of duplicate keys (via dbmail-smtp)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I did some further testing on 2.2.9 and was able
to reproduce the duplicate key problem.
The following message fed to dbmail via
cat /tmp/test | dbmail-smtp -d [EMAIL PROTECTED] -r [EMAIL PROTECTED]
produces the duplicate key message
- ---
Return-Path: <[EMAIL PROTECTED]>
Received: by mail.gufonero.com (Postfix, from userid 0)
id 8DB13AFB94; Tue, 4 Mar 2008 03:39:04 -0500 (EST)
To: [EMAIL PROTECTED]
Subject: Test
Message-Id: <[EMAIL PROTECTED]>
Date: Tue, 4 Mar 2008 03:39:04 -0500 (EST)
From: [EMAIL PROTECTED]
Simple test
-
Instead just changing the message a bit, the following message
produces NO error when submitted by:
cat /tmp/test | dbmail-smtp -d [EMAIL PROTECTED] -r [EMAIL PROTECTED]
- ---
Return-Path: <[EMAIL PROTECTED]>
Received: by mail.gufonero.com (Postfix, from userid 0)
id 8DB13AFB94; Tue, 4 Mar 2008 03:39:04 -0500 (EST)
To: [EMAIL PROTECTED]
Subject: Test
Message-Id: <[EMAIL PROTECTED]>
Date: Tue, 4 Mar 2008 03:39:04 -0500 (EST)
From: [EMAIL PROTECTED]
Simple test
-
but strangely has inserted TWO entries for Return-Path
into dbmail_headervalue [EMAIL PROTECTED] and blank.
see attached .log for first case and xx.log
for second case.
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHzaEZd4I3jTtt9EIRAiW/AKDZOKYYrNGjZC8qdkUQUrQf3WofHgCeITZm
oEw4RYLuKfTYNMuJe5q7wkY=
=BF6P
-END PGP SIGNATURE-
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[db] dbmodule.c,db_load_driver(+58): library_directory is [/usr/local/lib/dbmail]
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[db] dbmodule.c,db_load_driver(+71): looking for mysql as /usr/local/lib/dbmail/libmysql.so
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[sql] dbmysql.c,db_query(+287): query [SET NAMES utf8]
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[db] dbmodule.c,db_query(+151): last query took [0] seconds
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[sql] dbmysql.c,db_query(+287): query [SHOW VARIABLES LIKE 'collation_%']
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[db] dbmodule.c,db_query(+151): last query took [0] seconds
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[sql] dbmysql.c,db_mysql_check_collations(+121): does [collation_database:utf8_general_ci] match [collation_connection:utf8_general_ci]?
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[auth] authmodule.c,auth_load_driver(+51): library_directory is [/usr/local/lib/dbmail]
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[auth] authmodule.c,auth_load_driver(+64): looking for auth_sql as /usr/local/lib/dbmail/libauth_sql.so
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[sql] dbmysql.c,db_query(+287): query [SELECT 1=1 FROM dbmail_physmessage LIMIT 1 OFFSET 0]
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[db] dbmodule.c,db_query(+151): last query took [0] seconds
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[sql] dbmysql.c,db_query(+287): query [SELECT 1=1 FROM dbmail_headervalue LIMIT 1 OFFSET 0]
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[db] dbmodule.c,db_query(+151): last query took [0] seconds
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[sql] dbmysql.c,db_query(+287): query [SELECT 1=1 FROM dbmail_envelope LIMIT 1 OFFSET 0]
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[db] dbmodule.c,db_query(+151): last query took [0] seconds
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[message] dbmail-message.c,_set_content_from_stream(+425): parse message
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[smtp] main.c,main(+283): whole message = Return-Path: <[EMAIL PROTECTED]> Received: by mail.gufonero.com (Postfix, from userid 0) id 8DB13AFB94; Tue, 4 Mar 2008 03:39:04 -0500 (EST) To: [EMAIL PROTECTED] Subject: Test Message-Id: <[EMAIL PROTECTED]> Date: Tue, 4 Mar 2008 03:39:04 -0500 (EST) From: [EMAIL PROTECTED] Simple test
Mar 4 20:10:00 mail dbmail/smtp[11849]: Info:[dsn] dsn.c,dsnuser_resolve(+578): checking if [EMAIL PROTECTED] is a valid username, alias, or catchall.
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[auth] authsql.c,auth_check_user_ext(+222): checking user [EMAIL PROTECTED] in alias table
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[auth] authsql.c,auth_check_user_ext(+239): checks [0]
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[sql] dbmysql.c,db_query(+287): query [SELECT deliver_to FROM dbmail_aliases WHERE lower(alias) = lower('[EMAIL PROTECTED]') AND lower(alias) <> lower(deliver_to)]
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[db] dbmodule.c,db_query(+151): last query took [0] seconds
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[auth] authsql.c,auth_check_user_ext(+266): user [EMAIL PROTECTED] not in aliases table
Mar 4 20:10:00 mail dbmail/smtp[11849]: Debug:[dsn] dsn.c,address_has_alias(+2
Re: [Dbmail] (patch) Another case of duplicate keys (via dbmail-smtp)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul J Stevens wrote:
> I posted a patch that should fix this earlier today. I havent reproduced
> this problem (mysql settings involved here I suspect) so I can't verify
> this patch beyond not causing regressions.
>
I couldn't get the patch to work (it didn't insert all the
headers into dbmail_headervalue but skipped over quite a few
including the Return-Path).
I ran it with a slight modification:
static gboolean g_str_case_equal(gconstpointer a, gconstpointer b)
{
return MATCH((const char *)a,(const char *)b);
}
the patch seems ok, but does not solve the issue. The errors I
reported are with the above patch already done.
I cannot work it out at the moment why some message are ok
others are not. For some reason I think the return path with
<> round the email address is not working as it should.
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHzcovd4I3jTtt9EIRAvmSAKDdwtvJg4ZdMHyOhyB/bCpc/mXBtQCgyyKG
PqaAXC4F+eO6INRA/AVSx7g=
=Er8m
-END PGP SIGNATURE-
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] (patch) Another case of duplicate keys (via dbmail-smtp)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Fawcett wrote:
>
> the patch seems ok, but does not solve the issue. The errors I
> reported are with the above patch already done.
>
> I cannot work it out at the moment why some message are ok
> others are not. For some reason I think the return path with
> <> round the email address is not working as it should.
>
> John
ok, I've done some more debugging and have found one part of the problem:
the values in the GRelation which stores the headers/values relations
are being corrupted by the call to g_mime_message_set_header in
dbmail_message_set_header.
I printed them before and after that call and they are different:
I used this code which is the same as the code which will be used
later for reading the headers to be inserted.
GTuples *values;
unsigned char *raw;
unsigned i;
values = g_relation_select(self->headers,header,0);
for (i=0; ilen;i++) {
raw = (unsigned char *)g_tuples_index(values,i,1);
TRACE(TRACE_DEBUG,"raw value [%s]",(char*)raw);
}
in the case of xx.log (where two headers were inserted, one correct
and one blank) these are the values before and after the
g_mime_message_set_header call:
before: raw value [<[EMAIL PROTECTED]>]
after :raw value [^A]
the [^A] value eventually gets sanitized to "" which is why a blank
header gets inserted into the dbmail_headervalue table. It looks like
the call to g_mime_message_set_header is deallocating some memory
which the GRelation structure points to.
in the case of .log (where there was a duplicate entry)
before: raw value [<[EMAIL PROTECTED]>]
after :raw value [EMAIL PROTECTED]
so it looks as though the call to g_mime_message_set_header has
overwritten the previous memory with a new value but kept
memory position the same.
The code then goes on to add a new Return-Path header [EMAIL PROTECTED]
as specified by the command line parameter -r, so that's
why we end up with two Return-Path headers which are the same.
There is clearly a duplicate header problem to solve, but this is
compounded by undefined side effects on in memory headers
after the call to g_mime_message_set_header.
There is also an additional problem with g_mime_message_set_header
which is that it does not add a header if it is missing
but only change the value of an existing header, so I am getting
message that come in without a return-path being stored without
a return-path.
These are my packages on opensuse 10.3
gmime-2.2.1-10
glibc-2.4-31.1
We can spend time trying to get this to work, but I'm just wondering
whether we need to use g_mime_message_set_header at all. Seeing as
in the end we must have only one Return-Path header in the delivered
message and we are trying to update an existing header, maybe it
would be easier to ignore existing return-path headers and just
add our own: that way we also avoid duplicate Return-Path
headers in the in-memory structure which is the fundamental issue.
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHzmzud4I3jTtt9EIRAqsZAJ9cUG0v7kEQmdN4KeLJ0NIjDj0DQwCeOC04
wbTv4QhwM3fkl/3Ccmt4a+Y=
=CTiK
-END PGP SIGNATURE-
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] (patch) Another case of duplicate keys (via dbmail-smtp)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Rabbitson wrote: > John Fawcett wrote: >> >> We can spend time trying to get this to work, but I'm just wondering >> whether we need to use g_mime_message_set_header at all. Seeing as >> in the end we must have only one Return-Path header in the delivered >> message and we are trying to update an existing header, maybe it >> would be easier to ignore existing return-path headers and just >> add our own: that way we also avoid duplicate Return-Path >> headers in the in-memory structure which is the fundamental issue. >> > > I don't know much about C if anything, but just to chime in. As far as I > understand this code deals with general header handling. Isn't it > perfectly legal to have several X-headers with absolutely the same > values in a message? What happens then? g_mime_message_set_header (in set_message_header) is also being used on other types of headers (during message composition if I recall) so you're right that we cannot take it out altogether. However, the existing code cannot handle the case of multiple X- headers which have the same value: that would generate a Duplicate key. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHzoYGd4I3jTtt9EIRAocfAJ9um1FNQdMmZ/C/CvFNYIqwSYYj6QCg3OSK 9FUd8ZlAZEStJUcOrm0AEkc= =u/fL -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] (patch) Another case of duplicate keys (via dbmail-smtp)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Fawcett wrote: > However, the existing code cannot handle the > case of multiple X- headers which have the same value: that would > generate a Duplicate key. > > John Following up to my own post, ignore this, it's wrong. Multiple headers are handled without producing an error when they are read in from the original message, but they result in a single entry in the dbmail_headervalue cache. That makes sense I think, since dbmail_headervalue is a cache it won't benefit from multiple entries with the same values. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHzoqKd4I3jTtt9EIRAvn2AJ0brtcxM281zG8HeMXBZiC8THqlOwCgqEM2 cThlMUmTX0+xcFXZq30WZ3g= =OMRa -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] (patch) Another case of duplicate keys (via dbmail-smtp)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul J Stevens wrote: > attaching the old and a new patch. The last patch should fix the memory > corruption issue. > > Please apply both against 2.2.9 and let me know if it helps. > > Paul thanks for these. It solves memory corruption and duplicate Return-Path headers cases I posted. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHzpZ8d4I3jTtt9EIRAnevAKCggVbqYuPDUEPTMx9e2110/5BQSgCgsG2K 91/Y1MgKOY0EjpwcNzSdNic= =LtD1 -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
[Dbmail] Usermap to deny POP3 and allow IMAP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For some users I wanted to block pop3 but allow imap from the webmail
on localhost.
I entered this into usermaps, but it also blocks login to imap from
127.0.0.1.
Is anyone using usermap for the purpose or notice something wrong in
this entry?
INSERT INTO `dbmail_usermap` (`login`, `sock_allow`, `sock_deny`,
`userid`) VALUES
('[EMAIL PROTECTED]','inet:127.0.0.1:143','inet:0.0.0.0:110','[EMAIL
PROTECTED]');
here's the log snippet
Mar 5 15:38:16 mail dbmail/imap4d[17653]: Debug:[imapsession]
dbmail-imapsession.c,dbmail_imap_session_handle_auth(+1618): trying to
validate user [EMAIL PROTECTED], pass []
Mar 5 15:38:16 mail dbmail/imap4d[17653]: Debug:[sql]
dbmysql.c,db_query(+287): query [SELECT userid FROM dbmail_usermap WHERE
1 = 2]
Mar 5 15:38:16 mail dbmail/imap4d[17653]: Debug:[db]
dbmodule.c,db_query(+151): last query took [0] seconds
Mar 5 15:38:16 mail dbmail/imap4d[17653]: Debug:[db]
db.c,db_use_usermap(+167): enabling usermap lookups
Mar 5 15:38:16 mail dbmail/imap4d[17653]: Debug:[db]
db.c,db_usermap_resolve(+4748): checking userid [EMAIL PROTECTED] in
usermap
Mar 5 15:38:16 mail dbmail/imap4d[17653]: Debug:[db]
db.c,db_usermap_resolve(+4759): client on inet socket [inet:127.0.0.1:143]
Mar 5 15:38:16 mail dbmail/imap4d[17653]: Debug:[sql]
dbmysql.c,db_query(+287): query [SELECT login, sock_allow, sock_deny,
userid FROM dbmail_usermap WHERE login in ('[EMAIL PROTECTED]','ANY')
ORDER BY sock_allow, sock_deny]
Mar 5 15:38:16 mail dbmail/imap4d[17653]: Debug:[db]
dbmodule.c,db_query(+151): last query took [0] seconds
Mar 5 15:38:16 mail dbmail/imap4d[17653]: Debug:[misc]
misc.c,dm_sock_score(+830): base[inet:0.0.0.0:110]
test[inet:127.0.0.1:143] => [0]
Mar 5 15:38:16 mail dbmail/imap4d[17653]: Debug:[misc]
misc.c,dm_sock_compare(+853): clientsock [inet:127.0.0.1:143]
sock_allow[], sock_deny [inet:0.0.0.0:110] => [1]
Mar 5 15:38:16 mail dbmail/imap4d[17653]: Debug:[db]
db.c,db_usermap_resolve(+4799): access denied
thanks
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHzrGhd4I3jTtt9EIRAk0rAKCnDySJay9hgpnbvTXXGBu/fNmKegCfXv1I
VQ7WZBBXq9k1YQ6IR/8YMQc=
=cSiK
-END PGP SIGNATURE-
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: AW: AW: [Dbmail] HMM got lmtp dupicate entries HOW and WHY?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Rabbitson wrote:
> John Fawcett wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Peter Rabbitson wrote:
>>
>>> Ah, I just wrote about this in another message. So to confirm - when
>>> displaying in a MUA a message retrieved from dbmail, I see no return
>>> path header (unless I add it at my MTA).
>>
>> Peter
>> that's exactly what I get.
>>
>> However, if I do a select on dbmail_headervalues table, I find the
>> Return-PAth value stored there.
>>
>> I'm not sure where MUAs are expecting to get this,
>> from the message header or from the imap server directly, but I
>> think it should go into the message header too.
>>
>
> So what is the verdict on this? Should I be adding a RP just before
> handing email to dbmail, or should dbmail append it both in the headers
> and physmessage, or does it matter at all?
with the patch applied I could not find issues whether you add
RP in the MTA or not.
If passing messages via LMTP, I would not add a
RP in the MTA since dbmail gets this from the LMTP
envelope sender which is the most reliable place.
If passing messages via dbmail-smtp, I would specify the -r ${sender}
flag to ensure that this is the header that is used rather than any
pre-existing one, which may be forged.
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHzs19d4I3jTtt9EIRApNPAKCuv0oPrrKSoeQNjc7vrDMEo2RL7ACeIhaX
0MNyz+CSZapZOTcAvVHrZZE=
=jGUj
-END PGP SIGNATURE-
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] Usermap to deny POP3 and allow IMAP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul J Stevens wrote: > John Fawcett wrote: > >> @@ -4713,7 +4793,7 @@ >> - result = dm_sock_compare(clientsock, "", sockno); >> + result = dm_sock_compare(clientsock, sockok, sockno); > > don't do that. You won't be able to use the usermap's best-row-matches-best > weighing feature that determines which row to use for the actual mapping. > > The idea is that any match on a sock_deny will deny access, but the actual > usermapping used is determined by the row whose sock_allow matches best with > the > socket the client is connecting on. > > check out the patch in my other mail. > Paul thanks again, your patch is working fine. here's a documentation patch too, if that helps. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHzsUrd4I3jTtt9EIRApUVAKDXQyee0CROv5fu+/HLOwJZn7KSeQCZAdvs Z2sPYEWNQBMWvwWQ4Bx49NQ= =LOm4 -END PGP SIGNATURE- --- dbmail-2.2.9/README.usermap 2008-02-09 13:08:28.0 +0100 +++ dbmail-2.2.9-patch/README.usermap 2008-03-05 17:02:14.0 +0100 @@ -36,16 +36,19 @@ 3 |client | inet:10.1.1.1:143| inet:10.1.1.1:110| [EMAIL PROTECTED] 4 |ANY | inet:10.1.1.2:143| | [EMAIL PROTECTED] 5 |client | | inet:0.0.0.0:0 | +6 |client | inet:127.0.0.1:143 | inet:0.0.0.0/0:110 | [EMAIL PROTECTED] row 1 will give you a simple 1-1 mapping irrespective of the IP address connected to. row 2 will allow [EMAIL PROTECTED] to login on a single IP address with imap. row 3 will allow [EMAIL PROTECTED] to login on a single IP address with imap but will reject -POP access. +POP access from that IP. row 4 will map all logins on a single IP address to an expanded form. row 5 will deny any kind of access to client. +row 6 will allow [EMAIL PROTECTED] to login on a single IP address with imap but will reject +POP access from any IP. ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: AW: AW: [Dbmail] HMM got lmtp dupicate entries HOW and WHY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Rabbitson wrote: > > My question was was about the fact that currently dbmail does not record > the RP in the body of the message. I reviewed the patchset and don't see > this addressed. The bug indicated that OE discards information from the > IMAP server and reads the message body to get whatever it needs. So my > question is more like: will dbmail be adjusted in future version to > insert RP in the message body as well, or is this something in violation > of the protocols? I am getting RP header recorded now in the message body even when the message itself did not have a RP specified, so as far as I can see it is fixed. Here is the test I was using: cat /tmp/test | dbmail-smtp -d [EMAIL PROTECTED] where /tmp/test is: - ---start--- Received: by mail.gufonero.com (Postfix, from userid 0) id 8DB13AFB94; Tue, 4 Mar 2008 03:39:04 -0500 (EST) Received: by .gufonero.com (Postfix, from userid 0) id 8DB13AFB94; Tue, 4 Mar 2008 03:39:03 -0500 (EST) To: [EMAIL PROTECTED] Subject: Test Message-Id: <[EMAIL PROTECTED]> Date: Tue, 4 Mar 2008 03:39:04 -0500 (EST) From: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Simple test - end in squirrelmail I see: - ---start--- Received: by mail.gufonero.com (Postfix, from userid 0) id 8DB13AFB94; Tue, 4 Mar 2008 03:39:04 -0500 (EST) Received: by .gufonero.com (Postfix, from userid 0) id 8DB13AFB94; Tue, 4 Mar 2008 03:39:03 -0500 (EST) To: [EMAIL PROTECTED] Subject: Test Message-Id: <[EMAIL PROTECTED]> Date: Tue, 4 Mar 2008 03:39:04 -0500 (EST) From: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii - end So in the absence of the -r parameter and of an existing RP header, dbmail has added it's own (taken from the From: header). John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHztgHd4I3jTtt9EIRAtG+AKCowCtTfmy7/dRVtBvtqaLzq/0eWgCfQV3n JgFx7hwsPguZNYMoPQgH4D4= =AWkZ -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: AW: AW: [Dbmail] HMM got lmtp dupicate entries HOW and WHY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Rabbitson wrote: > John Fawcett wrote: > >> >> in squirrelmail I see: >> >> - ---start--- >> Received: by mail.gufonero.com (Postfix, from userid 0) id 8DB13AFB94; >> Tue, 4 Mar 2008 03:39:04 -0500 (EST) >> Received: by .gufonero.com (Postfix, from userid 0) id 8DB13AFB94; >> Tue, 4 Mar 2008 03:39:03 -0500 (EST) >> To: [EMAIL PROTECTED] >> Subject: Test >> Message-Id: <[EMAIL PROTECTED]> >> Date: Tue, 4 Mar 2008 03:39:04 -0500 (EST) >> From: [EMAIL PROTECTED] >> Return-Path: [EMAIL PROTECTED] >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=us-ascii > > Is it possible for you to verify how the same message looks like when > seen from OE? it looks fine and the RP header is visible too when I right click on properties. Is that what you meant? It's a while since I used OE. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHztw/d4I3jTtt9EIRAvHXAJ4qzfd8bglM72yGtMPa6eFhWg/GrgCfWuKX e8ySnKwkM1UaAQwWqe92x8A= =fvO4 -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] Usermap to deny POP3 and allow IMAP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Fawcett wrote:
> For some users I wanted to block pop3 but allow imap from the webmail
> on localhost.
>
> I entered this into usermaps, but it also blocks login to imap from
> 127.0.0.1.
>
> Is anyone using usermap for the purpose or notice something wrong in
> this entry?
>
> INSERT INTO `dbmail_usermap` (`login`, `sock_allow`, `sock_deny`,
> `userid`) VALUES
> ('[EMAIL PROTECTED]','inet:127.0.0.1:143','inet:0.0.0.0:110','[EMAIL
> PROTECTED]');
>
well I can get it working if I make this change, passing in the
sockok as well. (diff file line numbers may not match exactly
since I also have another patch installed on db.c)
- --- dbmail-2.2.9/db.c 2008-02-09 13:08:28.0 +0100
+++ dbmail-2.2.9-patch/db.c 2008-03-05 16:20:37.0 +0100
@@ -4713,7 +4793,7 @@
sockok = db_get_result(row, 1);
sockno = db_get_result(row, 2);
userid = db_get_result(row, 3);
- - result = dm_sock_compare(clientsock, "", sockno);
+ result = dm_sock_compare(clientsock, sockok, sockno);
/* any match on sockno will be fatal */
if (result) {
TRACE(TRACE_DEBUG,"access denied");
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHzruad4I3jTtt9EIRAoiJAJ0a6PoViLDKaXM9BFw2ofsXeQGMQACfbEs5
OVbn1sLTwBbXN/9Ok/xrwfc=
=DBgN
-END PGP SIGNATURE-
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: AW: AW: [Dbmail] DBMail version 2.2.10 release candidate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Lange wrote: > > Just "some lines" of dbmail-util... same for all binaries of dbmail. > Dbmail-conf settings for tracelevel are completely ignored. Began with the > patch. And now arrived in the rc1. > > Regards > > Simon Simon maybe it's something on your system, I'm not seeing anything like it and I have the rc1 installed. Also you mentioned it began with the patch. Looking at the few lines of code changed with the patch, it did not have anything to do with adding debugging or reading config options. Also -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFH1Q2/d4I3jTtt9EIRAqJkAKDc+Ibmu87E+thXhEs0lTXXnAkz3QCeIRjP e8aGtaugQSL4TYg7oXGxi8I= =s6yB -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] probably missing index in dbmail-2.2.8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Uwe Kiewel wrote:
| Hi there,
|
| probably I found a missing index on table dbmail_aliases in dbmail-2.2.8.
|
| mysql> explain SELECT deliver_to FROM dbmail_aliases WHERE lower(alias)
| = lower('XXX') AND lower(alias) <> lower(deliver_to);
|
++-++--+---+--+-+--+--+-+
| | id | select_type | table | type | possible_keys | key |
| key_len | ref | rows | Extra |
|
++-++--+---+--+-+--+--+-+
| | 1 | SIMPLE | dbmail_aliases | ALL | NULL | NULL |
| NULL| NULL | 20 | Using where |
|
++-++--+---+--+-+--+--+-+
|
| a "show index from dbmail_aliases;" shows, there is no index related to
| column deliver_to.
|
| After issuing "create index deliver_to_index on dbmail_aliases
| (deliver_to, alias);", mysql explain says:
|
| explain SELECT deliver_to FROM dbmail_aliases WHERE lower(alias) =
| lower('XXX') AND lower(alias) <> lower(deliver_to);
|
++-++---+---+--+-+--+--+--+
| | id | select_type | table | type | possible_keys |
| key | key_len | ref | rows | Extra|
|
++-++---+---+--+-+--+--+--+
| | 1 | SIMPLE | dbmail_aliases | index | NULL |
| deliver_to_index | 1054| NULL | 20 | Using where; Using index |
|
++-++---+---+--+-+--+--+--+
|
|
| Another way to optimize the "select deliver_to query" is to drop-off the
| "lower" function. In that case, you have to make sure, that all letters
| are lowered before using the sql statement.
|
|
| Well, my point of view is the database. Maybe there are more important
| reasons in the program code to go this way.
|
| How dou you think about?
|
Uwe,
adding this index changes a scan of every row of the table into a scan
~ of every row of the index, so although IO will be a bit faster it will
not really improve things by an order of magnitude.
Removing all the "lower" functions would be a performance improvement
since it would allow an exact match on the index. However, in this
~ case there is an existing index (alias) which would be almost as
good as yours. Not sure it would be worthwhile to make another
index since "<>" will not benefit from the index, even though IO
will be just slightly faster since the table will not have to be accessed.
I don't know why the lower function has been used. In mysql columns
~ are usually case insensitive unless you define them not to be or use a
case sensitive colation, so the query would work equally well without
lower(). Maybe in the other supported databases it is different
so they are there for compatibility.
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFH76Ned4I3jTtt9EIRAkpyAKDDMceDQR/Mgwy6JZxCF9q4y83EuQCeLBBw
wh0I/HHcGhPrbJnemUD50ig=
=NjdV
-END PGP SIGNATURE-
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
[Dbmail] ascii 96 (GRAVE ACCENT) `in email addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm getting a problem with some email sender addresses rejected by dbmail. As far as I can tell these are spam emails, but the problem is instead of going through to users spam folders as normal they are rejected producing unwanted bounces and also the mta mails to postmaster about the error on the lmtp conversation (the In values are what dbmail lmtp server replies to postfix): Unexpected response from 127.0.0.1[127.0.0.1]:24. Transcript of session follows. ~ In: 220 mail.gufonero.com DBMail LMTP service ready to rock ~ Out: LHLO mail.gufonero.com ~ In: 250-mail.gufonero.com ~ In: 250-PIPELINING ~ In: 250-ENHANCEDSTATUSCODES ~ In: 250 SIZE ~ Out: MAIL FROM:<[EMAIL PROTECTED]> SIZE=2291 ~ Out: RCPT TO:<[EMAIL PROTECTED]> ~ Out: DATA ~ In: 500 No address found. ~ In: 250 Recipient <[EMAIL PROTECTED]> OK ~ In: 554 No valid sender. ~ Out: RSET ~ Out: QUIT ~ In: 250 OK It just needs the ` character added to ValidNetworkChars in serverparent.c. Maybe it was meant to be there already, because I can see ' there twice. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFH/2v7d4I3jTtt9EIRAr+kAJ9HQc/oZObW9mEFmC9ZWp1eh56AbQCgw6Ql lAIzdaGXz3Tizfb2TP7FG7Y= =5Sp4 -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] Local Recipient Verification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | On Wed, 30 Apr 2008, Alan Hodgson wrote: | |>> Tis a good question ... I don't know what causes it offhand, if the |>> resolver otherwise seems to work. It sounds familiar, though .. it |>> seems like you generally use 127.0.0.1 rather than "localhost" for |>> whatever the reason is. |>> |> |> If the lmtp process is running chroot it may be using different hosts and |> resolv.conf files than normal system processes. | | It doesn't seem to be running chroot (note the 5th field is "n"): | dbmail-lmtp unix - - n - - lmtp -o disable_dns_lookups=yes | | Any other ideas? | Postfix by default uses dns via system library calls, what that returns will depend on resolv.conf. The behaviour of dig is not always representative of what the system libraries would return (for example dig does not use the search list of resolv.conf by default). disble_dns_lookups changes that behaviour and postfix uses getaddrinfo() which should also look in /etc/hosts, depending on the setting of /etc/nsswitch.conf or equivalent on your system. Postfix also has a parameter (from version 2.3) lmtp_host_lookup, which defaults to dns but can be set to native (to use nsswitch) or to dns, native. see http://www.postfix.org/postconf.5.html#lmtp_host_lookup http://www.postfix.org/postconf.5.html#smtp_host_lookup John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIG1Ymd4I3jTtt9EIRArGRAJ0VCXA/HdEYKXr24+N1YsFNS0CU8gCbBZKF l78jFMlGjhq/MrWQJB31oQ4= =9e3e -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] [imap] different behaveior between outlook and thunderbird
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Uwe Kiewel wrote: | Hi, | | I can see different behaveior between thunderbird and outlook. | Dbmail-imapd spans only one process per user and connection while using | thunderbird, dbmail-imapd creates a new process every time I access | another folder in my mailbox. Is this a dbmail or a client issue? | | example for outlook: | ~1 user, 5 folders in mailbox -> 1 imapd-process | | example form thunderbird: | ~1 user, 5 folders in mailbox -> 5 impad-processes | the number of connections openned by thunderbird should be controlled by the setting "Max number of server connections to cache" under account settings->server settings->advanced. The default is 5. John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkhmLQIACgkQd4I3jTtt9ELmOgCffWBQ2IN4DbyElM+WN9GCuKM7 UsYAoKL/MDvH9eF5gYU8FFCcF9+XIXzO =1v6f -END PGP SIGNATURE- ___ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] mysterious from-address
It's likely a bug of the sending client (probably a webmail service). Shouldn't the from header contain only ascii encoding? John Aaron Stone wrote: > I've noticed this, too. It's not an added header, it's a mis-decoded > header. I suspect a GMime bug; perhaps Paul has identified which versions > of GMime are buggy in this way? > > Aaron > > > On Wed, 6 May 2009 15:19:41 +0200, Marc Dirix > wrote: > >> Hi >> >> I'm on 2.2.11. >> >> Often some customers receive emails with incorrect (or strangely >> encoded) From headers. This From header then gets mangled >> at some point between reception and delivery. >> >> The newly formed From header has been mangled, and >> @host.domain of the mailserver has been added. >> See here a resulting header: >> >> =?iso-8859-1?q?jos=e9_m._joa...@gamma.electronics-design.nl >> >> If now the customers replies to this, obviously the email is >> not delivered to the original sender. >> >> Is it possible dbmail at some point adds the header? >> Er should I be looking through spamassassin or postfix? >> >> Regards, >> >> Marc >> ___ >> DBmail mailing list >> DBmail@dbmail.org >> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail >> > ___ > DBmail mailing list > DBmail@dbmail.org > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail > ___ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
Re: [Dbmail] mysterious from-address
Paul J Stevens wrote: > John Fawcett wrote: > >> It's likely a bug of the sending client (probably a webmail service). >> Shouldn't the from header contain only ascii encoding? >> > > That's not the point. Even if you are correct (I would assume rfc2047 > would apply to From_ headers as well), we'd like dbmail to gracefully > degrade. > Paul the encoding defined in rfc2047 applies to the word entity that precedes the address-spec, but not as part of the address spec. i.e. From: =?ISO-8859-1?Q?Jos=E9?= is ok and is correctly visualized (thunderbird/dbmail) From: =?iso-8859-1?q?jos=e...@erba.tv looks broken. I have to admit I never tried to define a mailbox with an accented character in it, but I suspect that it would not work reliably. John ___ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
Re: [Dbmail] mysterious from-address
Marc Dirix wrote: > My Point was not the part about not being able to decode, but the part > where dbmail (or gmime) adds an @host.domain after the non-decodable > address. This confuses things. > Marc I'm not convinced that it is dbmail or gmime adding a host part. Do you have an example of the full message headers? John ___ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
Re: [Dbmail] mysterious from-address
Marc Dirix wrote: >> Oops. The README clearly states: >> >> Rewrite "user" to "u...@$myorigin" >> >> This feature is controlled by the boolean append_at_myorigin >> parameter (default: yes). You should never turn off this feature, >> because a lot of Postfix components expect that all addresses have the >> form "u...@domain". >> > I have set it to "no" because of this problem (to see if it would make a > difference, which it doesn't). It also seems not to be related, because > $myorigin is not "gamma.electronics-design.nl" which is the string which > is add in the from header. > > Marc > > Marc the behaviour you're seing can also depend on the setting for the postfix parameter local_header_rewrite_clients. It's hard to tell without knowing the contents of master.cf and the output of postconf -n (and probably this should go to the postfix list) but my guess is that the "from" header is being rewritten when the email is passed back into postfix after spam filtering. How to change this behaviour depends on how you're feeding mail back to postfix. I know how to do this in my setup, but I'm using amavisd-new, which may not be your case. John ___ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
Re: [Dbmail] Problem with international characters in the from field in SquirrelMail
On 23/10/09 20:03, Peter Welzien wrote: > Hi. I'm not sure if the problem I'm having is because of DBMail or > SquirrelMail. I've tried the SquirrelMail mailinglist without getting a > reply. > > I'm having problems with international characters in the from field in > the message list in SquirrelMail 1.4.19. Instead of the actual characters > I see eg. =?iso-8859-1?q?=C5slund_Tr=F6ger=22?= (quoted printable?). See > http://welzien.se/misc/squirrelmail.png for an example. For some reason > the characters look good in the subject field. > > When I open the email, the from field display correctly though. > > The from field in the email header: > From: =?iso-8859-1?Q?Rikard_=C5slund_Tr=F6ger?= > > The problem only occurs in the from field in the message list view. > > I'm using DBMail 2.2.11_rc3-r1. > > I believe that DBMail, mysql and Squirrelmail are all set to UTF8. > > What else can I check to try to find the source of the problem? > > Peter squirrelmail should display quoted printable "from" headers correctly in the message list display. The header above looks fine, but it does look a bit different to the one posted at the link. Are they from the same message? The position of the quoted-printable part is different and also there is a " before the text. The " is probably what causes squirrelmail not to be display the header correctly. John ___ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
Re: [Dbmail] Problem with international characters in the from field in SquirrelMail
On 25/10/09 21:36, Peter Welzien wrote: > On Sun, 25 Oct 2009 21:09:00 +0100, John Fawcett wrote: > > >> The position of the quoted-printable part is different and also there >> is a " before the text. The " is probably what causes squirrelmail >> not to be display the header correctly. >> > The " is not present in the raw mail header. I'm not really sure where it > comes from. > > just to be sure: where did the info about the raw mail header come from? e.g. by querying the database directly? Is it the same value in the header cache table and the message table? John ___ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
Re: [Dbmail] Problem with international characters in the from field in SquirrelMail
On 26/10/09 08:37, Peter Welzien wrote: > On Sun, 25 Oct 2009 22:29:01 +0100, John Fawcett wrote: > > >>> The " is not present in the raw mail header. I'm not really sure where >>> > it > >>> comes from. >>> > >> just to be sure: where did the info about the raw mail header come >> from? e.g. by querying the database directly? >> > I got it when selecting "View Full Header" in SquirrelMail. It looks like > this: > From: =?iso-8859-1?Q?Rikard_=C5slund_Tr=F6ger?= > > >> Is it the same value in the header cache table and the message >> table? >> > The value in dbmail_headervalue is: > "Rikard Åslund Tröger" > looks ok > dbmail_fromfield is: > fromname: Rikard Åslund Tröger > fromaddr: dhettn...@hotmail.com > > looks ok > I don't know if I should look in any other tables. > > the raw message will be in dbmail_messageblks > I've noticed though that the from field displays correctly when using > roundcube. > > it doesn't sound like a dbmail problem. On the other hand my squirrelmail 1.4.19 doesn't have any issues with displaying quoted printable headers arriving from dbmail. But first of all, you need to rule out that there is something wrong with the message header in input, which I guess not but it's worth checking. John ___ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
Re: [Dbmail] Problem with international characters in the from field in SquirrelMail
On 27/10/09 09:30, Peter Welzien wrote: > On Mon, 26 Oct 2009 21:24:13 +0100, John Fawcett wrote: > > > The from line in the dbmail_messageblks table looks ok to me: > From: =?iso-8859-1?Q?Rikard_=C5slund_Tr=F6ger?= > > Does SquirrelMail use any libs for decoding these lines that can cause > these behaviours? > > Whenever I saw problems like this it was due to badly formed input. In this case we're saying that the input looks ok. I think that problems on dbmail are almost certainly ruled out (roundcube displays the info ok) though to verify that 100% you'd have to execute the imap commands that squirrelmail uses against the IMAP server and check the output. So it sounds like the only way to get to the bottom of it is by debugging squirrelmail. Squirrelmail uses functions/mime.php for decoding quote-printable. There is also functions/i18n.php for char set decoding. The problem may not even be in squirrelmail itself but may be in php or in the webserver php.ini settings (mbstring?). At this point I'd suggest debugging the php code or getting help on squirrelmail list. John ___ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
Re: [Dbmail] Problem with international characters in the from field in SquirrelMail
On 28/10/09 14:54, Reindl Harald wrote: > Sometimes we see this too, but i can not reproduce this > > SquirrelMail seems not to be the reason because thunderbird and horde > have also the nearly same problem display a german "Ü". Looks like this > only happens with UTF7/UTF8 > > Header: Benachrichtung zum =?unicode-1-1-utf-7?Q?+ANw-bermittlungsstatus > (Fehlgeschlagen)?= > Thunderbird: Benachrichtung zum =?unicode-1-1-utf-7?Q?+ANw-bermittlungsstatus > (Fehlgeschlagen)?= > Horde: Benachrichtung zum +ANw-bermittlungsstatus (Fehlgeschlagen) > Correct: Benachrichtung zum Übermittlungsstatus (Fehlgeschlagen) > > > Harald Looks like a different problem. I don't think that header follows any RFC. John ___ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
