zedshaw / lamson Goto Github PK

>>> msg1 = email.message_from_string("To: Person1 <[email protected]>, Person2\n\t<[email protected]>")
>>> msg2 = email.message_from_string("To: =?utf-8?q?Emil_Stenstr=C3=B6m?= <[email protected]>, Person2\n\t<[email protected]>")
>>> print encoding.to_message(encoding.from_message(msg1))
From nobody Tue Dec  3 12:42:05 2013
MIME-Version: 1.0
To: Person1 <person1@domain.com>, Person2
    <person2@domain.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
>>> print encoding.to_message(encoding.from_message(msg2))
From nobody Tue Dec  3 12:42:09 2013
MIME-Version: 1.0
To: "=?utf-8?q?Emil_Stenstr=C3=B6m?=" <person1@domain.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Note that the from_message step seems to work fine:

>>> print encoding.from_message(msg2)["to"]
Emil Stenström <person1@domain.com>, Person2
    <person2@domain.com>

If you use some -arg it will be set to True. You can also pass -arg True and it will be still set to True. But you cannot pass False in any way, you can only pass "False" which is pointless and misleading.

I've also found http://pydoc.net/lamson/0.9/lamson.args which says "if you give a boolean then your users can indicate that boolean is true by giving just the option (-horribly) or specify the truth (-horribly False)" which is even more misleading (maybe that's why it was removed in later versions).

There is a small typo in lamson/server.py.
Should read receives rather than recieves.

Individually-encoded base64 chunks must be decoded separately
due to padding at the end of base64-encoded chunks. Concatenating
base64 chunks and then decoding them may result in a different string
than decoding and then concatenating.

Lamson currently concatenates the base64 encoded chunks and then decodes them, potentially resulting in a different message than originally sent.

However, the characterset decoding into unicode must be done jointly,
since some mail clients will split the base64 encoding in the middle
of Unicode characters

I wanted to play with Lamson on a Windows 7 system. Unfortunately, python-daemon won't install. A similar issue (for another python app) and fix is documented here:

python-beaver/python-beaver#141

Perhaps an equivalent code change will work for Lamson.

When testing lamson I was able to reproduce the following on

ubuntu 10.04 and
Lamson-Version: 1.1
Repository-Revision: c74b850cf2
Repository-Hash: c74b850cf2f78e0397ee48338de99eaad543f668

I'm able to start and stop lamson but never able to start lamson again because the 'lock' file doesn't get cleaned up...

Steps to reproduce:

fox@cammy:/mymailserver$
fox@cammy:/mymailserver$ lamson status
Lamson not running.
fox@cammy:/mymailserver$ ll run
total 12
drwxr-xr-x 3 fox fox 4096 2011-11-12 03:53 ./
drwxr-xr-x 7 fox fox 4096 2011-11-12 03:48 ../
drwx------ 5 fox fox 4096 2011-11-12 03:48 undeliverable/
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$ lamson start
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$ lamson status
Lamson running with PID 8509
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$ ll run
total 16
drwxr-xr-x 3 fox fox 4096 2011-11-12 03:54 ./
drwxr-xr-x 7 fox fox 4096 2011-11-12 03:48 ../
-rw-rw-rw- 2 fox fox 0 2011-11-12 03:54 cammy.MainThread-8507
-rw-r--r-- 1 fox fox 5 2011-11-12 03:54 smtp.pid
-rw-rw-rw- 2 fox fox 0 2011-11-12 03:54 smtp.pid.lock
drwx------ 5 fox fox 4096 2011-11-12 03:48 undeliverable/
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$ lamson stop
Stopping processes with the following PID files: ['./run/smtp.pid']
Attempting to stop lamson at pid 8509
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$ lamson status
Lamson not running.
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$ ll run
total 12
drwxr-xr-x 3 fox fox 4096 2011-11-12 03:54 ./
drwxr-xr-x 7 fox fox 4096 2011-11-12 03:48 ../
-rw-rw-rw- 2 fox fox 0 2011-11-12 03:54 cammy.MainThread-8507
-rw-rw-rw- 2 fox fox 0 2011-11-12 03:54 smtp.pid.lock
drwx------ 5 fox fox 4096 2011-11-12 03:48 undeliverable/
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$ lamson start
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$ lamson status
Lamson not running.
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$
fox@cammy:/mymailserver$ ...

