> What would be happen for legal SMTP connections? > > -> mx01 -> no connect > -> mx02 -> 451 ... the assp delay > -> mx03 -> 451 - the every time delay > wait 5 min -> mx01 -> no connect > -> mx02 -> assp will accept and deliver the mail > > Where is the difference for ASSP if we delay on an > extra IP (MX) and the current delaying?
The difference (in my case, that is, using a separate "fake MX" application) is in the fact that the real mailserver (or ASSP) gets less load due to the fact that a number of bots go straight to the mx03 :) then... ok, embedding the fakeMX inside ASSP would mean posing some "load" but ... not too much imHo, see, the "fakeMX" won't need to perform any kind of filtering, it would just sit there, accept connections and then emit the "421..." so no real load there > disadvantage : ASSP will get a much higher connection count > advantage : we may do some scoring, if a host connects within a > specific time frame first at MX03. Exactly; with the approach I'm currently using (separate fakemx application) I'm able to relieve the load on the real MX server(s) but when it comes to correlating infos, I need to use some scripts to check if a given host went straight to mx03 (or to mx01 and then to mx03) while having such a feature built directly into ASSP may allow to automatically update the "penaltybox" and possibly the spamtraps and other stuff too > -> mx01 -> no connect and the RFC states that in such a case the sending server should directly go on and try the next MX in preference order, so, no delay here aside the one introduced by the "connection timeout" > -> mx02 -> 451 ... the assp delay this only happens the first time :) > -> mx03 -> 451 - the every time delay (score or needs additional > logic because we saw it at mx02 first) not a 451 in this case but a 421 4.2.1 Service temporarily unavailable, closing transmission channel. which, as for the RFCs is still a temporary failure and allows us to drop the connection at whatever stage (I do that as soon as I get the "DATA" command in my own fakemx implementation) > wait 6 hours -> mx01 -> no connect > -> mx03 -> 451 - the every time delay (score ???) hm.... no wait, the sender waits, then retries mx01, gets "no connection" and immediately retries with mx02 where ASSP, having the "tuple" in its cache will accept and process the message and accept or either reject it... and this won't need 6 hours :) or at least I never saw that till now, then, maybe some senders may have such kind of issue, but, again, till now (and I've been using the fakemx for quite a while) I had no issues of this type > Sorry - but I don't like the idea. If MX01 and MX03 has nothing to do > with ASSP - OK - this will lead in to a small decrease of the connection > count for assp. But why should we FORCE the raise of the connection I see... well, I agree and sorry for bringing this to the table, see, as sometimes I do, I was "thinking loud" and, given the fact that the "mx sandwich" (that's how some people calls it) helps and helped some server "standing up in a storm" and given the fact that while on Unix it's quite easy setting up a "fake MX" (while in windows I had to write my own), I thought to post the idea... but then... yes, if will add some "load" (even if a really light one) on ASSP, so... just discard it, sorry again ! (by the way I'll keep using the sandwich, just... will do that using my own "fakemx" critter instead of leveraging an ASSP feature :D) ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test
