Re: ot: iPhone smtp setup
Le 25/10/2012 22:39, li...@sbt.net.au a écrit : [snip] > the error message didn't say, I've screenshoted it, not sure if iPhone has > some other log access one can see ? > or it tried to connecte to the "smtps" port, and this one is not open/enabled. As Jeroen told you, make sure you configured the account to use "TLS" and not "SSL". [snip] > > but, my understanding of mail header above, it was submitted to ISP's mail > server, not postfix server, yet, the only enabled smtp I saw on iphone was > my postfix server (unless iPhone user fiddled the iPhone..?) > maybe the ISP is silently redirecting traffic. good ISPs should not redirect submission (port 587) but some do. or the iphone is not configured to use 587.
Re: mini-mailbomb service problems
On 10/27/2012 12:17 AM, /dev/rob0 wrote: > On Fri, Oct 26, 2012 at 10:46:40PM -0500, Stan Hoeppner wrote: >> On 10/26/2012 6:16 PM, John Baker wrote: >>> I just wondered if anyone can give me any suggestions on how to >>> improve this situation. I have been getting slammed by a bot net >>> mostly for accounts that don't actually exist since late morning. >>> Almost all the messages are being rejected by postfix or >>> greylisting but at the same time it's resulted in hundreds of >>> Temporary lookup failures. I use ldap lookups in in >>> virtual_alias_maps to do some mail routing. As best I can tell my >>> ldap servers can't move fast enough for the volume so I end up >>> with a bunch of error messages like this coming to postmaster: >>> >>> Out: 250 2.1.0 Ok >>> In: RCPT TO:<+._-gmatto...@marlboro.edu> >>> Out: 451 4.3.0 <+._-gmatto...@marlboro.edu>: Temporary lookup failure >>> In: RSET >>> Out: 250 2.0.0 Ok >>> In: MAIL FROM:<> SIZE=7377 > > Hmmm. Looks like backscatter. I totally missed it. Good catch Rob. >>> Out: 250 2.1.0 Ok >>> In: RCPT TO:<+._-gmatto...@marlboro.edu> >>> Out: 450 4.7.1 <+._-gmatto...@marlboro.edu>: Recipient address rejected: >>> Policy Rejection- Abuse. Go away. >>> In: RSET >>> Out: 250 2.0.0 Ok >>> In: MAIL FROM:<> SIZE=7380 >>> Out: 250 2.1.0 Ok >>> In: RCPT TO:<+._-gmatto...@marlboro.edu> >>> Out: 450 4.7.1 <+._-gmatto...@marlboro.edu>: Recipient address rejected: >>> Policy Rejection- Abuse. Go away. >>> In: QUIT >>> Out: 221 2.0.0 Bye >>> >>> I'm also getting a bunch that just time out and have to resend. Yeah, the fact that he's temp failing these with 450 and they retry demonstrates these are not bots. Bots don't retry. None that I'm aware of anyway. >>> Is there anything I can do to alleviate the load on my ldap >>> server? It's coming from so many IP's it's not going to do any >>> good to just start firewalling. >> >> Configure Postscreen >> http://www.postfix.org/postscreen.8.html >> >> It drops bots before user lookup. Very effective. Requires >> Postfix 2.8 or later. > > Yes, *if* these really are bots. I bet they're not. It looks like a > backscatter / sender verification attack, as if these addresses were > used as sender addresses in a spam run. Now that you've made me look at this more closely I tend to agree. He may be seeing a combination of backscatter and increased bot connections as well. Not really enough evidence presented here for a clear picture. > I would recommend that John consider a check_sender_access lookup of > the null sender, and therein apply ips.backscatterers.org or other > backscatter DNSBL[s], but that entails a slight risk of loss of real > mail (sometimes a backscatter source might have a real bounce to > deliver), and it won't help with the load on the LDAP server. > > If all the rejected recipient addresses follow some kind of pattern, > maybe a PCRE lookup can help. We don't know enough about it to > suggest anything more. Actually, we might know enough. The op's primary stated concern is alleviating load/latency on his LDAP servers. Marlboro college, according to the website, only has ~300 students. Add faculty/staff/alumni/etc, and the valid user table shouldn't be all that large. Cron'ing a nightly, twice daily, whatever works best, script to pull addresses from LDAP into a Postfix virtual users table may be a good option here. Query the local table and eliminate LDAP lookups entirely, making lookups instantaneous. The frequency of the table update is determined by how often address changes are made to LDAP, and how quickly mailboxes need to go live according to organizational policy. Of course, the script can be run manually any time as well. I believe such a setup is relatively common for eliminating this LDAP load issue, and specifically at sites with MS AD/Exchange downstream of Postfix. -- Stan
Re: mini-mailbomb service problems
On 10/27/2012 12:29 AM, /dev/rob0 wrote: > On Sat, Oct 27, 2012 at 12:17:43AM -0500, I wrote: >> On Fri, Oct 26, 2012 at 10:46:40PM -0500, Stan Hoeppner wrote: >>> On 10/26/2012 6:16 PM, John Baker wrote: Is there anything I can do to alleviate the load on my ldap server? It's coming from so many IP's it's not going to do any good to just start firewalling. >>> >>> Configure Postscreen >>> http://www.postfix.org/postscreen.8.html >>> >>> It drops bots before user lookup. Very effective. Requires >>> Postfix 2.8 or later. >> >> Yes, *if* these really are bots. I bet they're not. It looks like >> a backscatter / sender verification attack, as if these addresses >> were used as sender addresses in a spam run. > > Most backscatter sources are "legitimate" MTAs. Many have FCrDNS. > They'll pass any postscreening and get to smtpd soon enough. Even so, > postscreen would lessen the pressure of actual bots on the server, so > it would indeed help somewhat. Agreed. My previous rec to use a local table will help with backscatter induced LDAP load. Postscreen would also allow the op to eliminate his greylisting daemon since Postscreen does the same job, but much more efficiently. Greylisting daemons require one smtpd process per client connection, eating resources, whereas Postscreen drops bot connections before they reach smtpd--which is the design purpose of Postscreen--reducing the overall load Postfix places on the system, reducing the latency of real email through the system. -- Stan
Re: Debug smtpd_recipient_restrictions
Freek Dijkstra skrev den 26-10-2012 23:06: warn_if_reject reject_rbl_client relays.ordb.org, old rbl list never dies ? hint dont add dns check that does not work
Re: Debug smtpd_recipient_restrictions
On 10/26/2012 4:34 PM, Viktor Dukhovni wrote: > IIRC relays.ordb.org is LONG dead, or if not dead, is not a good > choice for most sites. LONG dead is right, for six years now. Offline since Dec 31, 2006: http://tech.slashdot.org/story/06/12/18/154259/ordborg-going-offline -- Stan
Re: ot: iPhone smtp setup
Mous, Sorry, I've misunderstood the explanation, i was thinking at the server end, where I'm confident it's correct, I'll recheck iPhone when I get access to it again, thanks. mouss wrote: >Le 25/10/2012 22:39, li...@sbt.net.au a écrit : >[snip] >> the error message didn't say, I've screenshoted it, not sure if >iPhone has >> some other log access one can see ? >> > > >or it tried to connecte to the "smtps" port, and this one is not >open/enabled. > >As Jeroen told you, make sure you configured the account to use "TLS" >and not "SSL". > >[snip] >> >> but, my understanding of mail header above, it was submitted to ISP's >mail >> server, not postfix server, yet, the only enabled smtp I saw on >iphone was >> my postfix server (unless iPhone user fiddled the iPhone..?) >> > >maybe the ISP is silently redirecting traffic. good ISPs should not >redirect submission (port 587) but some do. or the iphone is not >configured to use 587. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