Last news is from 2010, and the switch to git is not reflected (documentation points to fossil installation and so on), part of the links in «what's built with lamson» list are dead, only the redirection from support.lamson.org gets you there to learn the project is indeed not dead.

Is the website hard to update, is Zed too busy with other things? Are contribution in this area needed (no promise i would, but good to know) or are there other things preventing the project to thrive?

http://lamsonproject.org/docs/html_email_generation.html

On the documentation for html email generation the id #bright and the class .dull is used. Yet in the example the html states class="bright" and id="dull".

the lamsonserver.org website is down, is this project being discontinued.

The clause in the license that allows the rights holder to revoke the license, namely

'5. The copyright holder reserves the right to revoke this license on anyone who
uses this copyrighted work at any time for any reason.
makes it impossible to use lamson in any serious project.'

I don't have any problem with the other clauses, but if this is not changed, I'd have to use the version from 2 years ago without the clause.

Why does not lamson show up on https://zedshaw.com/dead-projects/ ?
;)

Hi there,

while researching lamson, I noticed that the pypi page does not contain neither a link to the homepage of lamson nor a link to the github page (assuming this is the focus of development and where I am supposed to report bugs).

The lamson homepage has the same problem.

Please fix, by linking the relevant pages on pypi and the lamson homepage so it is easy to go to the right places that are relevant for lamson development.

Thanks!

http://lamsonproject.org/docs/getting_started.html

There are several problems with the code samples.

The closing quotes are turned into their slanted equvalents, which messes up the syntax highlighting, and the comments are turned into HTML ordered lists.

The README.md says

using the best technology currently available.

But the last commit to the project was on 2013-03-07, more than 10 years ago.

So the sentence is probably false by now.

Please update the README.md accordingly.

Regards!

At page http://lamsonproject.org/releases/ is a broken link to http://support.lamsonproject.org/vinfo/1.0

In the case of headers, wrapped per RFC 2822 §2.2.3 and MIME-encoded per RFC 2047, lamson.encoding._parse_charset_header combines encoded-text parts of all encoded-words together and passes the result to lamson.encoding.apply_charset_to_header. This is clearly wrong and if some base64-encoded encoded-word is padded (i.e. ends with =), the result will be trimmed after this point on decoding. This means that in a lot of cases the parsed header value will be shorter than it should be. I'm also worried about support of headers that simultaneously include B-encoded and Q-encoded encoded-words and unencoded text which is possible per RFC 2047 §5(1).

Following is the setup I've got:

1. lamson installed inside python virtualenv on ubuntu server
2. lamson receiver configured to listen on TCP port 25
3. exim4 configured on same server to listen on TCP port 2500 for relay
4. lamson relays i.e. passes on mails it receives to exim

Issue:

1. When put multiple recipients in 'To', lamson sends as many mails as the number of recipients to first recipient only and nothing goes to rest of them
2. When put 1 recipient in 'To' and rest in 'cc', lamson sends as many mails as the number of recipients to recipient listed in 'To'; nothing goes to rest of recipients.

Commands included in docs such as lamson start -pid ./run/smtp.pid -FORCE False -chroot False -chdir "." -umask False -uid False -gid False -boot config.boot do not and cannot work because "False" here is not even a bool, it is a string, while that args require ints:

daemon.daemon.DaemonOSEnvironmentError: Unable to change file creation mask (an integer is required)

etc.

Despite prominent notices about caring about Unicode lamson breaks outgoing headers too.

lamson.encoding.properly_encode_header uses email.charset.Charset.header_encode which doesn't know about splitting multibyte sequences and asks to use email.header.Header instead. As the result, headers in message objects created by lamson may include utf8 characters broken between their bytes.