[no subject]
I can see the mail coming but doesn't show up in the inbox.. Anyone have any ideas? Dec 31 13:35:35 kraner postfix/qmgr[2803]: 7109B40AB8: from=, size=1704, nrcpt=1 (queue active) Dec 31 13:35:35 kraner postfix/local[2958]: 7109B40AB8: to=, relay=local, delay=0.16, delays=0.14/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir) Dec 31 13:35:35 kraner postfix/qmgr[2803]: 7109B40AB8: removed Dec 31 13:36:05 kraner postfix/smtpd[2953]: disconnect from mail-ob0-f171.google.com[209.85.214.171] Dec 31 13:36:24 kraner postfix/postfix-script[3077]: refreshing the Postfix mail system Dec 31 13:36:24 kraner postfix/master[839]: reload -- version 2.9.3, configuration /etc/postfix Dec 31 13:36:24 kraner postfix/anvil[2955]: statistics: max connection rate 1/60s for (smtp:209.85.214.171) at Dec 31 13:35:35 Dec 31 13:36:24 kraner postfix/anvil[2955]: statistics: max connection count 1 for (smtp:209.85.214.171) at Dec 31 13:35:35 Dec 31 13:36:24 kraner postfix/anvil[2955]: statistics: max cache size 1 at Dec 31 13:35:35
Re:
do you check if the maildir is really from that user? maybe any UID duplicated in the passwd? 2012/12/31 : > I can see the mail coming but doesn't show up in the inbox.. Anyone have > any ideas? > > Dec 31 13:35:35 kraner postfix/qmgr[2803]: 7109B40AB8: > from=, size=1704, nrcpt=1 (queue active) > Dec 31 13:35:35 kraner postfix/local[2958]: 7109B40AB8: > to=, relay=local, delay=0.16, delays=0.14/0.01/0/0.01, > dsn=2.0.0, status=sent (delivered to maildir) > Dec 31 13:35:35 kraner postfix/qmgr[2803]: 7109B40AB8: removed > Dec 31 13:36:05 kraner postfix/smtpd[2953]: disconnect from > mail-ob0-f171.google.com[209.85.214.171] > Dec 31 13:36:24 kraner postfix/postfix-script[3077]: refreshing the > Postfix mail system > Dec 31 13:36:24 kraner postfix/master[839]: reload -- version 2.9.3, > configuration /etc/postfix > Dec 31 13:36:24 kraner postfix/anvil[2955]: statistics: max connection > rate 1/60s for (smtp:209.85.214.171) at Dec 31 13:35:35 > Dec 31 13:36:24 kraner postfix/anvil[2955]: statistics: max connection > count 1 for (smtp:209.85.214.171) at Dec 31 13:35:35 > Dec 31 13:36:24 kraner postfix/anvil[2955]: statistics: max cache size 1 > at Dec 31 13:35:35 > >
Re:
On 2012-12-31, ma...@kraner.us wrote: > I can see the mail coming but doesn't show up in the inbox.. Anyone have > any ideas? where's the mailbox of the user? Did you set something special for "mail_location" in your Dovecot configuration? If not, mabye the auto detection doesn't work? Maybe Dovecot looks in another directory? Could you post the output of "dovecot -n"? Daniel
Re: your mail
ma...@kraner.us: > I can see the mail coming but doesn't show up in the inbox.. Anyone have > any ideas? ... > Dec 31 13:35:35 kraner postfix/local[2958]: 7109B40AB8: > to=, relay=local, delay=0.16, delays=0.14/0.01/0/0.01, > dsn=2.0.0, status=sent (delivered to maildir) Where *is* it supposed to be delivered? http://www.postfix.org/postconf.5.html#home_mailbox http://www.postfix.org/postconf.5.html#mail_spool_directory Wietse
Re: postfix mysql lookup table has some kind of caching?
Wietse Venema porcupine.org> writes: > It is not a major effort to give those cache entries a finite > time-to-live but this needs a better justification that what appears > to be an attempt to circumvent Yahoo rate limits. I have a need similar to the original poster. In my case the use case is to gradually move outgoing traffic to a new egress IP. I have separate transports set up in master.cf per address like this: smtp unix - - - - - smtp out1 unix - - - - 50 smtp \ -o smtp_bind_address=10.150.15.101 out2 unix - - - - 50 smtp \ -o smtp_bind_address=10.150.15.102 [...] and additionally the senders are partitioned across IPs with sender_dependent_default_transport_maps Moving a big chunk of traffic in one go to a new IP that was never sending any traffic before will just cause it to get greylisted or blocked altogether. Given I have a low number of high-volume senders, I cannot find an easy way to start sending (say) 1% of given sender's traffic from a new IP. Any suggestions? Marcin
Re: postfix mysql lookup table has some kind of caching?
Marcin Owsiany: > Wietse Venema porcupine.org> writes: > > It is not a major effort to give those cache entries a finite > > time-to-live but this needs a better justification that what appears > > to be an attempt to circumvent Yahoo rate limits. > > I have a need similar to the original poster. In my case the use case > is to gradually move outgoing traffic to a new egress IP. > > I have separate transports set up in master.cf per address like this: > > smtp unix - - - - - smtp > out1 unix - - - - 50 smtp \ > -o smtp_bind_address=10.150.15.101 > out2 unix - - - - 50 smtp \ > -o smtp_bind_address=10.150.15.102 > [...] > > and additionally the senders are partitioned across IPs > with sender_dependent_default_transport_maps > > Moving a big chunk of traffic in one go to a new IP that was never > sending any traffic before will just cause it to get greylisted > or blocked altogether. > > Given I have a low number of high-volume senders, I cannot find > an easy way to start sending (say) 1% of given sender's traffic > from a new IP. Any suggestions? You did not provide enough context to figure out what Postfix caching feature you're referring to, so I will assume that this is the one-element reply cache with transport map lookups. In that case the obvious solution is not to send 100% of all email to the same destination domain. That will flush the one-element cache frequently, and force fresh transport map lookups. What is the business use case to send 100% of all email to the same destination domain? Wietse
Accept TLS connections only for certain domains?
Is it possible to only accept inbound TLS connections for specified recipient domains only? Thanks, Curtis
Re: Accept TLS connections only for certain domains?
Curtis: > Is it possible to only accept inbound TLS connections for specified > recipient domains only? FYI, the TLS handshake happens before the MAIL FROM and RCPT TO commands. If you want to segregate plaintext and TLS by destination domain, then you need different SMTP listeners (and MX addresses) for different domains. Wietse
Re: postfix mysql lookup table has some kind of caching?
On Mon, Dec 31, 2012 at 02:05:38PM -0500, Wietse Venema wrote: > Marcin Owsiany: > > Wietse Venema porcupine.org> writes: > > > It is not a major effort to give those cache entries a finite > > > time-to-live but this needs a better justification that what appears > > > to be an attempt to circumvent Yahoo rate limits. > > > > I have a need similar to the original poster. In my case the use case > > is to gradually move outgoing traffic to a new egress IP. > > > > I have separate transports set up in master.cf per address like this: > > > > smtp unix - - - - - smtp > > out1 unix - - - - 50 smtp \ > > -o smtp_bind_address=10.150.15.101 > > out2 unix - - - - 50 smtp \ > > -o smtp_bind_address=10.150.15.102 > > [...] > > > > and additionally the senders are partitioned across IPs > > with sender_dependent_default_transport_maps > > > > Moving a big chunk of traffic in one go to a new IP that was never > > sending any traffic before will just cause it to get greylisted > > or blocked altogether. > > > > Given I have a low number of high-volume senders, I cannot find > > an easy way to start sending (say) 1% of given sender's traffic > > from a new IP. Any suggestions? > > You did not provide enough context to figure out what Postfix caching > feature you're referring to, so I will assume that this is the > one-element reply cache with transport map lookups. Gmane nagged me to remove excessive citation, and I guess it got too terse. > In that case the obvious solution is not to send 100% of all email > to the same destination domain. That will flush the one-element > cache frequently, and force fresh transport map lookups. > > What is the business use case to send 100% of all email to the same > destination domain? That's not what is happening. Let me explain a bit more: There's a dozen or so envelope-senders (distribution lists), each periodically sends to a lot of recipients (few thousand to a few dozen thousand). The recipients are distributed over what I think is a typical country-wide sample of domains, which inevitably means the few big webmail services get a large portion. In the basic case, sender_dependent_default_transport_maps assigns each sender to one outgoing IP address, to try and limit colateral damage if one of them screws up and gets blacklisted. I imagine this might sound like a spam sending service, but it's not :-) Now the problem is when we want to move a sender to a different IP address. Because receivers don't like a previously-idle IP to suddenly start sending lots of mail, we need to start with a trickle, to build reputation. Ideally the smtp daemon would be able to bind to a few addresses and there would be an option to assign egress traffic split between them. However I did not find anything like that, so my next idea was to use a custom randomized "tcp" sender_dependent_default_transport_maps lookup table that would map "sender1" to, say, "out1" in 99% of cases and "out2" in the remaining 1%. However the builtin caching would defeat that. regards, -- Marcin Owsiany http://marcin.owsiany.pl/ GnuPG: 2048R/02F946FC 35E9 1344 9F77 5F43 13DD 6423 DBF4 80C6 02F9 46FC "Every program in development at MIT expands until it can read mail." -- Unknown
Re: postfix mysql lookup table has some kind of caching?
Marcin Owsiany: > Ideally the smtp daemon would be able to bind to a few addresses and > there would be an option to assign egress traffic split between them. According to source code, the Postfix 2.5 and later resolver client will reuse the trivial-rewrite daemon result for up to 30 seconds when the request's (address class, sender address, recipient address) are the same as the previous request. According to the following comment, a similar strategy was adopted for address rewriting and transport map wild-card results. 20070414 Cleanup: expire cached results from addres rewriting, address resolution, and from transport map lookups. Results expire after 30 seconds; short enough that it doesn't freak out people who run the same test repeatedly, and long enough that it doesn't upset other people with continuous streams of "*" transport map lookups. Files: global/rewrite_clnt.c, global/resolve_clnt.c, trivial-rewrite/transport.c. Now the question is are 30 seconds too much or too little. Wietse
Re: postfix mysql lookup table has some kind of caching?
On Mon, Dec 31, 2012 at 05:00:52PM -0500, Wietse Venema wrote: > Marcin Owsiany: > > Ideally the smtp daemon would be able to bind to a few addresses and > > there would be an option to assign egress traffic split between them. > > According to source code, the Postfix 2.5 and later resolver client > will reuse the trivial-rewrite daemon result for up to 30 seconds > when the request's (address class, sender address, recipient address) > are the same as the previous request. > > According to the following comment, a similar strategy was adopted > for address rewriting and transport map wild-card results. > > 20070414 > > Cleanup: expire cached results from addres rewriting, address > resolution, and from transport map lookups. Results expire > after 30 seconds; short enough that it doesn't freak out > people who run the same test repeatedly, and long enough > that it doesn't upset other people with continuous streams > of "*" transport map lookups. Files: global/rewrite_clnt.c, > global/resolve_clnt.c, trivial-rewrite/transport.c. > > Now the question is are 30 seconds too much or too little. Much too much in my case. The client app sends messages in batches, and in 30 seconds much more than 1% of a batch will get processed, especially given that the canary IP address transport will mostly see fast rejections. -- Marcin Owsiany http://marcin.owsiany.pl/ GnuPG: 2048R/02F946FC 35E9 1344 9F77 5F43 13DD 6423 DBF4 80C6 02F9 46FC "Every program in development at MIT expands until it can read mail." -- Unknown
Re: postfix mysql lookup table has some kind of caching?
Wietse: > 20070414 > Cleanup: expire cached results from addres rewriting, address > resolution, and from transport map lookups. Results expire > after 30 seconds; short enough that it doesn't freak out > people who run the same test repeatedly, and long enough > that it doesn't upset other people with continuous streams > of "*" transport map lookups. [...] > > Now the question is are 30 seconds too much or too little. Marcin Owsiany: > Much too much in my case. The client app sends messages in batches, > and in 30 seconds much more than 1% of a batch will get processed, > especially given that the canary IP address transport will mostly > see fast rejections. In that case, a burst of 1s would still be undesirable, so one would have to be able to specify 0 (no caching) while the default would remain at 30s. Wietse
Re: postfix mysql lookup table has some kind of caching?
On Mon, Dec 31, 2012 at 05:45:57PM -0500, Wietse Venema wrote: > In that case, a burst of 1s would still be undesirable, so one would > have to be able to specify 0 (no caching) while the default would > remain at 30s. Right. I hope that disabling caching altogether would not affect performance too much. Perhaps it would be a per-map option, so that it would only affect the maps that it needs to affect? -- Marcin Owsiany http://marcin.owsiany.pl/ GnuPG: 2048R/02F946FC 35E9 1344 9F77 5F43 13DD 6423 DBF4 80C6 02F9 46FC "Every program in development at MIT expands until it can read mail." -- Unknown
Re: postfix mysql lookup table has some kind of caching?
Marcin Owsiany: > On Mon, Dec 31, 2012 at 05:45:57PM -0500, Wietse Venema wrote: > > In that case, a burst of 1s would still be undesirable, so one would > > have to be able to specify 0 (no caching) while the default would > > remain at 30s. > > Right. > > I hope that disabling caching altogether would not affect performance > too much. Perhaps it would be a per-map option, so that it would only > affect the maps that it needs to affect? Caching is mostly a client feature. A client doesn't care what tables a server is using. Wietse
Re: postfix mysql lookup table has some kind of caching?
On 12/31/2012 3:06 PM, Marcin Owsiany wrote: > I imagine this might sound like a spam sending service, but it's not :-) Hi Marcin, Q1: Why is a Google Site Reliability Engineer and long time Debian maintainer, with two Masters degrees, working on an email blasting infrastructure? Q2: Why are you not leveraging the expertise of the Google messaging folks for this project? FYI, my first Linux was Potato and I've been Debian ever since. :) Thank you for your contributions over the years. -- Stan
