Problem with notification e-mails

[mtutak@…]

SMTPD dialog goes like this:

connect from xxx[10.2.5.43]
> xxx[10.2.5.43]: 220 mail.yyy ESMTP Postfix (Debian/GNU)
< xxx[10.2.5.43]: quit
> xxx[10.2.5.43]: 221 Bye
disconnect from xxx[10.2.5.43]

In the result no emails was send.

[bencollins@…]

I also have this problem. My mail server is postfix. Trac connects and disconnects without actually sending an email.

[fiid@…]

I see exactly the same behaviour. Is this a known (common) issue with postfix? Any workarounds?

Thanks,

Fiid.

[tomas@…]

same here, postfix 2.1.5

[tomas@…]

traceback below. i guess it's not related to mail server version :)

13:45:04 Trac[Notify] DEBUG: Sending SMTP notification to stoned.lan on port 25 13:45:04 Trac[web_ui] ERROR: Failure sending notification on change to ticket #8: len() of

unsized object

Traceback (most recent call last):

File "/usr/local/lib/python2.4/site-packages/trac/ticket/web_ui.py", line 301, in _do_sa

ve

tn.notify(ticket, newticket=False, modtime=now)

File "/usr/local/lib/python2.4/site-packages/trac/Notify.py", line 218, in notify

NotifyEmail.notify(self, ticket.id, subject)

File "/usr/local/lib/python2.4/site-packages/trac/Notify.py", line 118, in notify

Notify.notify(self, resid)

File "/usr/local/lib/python2.4/site-packages/trac/Notify.py", line 57, in notify

self.send(to)

File "/usr/local/lib/python2.4/site-packages/trac/Notify.py", line 336, in send

NotifyEmail.send(self, rcpt, hdrs)

File "/usr/local/lib/python2.4/site-packages/trac/Notify.py", line 151, in send

self.server.sendmail(self.from_email, rcpt, msg.as_string())

File "/usr/local/lib/python2.4/email/Message.py", line 129, in as_string

g.flatten(self, unixfrom=unixfrom)

File "/usr/local/lib/python2.4/email/Generator.py", line 82, in flatten

self._write(msg)

File "/usr/local/lib/python2.4/email/Generator.py", line 120, in _write

self._write_headers(msg)

File "/usr/local/lib/python2.4/email/Generator.py", line 166, in _write_headers

header_name=h, continuation_ws='\t').encode()

File "/usr/local/lib/python2.4/email/Header.py", line 392, in encode

newchunks += self._split(s, charset, targetlen, splitchars)

File "/usr/local/lib/python2.4/email/Header.py", line 277, in _split

elen = charset.encoded_header_len(encoded)

File "/usr/local/lib/python2.4/email/Charset.py", line 318, in encoded_header_len

return len(s)

TypeError: len() of unsized object

[dmbrucker@…]

I can recreate the problem described by the original reporter and the first few commentors just by having always_notify_owner=false and always_notify_reporter=false, which is the default, in the trac.ini. I think, having just read through the code and testing a little bit, that without either of the above set to true, emails will only be sent to the CC list for a ticket. So, by default, a ticket with an empty CC list is an email no-op. I tested this with both Postfix 2.2.2 and Sendmail 8.13.4, and both show a connection followed by immediate closure. So, I don't think this has anything to do with MTA or version.

However, I can't recreate the stacktrace of the final poster. Can you all check your configs and if you're still having problems post the notification section, trac version, python version, and any pertinent details about the tickets that cause these errors, like the reporter, owner, and CC fields.

Eg.

[notification]
always_notify_owner = false
smtp_always_cc =
smtp_password =
smtp_enabled = true
smtp_replyto = trac@localhost
smtp_port = 25
always_notify_reporter = false
smtp_server = localhost
smtp_from = trac@localhost
smtp_user =

Trac v0.8.4
Python v2.4.1
Reporter: someguy@mysite.com
Owner: programmer@mysite.com
CC: dev@mysite.com, joe@mysite.com

[tomas@…]

mails are sent out, everything is ok.

Trac log contains just

13:37:26 Trac[Notify] DEBUG: Sending SMTP notification to mailserver on port 25

notification config:

[notification]
always_notify_owner = true
always_notify_reporter = true
smtp_enabled = true
smtp_replyto = office@mailserver
smtp_port = 25
smtp_server = mailserver
smtp_from = trac@tracserver

trac version:

URL: http://svn.edgewall.com/repos/trac/trunk
Repository UUID: af82e41b-90c4-0310-8c96-b1721e28e2e2
Revision: 2116
Node Kind: directory
Schedule: normal
Last Changed Author: cboos
Last Changed Rev: 2116
Last Changed Date: 2005-08-23 09:20:47 +0000 (Tue, 23 Aug 2005)
Properties Last Updated: 2005-08-23 12:18:35 +0000 (Tue, 23 Aug 2005)

[dmbrucker@…]

I can't reproduce this problem and I think this ticket can probably be safely closed. I've tried with Sendmail and Postfix is several configurations, both local and remote, with different versions of Python and Trac 0.8.4 through devel. In each case, when Trac is properly configured and the tickets match the criteria for emailed notifications, they are properly sent. Since tomas@… has reported success and there havn't been any other responses, I suggest the issue be closed, but I'll defer to jonas.

[Matthew Good]

Ok, well the reporters of this don't seem to be able to reproduce it anymore, so I think it's safe to close.

[chris.shenton@…]

I encountered this in 0.8.4 when I had

always_notify_cc =

with no address specified. Filling this in got the notifications working. Perhaps if you don't want to always_notify_cc you should just comment it out?

Would be nice if the config file parser warned of this problem.

[mcquayb@…]

I have this same problem using Trac 0.8.4. Postfix works fine and I have verified this by telnetting to port 25 and manually sending mail. Local mail through mutt works as well. Postfix version 2.1.5

logs (fqdn and ip have been replaced for this posting):
Oct 5 12:17:05 wikiserver postfix/smtpd1204: connect from fqdn[ip]
Oct 5 12:17:05 wikiserver postfix/smtpd[1204]: disconnect from fqdn[ip]

This is repeated each time I create or close a ticket.

trac.ini: [notification] smtp_enabled = true smtp_server = ip smtp_from = trac@fqdn

[Matthew Good]

No further 0.8.x releases are planned, so unless you can reproduce this problem on 0.9 it won't be fixed.

[anonymous]

This can also be caused by:

a) having a trac login b) not having your email preference set!

Make sure all users have set an email addr.