>> that those servers send me ham but also spam > Purely IP based - checks do not make sense for IPs > which have mixed (ham/spam) output per definition. > This is als valid for the ISPIP list. > So - many people run the nodelay list also as ispip list.
probably you missed the point about the "cluster" issue let's say we have a "cluster" made up this way (the IPs/hosts below are for true, are used by Italian Interbusiness and TelecomItalia as mail "emission" points but this isn't the only one around having such issues with delaying) # # alice and interbusiness # 85.33.2.6 # smtp-out02.alice.it 85.33.2.7 # smtp-out08.alice.it 85.33.2.8 # smtp-out09.alice.it 85.33.2.12 # smtp-out01.alice.it 85.33.2.13 # smtp-out05.alice.it 85.33.2.14 # smtp-out06.alice.it 85.33.2.15 # smtp-out07.alice.it 85.33.2.16 # smtp-out10.alice.it 85.33.2.17 # smtp-out11.alice.it 85.33.2.18 # smtp-out13.alice.it 85.33.2.19 # smtp-out19.alice.it 85.33.2.20 # smtp-out20.alice.it 85.33.2.21 # smtp-out21.alice.it 85.33.2.22 # smtp-out22.alice.it 85.33.2.23 # smtp-out23.alice.it 85.33.2.24 # smtp-out24.alice.it 85.33.2.25 # smtp-out25.alice.it 85.33.2.26 # smtp-out26.alice.it 85.33.2.27 # smtp-out27.alice.it 85.33.2.28 # smtp-out28.alice.it 85.33.2.29 # smtp-out29.alice.it 85.33.2.30 # smtp-out30.alice.it 85.33.2.31 # smtp-out31.alice.it 85.33.2.51 # iptvwm.rossoalice.virgilio.it 85.33.2.53 # smtp.aliceposta.it 85.33.2.55 # out.aliceposta.it 85.33.2.56 # in.aliceposta.it 85.33.2.57 # mail.rossoalice.virgilio.it 85.33.2.58 # gmail.rossoalice.virgilio.it 85.33.2.59 # pushsrv.attiva.biz 85.33.2.128 # MTA128A.interbusiness.it 85.33.2.129 # MTA129A.interbusiness.it 85.33.2.130 # MTA130A.interbusiness.it 85.33.2.131 # MTA131A.interbusiness.it 85.33.2.132 # MTA132B.interbusiness.it 85.33.2.133 # MTA133B.interbusiness.it 85.33.2.134 # MTA134B.interbusiness.it 85.33.2.135 # MTA135B.interbusiness.it 85.33.2.136 # MTA136C.interbusiness.it 85.33.2.137 # MTA137C.interbusiness.it 85.33.2.138 # MTA138C.interbusiness.it 85.33.2.139 # MTA139C.interbusiness.it 85.33.2.140 # MTA140D.interbusiness.it 85.33.2.141 # MTA141D.interbusiness.it 85.33.2.142 # MTA142D.interbusiness.it 85.33.2.143 # MTA143D.interbusiness.it 85.33.3.5 # smtp-OUT05A.alice.it 85.33.31.84 # smtpout084B.attiva.biz 85.33.31.85 # smtpout085B.attiva.biz 85.33.31.86 # smtpout086B.attiva.biz 85.33.31.87 # smtpout087B.attiva.biz 85.33.31.88 # smtpout088B.attiva.biz 85.33.31.89 # smtpout089B.attiva.biz 85.33.31.90 # smtpout090B.attiva.biz 85.33.31.91 # smtpout091B.attiva.biz 85.33.31.92 # smtpout092B.attiva.biz 85.33.31.93 # smtpout093B.attiva.biz 85.33.31.94 # smtpout094B.attiva.biz now, someone sends to my ASSP an email through those servers, a first server, from a given IP (they may be behind a load balancer for example) tries to send the email, my ASSP delays it and sends out a 4xx; after a while, the sender cluster retries, but this time the connection comes from another IP from the "cluster" so it's delayed again... and so on, and in many cases this causes the mail to be refused (over attempt limit) so, in such cases we'll need to skip the delay for those IPs but NOT to skip the regular spamchecks for it nor to lower the score and consider it "better" than it is :) ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
