Zoltan Balogh a écrit : > On Thu, Feb 26, 2009 at 8:50 PM, Magnus Bäck <mag...@dsek.lth.se> wrote: >> On Thursday, February 26, 2009 at 19:57 CET, >> Zoltan Balogh <zee.bal...@gmail.com> wrote: >> >>> On 2/26/09, Victor Duchovni <victor.ducho...@morganstanley.com> wrote: >>> >>>> Note, this notion of "correctness" is not one of those pedantic >>>> types of "correctness" that is "optional". Systems that forward mail >>>> to all header recipients are severely broken, and will cause mail >>>> loops, blacklisting by annoyed incorrect recipients, abuse by >>>> spammers, ... >>>> >>>> So in short, forwarding systems must PRESERVE the original message >>>> envelope and must not re-create fresh envelopes from message To/Cc >>>> headers. >>> Preserving an original envelope is relevant only for SMTP >>> communication. >> Why would you say that? > Maybe I misunderstood what was meant by "preserving the original > message envelope". I was thinking in terms of preserving the envelope > through SMTP communication forwarding. >
Yes. Mail routing is based on the envelope. informations found in To/Cc headers must not be used to route mail. so once again: routing mail based on To/CC headers is broken. consider what happens if you use the To and CC headers of this list mail? you would redeliver the message to the list, and so on... >>> So the idea of fetching mail by POP3 and then forward >>> it to mail recipients parsed from fetched email header is generally a >>> bad idea? >> Yes, of course. The To and Cc headers have nothing at all to do with the >> intended recipient addresses. >> >>> But if I am not wrong that's exactly what fetchmail No. this is one of the features of fetchmail, and one that is explicitely discouraged. I have fetchmail running on this server for a few accounts, and it's not using headers at all. the recipient is specified in the fetchmailrc file. >>> and POP3 >>> mail proxies do which pop3 proxy forward mail via smtp? > - so all these systems are not correct and not >>> recommended to use? I usually use transport mechanism of postfix >>> to forward a SMTP communication to other mail server. Use of fetchmail >>> is a server2-user requirement. >> Multidrop POP is broken iff headers are used to determine the >> recipients. > This is what I read on the fetchmail man page > http://fetchmail.berlios.de/fetchmail-man.html#2 : > > "... fetchmail must resort to a process of informed guess-work in an > attempt to discover the true envelope recipient of a message, unless > the ISP stores the envelope information in some header (not all do)." > http://www.catb.org/~esr/fetchmail/fetchmail-FAQ.html has a 8 questions about multi-drop box problems. > So basically I just need to help fetchmail "guessing" the correct > envelope recipients by appending "X-Envelope-To" (or similar header > entry) to the email message. I did the following: > > smtpd_recipient_restrictions = > ... > check_recipient_access pcre:/etc/postfix/recipient_access > > /etc/postfix/check_recipient_access: > /(....@somedomain.com)/ PREPEND X-Envelope-To: <$1> > there's something I don't understand. you send mail via postfix to a remote server, then you fetch that same mail back? anyway, while your postfix tricks may change mail that passes via your postfix, it won't touch mail that is sent from external servers. back to square 0. > and it works. It adds the "X-Envelope-To:" information for Bcc: > recipients what should be sufficient for fetchmail. The > "X-Envelope-To:" information is added only for somedomain.com > recipients so other domain emails are not affected. so now, all recipients see who was Bcc'ed, thus defeating the purpose of Bcc. > I could not find a > different solution. If there is any please let me know. > fix the problem at the source: give each user his own mailbox. then each mailbox is associated with a single recipient, and fetchmail can use this via fetchmailrc: set postmaster <postmas...@netoyen.net> set no bouncemail defaults proto pop3 smtphost 127.0.0.1/25 poll pop.isp.example user "remotejoe" there has password "hispass" is "local...@example.com" here ...
