Victor Duchovni wrote: > On Tue, Dec 02, 2008 at 10:02:37AM -0800, David Jonas wrote: > > >>> What version of Postfix are you using? >>> >> 2.3.8 and 2.4.6-- yea, we're a little behind. Perhaps I'll bring us up >> to 2.5 today. >> > > I am not aware of any "transparency" issues in either of those releases. > You don't need to upgrade. There was once an undesirable interaction > between "transparency" and 8-bit to 7-bit conversion, but that was > in Postfix 2.0 snapshot (at the time called 1.1.N-YYYYMMDD) releases. > This was fixed before 2.0.0. > Updated to 2.5.5
>>>> @@ -92,6 +83,7 @@ >>>> -=20 >>>> +.=20 >>>> >>> Most likely Ebay sending software fails to implement RFC 821/2821/5281 >>> correctly: >>> >>> http://tools.ietf.org/html/rfc5321#section-4.5.2 >>> >>> not much you can do about that. Postfix can't possibly know all >>> the places in which the Ebay software screwed up. >>> >>> The RFC is quite clear, leading "." characters in SMTP are stripped >>> regardless of the following character. Some MTAs only trim "." when >>> the next character is also a ".", but this violates the RFC. >>> >> I will attempt to file a bug with eBay/PayPal. Thanks. I'm going to try >> to set up a clean environment (no processing at all) to make sure this >> is definitely real and not just a side effect. Nothing touches the body >> right now, but the message does get juggled a bit before being sent out >> again. >> > > A tcpdump capturing the SMTP traffic from EBAY should show the lack > of propper "dot-stuffing" in their sending engine. > > If they do it correctly, perhaps you have content filters or down-stream > SMTP senders that are broken. What software other than Postfix do > the messages traverse before forwarding? > > I found the culprit. To get an X-Original-To header on the forwarded emails they get run through pipe and back to postfix with smtpclient (http://www.freebsdsoftware.org/mail/smtpclient.html): xorig unix - n n - - pipe flags=Ohuq user=smtpclient argv=/usr/bin/smtpclient -w -S 127.0.0.1 -P 4525 -f ${sender} -- ${recipient} We also use smtpclient to pass the messages back from spamc to a special port. A quick test showed that smtpclient was stripping that dot. I sincerely apologize for the noise, but I did learn a lot here. Thanks for the help. Any other options besides smtpclient to pass the message back to a different port? This is already a multi-instance setup, one for regular incoming mail/backup mx'ing and another for filtering the local and forwarding mail.