Well, "SPF" and "smtp port blocking / use our MTA enforcement" exclude each other - it's not SPF's fault that ISPs block that port (if that's the matter at all in this case).
as already stated: Bluewin does not block _ANY_ ports... (we did and will do it if it's needed for Worm mitigation, but only a restricted time) A customer can use any MTA he likes. The question is if the selected MTA will accept the mail. The customer could also run their own mailserver if they want. (As stated below, many MX will reject mail from customer pools)
IF it is the case as mentioned:
1. The user can't use his mailserver of choice, and therefore relies on the bluewin mailservice (which I belive works well... - but I guess there are lot of reasons why you rather use the MTA responsible for your domain).
We suggest to all Bluewin users to use our mail servers, but they don't have to.
2. The same thing can be arranged by either contribute the IP-Range to a DUL RBL, or some nice naming scheme (like dynip.bluewin.ch and fix.bluewin.ch) so an a remote ISP can black/greylist the Range by using the RBL or name of the host connecting.
Our naming scheme is quite easy: [IP-reversed].cust.bluewin.ch or [IP-reversed].fix.bluewin.ch e.g 5.6.76.83.cust.bluewin.ch for IP 83.76.6.5 We can't înfluence what people DUL/RBL's use for black- or greylisting. The DUL's know many blocks, no matter if they have easy hints in the name or not.
3. The blocking of the port does not prevent sender forgery, which is the goal of SPF. It "just" ensures that the postmasters at bluewin have precious logfiles to see what mailtraffic is happening - and _maybe_ they are doing some woodoo to prevent nasty things.
No, the Bluewin Mailservers are "open" for their customers. They can send mail with their "@gmail.com, @gmx.de, @hotmail.XX) addresses. Not that many MUA's let you use another mailserver depending on the from: address inn the mail.
4. IF they really filter the traffic and eliminate all the UCE/UBE/Virii then I would say they are doing something to same cpu cicles on our mailservers...
5. The options are rather limited and I assume straight forward - change the ISP (rather pragmatic) - get the feature disabled - use the submission thingy (I wonder when MUAs switch to using this port out of the box)
There is still the possibility of some other feature like a Firewall between that blocks ECN or ICMP - in case you are using postfix, just "clone" smtpd service and let it run on port (your favorite alternate smtp port) - if the customer can telnet to that port but not to your smtp port the thing boils down to a smtp-filter.
That's one reason we don't see any use in blocking port 25 (or anyhing else). In the end eveerything is "tunneled" over port 80 which nobody blocks. Many infections of customer computers come from "web exploits", or at least further damaging payload gets downloaded from web sites. I always point this out in disscusions at Bluewin and recommend blocking ports 80,110,143 first and only then maybe filter port 25. (This way a customer cannot be infected and become a spam proxy/zombie.)
On Mit, Dez 08, 2004 at 19:18:49 +0100, Roger Schmid wrote:
that's why noone really using SPF.
.. btw, not only bluewin is doing this, others will follow.. so be prepared.
Others _are_ doing this. We (Bluewin are not)
There are some techniques out there that exclude each other, it would be REALLY nice if the postmasters on this world would come to a common mailpolicy - ah sorry, it's 3:54am - I'm dreaming with eyes open...
It's a pity there's no perfect solution in sight. Everyone has to look what works best for them. A company maybe can easily use spamassasin and filter all mails from Asia, Middle east, Africa and the Americas (only allowing german mails). Others can only communicate with known peers or use greylisting. As an ISP we cannot use those measures.
my 2c Philipp
Guido _______________________________________________ swinog mailing list [EMAIL PROTECTED] http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
