Re: Outgoing mail problem from phone
Den 2012-07-27 10:57, Dominique skrev: The message is not cryptic, I just don't know what to do to fix it... you are outside of mynetworks in postfix term, so postfix will have sasl auth from client to reley Can someone help me out ? Let me know what info is needed. google postfix sasl auth i cant say it more specific before i get more info :)
Re: Postfix 2.9.x vs iptables 1.4.x interaction issues under Debian/Ubuntu
Den 2012-07-27 20:43, Mark Alan skrev: While using Postfix 2.9.3, iptables 1.4.12, under Ubuntu 12.04 LTS, after upgrading to Postfix 2.9.x, using suggest here "apt-get install shorewall" it creates stable firewall
Re: Postfix 2.9.x vs iptables 1.4.x interaction issues under Debian/Ubuntu
On Fri, 27 Jul 2012 14:11:44 -0700, "Daniel L. Miller" wrote: > That's a fairly restrictive matching rule you > have for your new connection state - what worked before might have > changed. May I suggest removing the --syn for starters? Tried your suggestion. The problem persists. Thank you. M.
Re: Postfix 2.9.x vs iptables 1.4.x interaction issues under Debian/Ubuntu
On Fri, 27 Jul 2012 19:43:59 +0100, Mark Alan wrote: > after upgrading to Postfix 2.9.x, using > I am now finding a lot of syslog entries like these: >/var/log/syslog:Jul 27 12:00:32 mx kernel: [485xxx.x] FW >DROP-OUT IN= OUT=eth0 SRC=xx.xxx.xxx.xx DST=xxx.xx.xxx.xx LEN=77 >TOS=0x00 PREC=0x00 TTL=64 ID=x DF PROTO=TCP SPT=x DPT=25 >WINDOW=26280 RES=0x00 ACK PSH URGP=0 A more thorough check revealed that this only happens when requesting VERP style delivery to process a mailing list. Has anything changed in Postfix 2.9.x VERP processing? My VERP settings include: postconf -n | grep 'verp\|recipient_delimiter' recipient_delimiter = + smtpd_authorized_verp_clients = $mynetworks The mailing list is managed by mlmmj (which is a ezmlm clone that works with Postfix under Linux). mlmmj adds XVERP=-= to the MAIL FROM: line. mlmmj needs to set =-= to be able to process owner-listname internally. mlmmj sets verp recipients to 100. grep 'foo:' /etc/aliases # foo is a mailing list =< 1000 subscribers foo: "|/usr/bin/mlmmj-recieve -L /var/spool/mlmmj/foo/" Any other thoughts ? Thank you, M.
Re: Postfix 2.9.x vs iptables 1.4.x interaction issues under Debian/Ubuntu
On Sat, 28 Jul 2012 13:48:55 +0200, Benny Pedersen wrote: > Den 2012-07-27 20:43, Mark Alan skrev: > > > While using Postfix 2.9.3, iptables 1.4.12, under Ubuntu 12.04 LTS, > > after upgrading to Postfix 2.9.x, using > > suggest here "apt-get install shorewall" I am afraid that shorewall is just a front end to iptables. Using that exact same iptables configuration with qmail (instead of Postfix 2.9.x) does not raise any firewall drop-outs. Thank you, M.
Re: Postfix 2.9.x vs iptables 1.4.x interaction issues under Debian/Ubuntu
Mark Alan: > On Fri, 27 Jul 2012 19:43:59 +0100, Mark Alan > wrote: > > > after upgrading to Postfix 2.9.x, using > > I am now finding a lot of syslog entries like these: > >/var/log/syslog:Jul 27 12:00:32 mx kernel: [485xxx.x] FW > >DROP-OUT IN= OUT=eth0 SRC=xx.xxx.xxx.xx DST=xxx.xx.xxx.xx LEN=77 > >TOS=0x00 PREC=0x00 TTL=64 ID=x DF PROTO=TCP SPT=x DPT=25 > >WINDOW=26280 RES=0x00 ACK PSH URGP=0 > > A more thorough check revealed that this only happens when > requesting VERP style delivery to process a mailing list. > > Has anything changed in Postfix 2.9.x VERP processing? Postfix without VERP delivers 1 .. $smtp_destination_recipient_limit (default: 50) recipients per MAIL FROM transaction. If the destination has more than $smtp_destination_recipient_limit recipients, Postfix may make parallel connections; existing connections may be reused, each time sending 1 .. $smtp_destination_recipient_limit recipients per MAIL FROM transaction. Postfix with VERP delivers one recipient per MAIL FROM transaction. If the destination has more than 1 recipient, Postfix may make parallel connections; existing connections may be reused, each time sending one recipient per MAIL FROM transaction. Thus, VERP increases the number of parallel connections. This may result in overflow of state tables in under-powered stateful routers, causing them to drop packets that don't match any existing state. Wietse
Re: Postfix 2.9.x vs iptables 1.4.x interaction issues under Debian/Ubuntu
Mark Alan: > Using that exact same iptables configuration with qmail (instead of > Postfix 2.9.x) does not raise any firewall drop-outs. qmail makes fewer parallel connections than Postfix (especially with Postfix VERP turned on), and so it can overflow state tables that qmail doesn't. Wietse
Re: Postfix 2.9.x vs iptables 1.4.x interaction issues under Debian/Ubuntu
On Sat, Jul 28, 2012 at 09:10:34AM -0400, Wietse Venema wrote: > Thus, VERP increases the number of parallel connections. This may > result in overflow of state tables in under-powered stateful routers, > causing them to drop packets that don't match any existing state. Or perhaps the state tables don't overflow, but rate limits apply regardless of connection state. In fact that would be correct behaviour I think. Rate enforcement has little to do with whether the connection table is full or not... I would guess that the OP's iptables configuration unwisely fails to discriminate between incoming and outgoing traffic. The solution is to exempt traffic sent from the machine from the rate controls. -- Viktor.
Re: the mail server from source problem
On 7/27/2012 10:18 AM, Wietse Venema wrote: > Dennis Clarke: >> Do you think I can figure that one out ? No way. What I do find is >> vast amounts of info about how to put in ClamAV and SSL bits and auth >> bits and endless web pages that point to apt-get and RHEL yum this that >> and the other thing. [1] What I am seeing is that no one seeems to just >> get the sources and "do it". Perhaps my entire understanding and >> philosophy around open source is terribly flawed? > > Of course there are plenty people, but they have prior experience. > > If you have no prior experience, then you should not build a system > from scratch, when you don't even know what a working system is > supposed to look like. > > Instead, your time is better spent learning from a system that > already works. In other words, start with a pre-built distribution. > > Have a wonderful learning experience. > > And please ignore the idiots on this list who say that you are stupid. > > Wietse To drive the prior experience point home, I've been building my own Linux kernels from vanilla source for about 8 years because I don't like stock kernels and hardware drivers as loadable modules, and 15MB kernel files when 1.7MB works fine. I'm very comfortable with it and get the results I want. There was a steep learning curve, not for the process, but understanding which of the 1000s of configuration options I needed to understand and change to meet my goals. If I wanted to or really had a need to, I'm sure I could build my own Postfix and Dovecot and etc from source. But given how well the Debian packaging system works, and the fact their Backports repo tends to keep up fairly closely with Postfix releases, I see no point in embarking upon yet another learning curve with no tangible payoff. I've better things to do these days with my time. I don't build any applications from source, only my kernels. I'm probably bass ackwards in this regard compared to many/most others. -- Stan
Re: Postfix 2.9.x vs iptables 1.4.x interaction issues under Debian/Ubuntu
On Sat, Jul 28, 2012 at 11:42 AM, Viktor Dukhovni < postfix-us...@dukhovni.org> wrote: > On Sat, Jul 28, 2012 at 09:10:34AM -0400, Wietse Venema wrote: > > > Thus, VERP increases the number of parallel connections. This may > > result in overflow of state tables in under-powered stateful routers, > > causing them to drop packets that don't match any existing state. > > Or perhaps the state tables don't overflow, but rate limits apply > regardless of connection state. In fact that would be correct > behaviour I think. Rate enforcement has little to do with whether > the connection table is full or not... > > I would guess that the OP's iptables configuration unwisely fails > to discriminate between incoming and outgoing traffic. The solution > is to exempt traffic sent from the machine from the rate controls. > > -- > Viktor. > Dear friends, The systlog lines grabbed at the first e-mail for this thread shows clearly that iptables is dropping the packet because of the statement below, the only one that logs with "FW DROP-OUT" header: -A OUTPUT -m limit --limit 30/m --limit-burst 3 -j LOG --log-level notice --log-prefix "FW DROP-OUT " Adding the information on other e-mails in this thread that it only occurs when sending a great number of e-mais at speed, it seems to me that you should set your limit too little (30/m). May be you should set it to something like 200/m and see if that can get you out of your problem. Also, take care of limit-burst, the default is 5 and you limit it to 3. I understand that defaults are far from specific, they are general numbers, that are good for stations, not servers. I would use limit with great care. I also recommend you to send your initial mail to an iptables mailing list, instead of postfix. I believe the problem is with iptables statements instead of postfix. Fernando Maior
Recipient delimiter
Hi guys, I currently have a postfix setup with virtual users on a mysql database and dovecot as lda. I wanted to implement the "+" separator to route specific messages to a custom destination folder (within the account). Can I do that directly in postfix or should I create ad-hoc rules in dovecot (eg sieve) to do it? Moreover, I have recipient_bcc_maps on and the user requiring the delimiter is listed there. Will the separator have any impact on that? Thanks! Andrea
[SOLVED] Postfix 2.9.x vs iptables 1.4.x interaction issues under Debian/Ubuntu
On Sat, 28 Jul 2012 14:42:59 +, Viktor Dukhovni wrote: > On Sat, Jul 28, 2012 at 09:10:34AM -0400, Wietse Venema wrote: > > > Thus, VERP increases the number of parallel connections. This may > > result in overflow of state tables in under-powered stateful > > routers, causing them to drop packets that don't match any existing > > state. > > Or perhaps the state tables don't overflow, but rate limits apply > regardless of connection state. In fact that would be correct > behaviour I think. Rate enforcement has little to do with whether > the connection table is full or not... [SOLVED] It was rate limiting kicking in. As it should. I was unaware that Postfix could be so fast while VERP'ing. This postfix setup resides in a fairly modest Xen VPS server. Due to strict policies that we must comply with, it has fairly conservative --limit and --limit-burst settings. And, as expected, when those limits are topped those extra packets get logged and trapped by the final "-A OUTPUT -j DROP"). > I would guess that the OP's iptables configuration unwisely fails > to discriminate between incoming and outgoing traffic. Not in this case. All streams (and not only INPUT and OUTPUT) are fully discrete, have their own needs and their own policies. > The solution is to exempt traffic sent from the machine from the rate > controls. In 2012, in a server facing the net and running other services besides mail, I would not call it a safe bet. In the event (that must be accounted for) of an intrusion, one should consider that a syn flood DOS isn't an exclusive of the INPUT stream. Thank you all, M.
Re: Recipient delimiter
On 2012-07-28 Andrea Gozzi wrote: > I currently have a postfix setup with virtual users on a mysql database > and dovecot as lda. > I wanted to implement the "+" separator to route specific messages to a > custom destination folder (within the account). > > Can I do that directly in postfix or should I create ad-hoc rules in > dovecot (eg sieve) to do it? > Moreover, I have recipient_bcc_maps on and the user requiring the > delimiter is listed there. Will the separator have any impact on that? Postfix delivers to mailboxes. It doesn't know or care about the inner workings of a mailbox. For placing a message in a particular folder inside a mailbox you have to use sieve. Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky
Re: Postfix 2.9.x vs iptables 1.4.x interaction issues under Debian/Ubuntu
Den 2012-07-28 14:45, Mark Alan skrev: I am afraid that shorewall is just a front end to iptables. Using that exact same iptables configuration with qmail (instead of Postfix 2.9.x) does not raise any firewall drop-outs. respect, C is just a gui front end for ASSEMBLER postfix will be much faster if writed in portable code i am now inavaible
Re: the mail server from source problem
Den 2012-07-27 17:26, Dennis Clarke skrev: And please ignore the idiots on this list who say that you are stupid. I always do and know better regardless. Also, thank you for truely wonderful software that saves me from SendMail. and sendmail people will say the same to qmail :=)
Cannot smtp unless logon before sending
Hi all, I've already finished a Postfix server setup with virtual users and Dovecot as virtual transport. I just cannot find out why MS Outlook fails the smtp test unless I check the "Log on to incoming mail server before sending mail" on the More settings/ Outgoing Server tab. Thanks in advance for any hint you can help. -- Best regards, Gmail-teopro mailto:teo...@gmail.com
Re: the mail server from source problem
- Original Message - From: Stan Hoeppner Date: Saturday, July 28, 2012 12:14 pm Subject: Re: the mail server from source problem To: postfix-users@postfix.org > On 7/27/2012 10:18 AM, Wietse Venema wrote: > > Dennis Clarke: > >> Do you think I can figure that one out ? No way. What I do > find is > >> vast amounts of info about how to put in ClamAV and SSL bits and auth > >> bits and endless web pages that point to apt-get and RHEL yum this > that > >> and the other thing. [1] What I am seeing is that no one seeems to > just > >> get the sources and "do it". Perhaps my entire understanding and > >> philosophy around open source is terribly flawed? > > > > Of course there are plenty people, but they have prior experience. > > > > If you have no prior experience, then you should not build a system > > from scratch, when you don't even know what a working system is > > supposed to look like. > > > > Instead, your time is better spent learning from a system that > > already works. In other words, start with a pre-built distribution. > > > > Have a wonderful learning experience. > > > > And please ignore the idiots on this list who say that you are stupid. > > > > Wietse > > To drive the prior experience point home, I've been building my own > Linux kernels from vanilla source for about 8 years because I don't like > stock kernels and hardware drivers as loadable modules, and 15MB kernel > files when 1.7MB works fine. I'm very comfortable with it and get the > results I want. There was a steep learning curve, not for the process, > but understanding which of the 1000s of configuration options I needed > to understand and change to meet my goals. > > If I wanted to or really had a need to, I'm sure I could build my own > Postfix and Dovecot and etc from source. Actually that was the easy part. Did that with no real problem and have been building bins from various software projects for years. No biggie. > But given how well the Debian > packaging system works, and the fact their Backports repo tends to keep > up fairly closely with Postfix releases, I see no point in embarking > upon yet another learning curve with no tangible payoff. I've better > things to do these days with my time. However what if you are running a T5240 Niagara Sparc server with Solaris 10 ? This is where I wander off the Linux reservation. > I don't build any applications from source, only my kernels. I'm > probably bass ackwards in this regard compared to many/most others. You know, funny enough I have a whole collection of weird and interesting servers. Once upon a time I install Red Hat 6.2 ( zoot ) onto a Sparc 20 server with no reason other than to follow the Linux from Scratch project guide. I di the same thing on some embedded Motorola PowerPC equipment and the process is very educational. I even have an old DEC Alpha in my pile. As for building my own kernel? Well I would love to really. However, as you say, the learning curve is a real mountain to climb and takes a pile of man hours. So I decided to simply stick with the task at hand which was a really minimal postfix dovecot config. I plan to go back and fight with that some more later today in fact. Dennis
Re: [SOLVED] Postfix 2.9.x vs iptables 1.4.x interaction issues under Debian/Ubuntu
Am 28.07.2012 20:03, schrieb Mark Alan: >> The solution is to exempt traffic sent from the machine from the rate >> controls. > > In 2012, in a server facing the net and running other services besides > mail, I would not call it a safe bet. In the event (that must be > accounted for) of an intrusion, one should consider that a syn flood > DOS isn't an exclusive of the INPUT stream if you do not trust you OUTGOING traffic the only valid reason is that you doubt your machine is comprimised in this case shut it down and NO a synflood will never come in the OUTPUT stream except your machine is compromised, but if so shut it down signature.asc Description: OpenPGP digital signature
