|Summary:||Qmail is strictly RFC w/ regards to bare LFs, email by bad host rejected by default|
|Product:||Gentoo Linux||Reporter:||Paul Sumner <paul>|
|Component:||Current packages||Assignee:||Net-Mail Packages <net-mail+disabled>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Paul Sumner 2004-11-16 10:39:39 UTC
This is a feature request... Qmail will be default reject badly formatted emails, i.e., emails with bare line feeds in them. You will see in your qmail-smtpd log a message pointing to: http://cr.yp.to/docs/smtplf.html or "Stray newlines" DJB has the following to fix this issue if you wish to receive mail from such hosts: http://cr.yp.to/ucspi-tcp/fixcrio.html This can be run by editing /var/qmail/control/conf-smtpd (in the qmail install setup by the ebuild) the preline var to look like: # Stuff to run before tcpserver QMAIL_TCPSERVER_PRE="/usr/bin/fixcrio" It would be nice to have this in the conf by default, if even commented out or as part of the config part of the install. Thanks much. Reproducible: Always Steps to Reproduce: 1. emerge qmail 2. receive email from a old or non RFC compliant smtp server 3. look for errors in smtpd log/some mail rejected
Comment 1 Paul Sumner 2004-11-16 10:48:45 UTC
Oops. Actually, it should be the cmd right before qmail-smtp: # Stuff to run before tcpserver #QMAIL_TCPSERVER_PRE="" # Stuff to run qmail-smtpd QMAIL_SMTP_PRE="/usr/bin/fixcrio"
Comment 2 Michael Hanselmann (hansmi) (RETIRED) 2005-01-03 13:31:32 UTC
Added to files/conf-smtpd, could you test it, please?
Comment 3 Paul Sumner 2005-01-03 14:29:57 UTC
Sure. Is the change in cvs HEAD? --I'm not finding it.
Comment 4 Michael Hanselmann (hansmi) (RETIRED) 2005-01-04 10:02:11 UTC
It is already on the rsync-mirrors, but you have to remerge qmail after an
Comment 5 Michael Hanselmann (hansmi) (RETIRED) 2005-01-04 10:02:11 UTC
It is already on the rsync-mirrors, but you have to remerge qmail after an «emerge --sync» and merge (or replace, but you may have to be careful) /var/qmail/control/conf-smtpd. Then you have to enable fixcrio in there, line 17.
Comment 6 Paul Sumner 2005-01-04 11:07:47 UTC
OK. I have a new server coming in today. I will just build it up w/ the new version (conf file) and report back.
Comment 7 Paul Sumner 2005-01-05 22:41:43 UTC
I sync'd, unmerged and remerged. I see the conf line change and it looks good. I've tested minimally and will be testing further with as I burn-test setup this new email server. I did notice 1 issue on my already setup email server at home. It appears that fixcrio may break ssl/tls; although, I need to verify my setup is correct to rule out user error and rule out a bad setup on the other end. To test this I used the following host: from usacycling.org (HELO pedal.usacycling.ORG) (18.104.22.168) by 192.168.1.2 with AES256-SHA encrypted SMTP; 5 Jan 2005 22:18:40 -0800 ..had it send me mail w/ and w/o fixcrio and found that qmail on my end would generate: @4000000041dcd80b0065863c tcpserver: pid 13510 from 22.214.171.124 @4000000041dcd80b077078ec tcpserver: ok 13510 :192.168.1.2:25 usacycling.org:126.96.36.199::60034 @4000000041dcd80b0f959214 tcpserver: end 13510 status 256 @4000000041dcd80b0f9599e4 tcpserver: status: 0/40 I seem to recall 256 being bad and my mail 1st (w/ fixcrio enabled) msg seems to get deferred. I'm not an expert on ssl/tls mail, but I imagine if fixcrio is changing the msg by removing those bare lfs then this might make sense. Although it would only then affect email servers generating ssl/tls msgs w/ bare lfs ;-)
Comment 8 Michael Hanselmann (hansmi) (RETIRED) 2005-01-06 04:21:35 UTC
Hello Paul Thanks for the first test reports. It's very likely that fixcrio will break SSL/TLS. fixcrio replaces chars in the stream and SSL/TLS doesn't like that. However, I did not test it, because the current (old) SSL/TLS-patch is somehow broken on non-x86 platforms (I'm working on PowerPC). That's the cause why I'm currently integrating a new version of the patch and that needs a lot of rediffing. :/ Greets, Michael
Comment 9 Paul Sumner 2005-01-22 22:37:30 UTC
Hey Michael, Sorry for the delayed reply ;-) ....been busy w/ another server that was very problematic. Tuesday I finally begin work on our new email server. FYI, it is amd64. I'll report back how it goes.