Re: [swinog] Cloudflare DMCA Takedown requests - but content not present under mentioned IP
Hello Benoit, > I am a bit puzzled by repeated Cloudflare Takedown Requests regarding > the domain: lord-film.cash we are getting. > > lord-film.cash has address 172.67.181.230 > lord-film.cash has address 104.21.32.5 > lord-film.cash has IPv6 address 2606:4700:3035::6815:2005 > lord-film.cash has IPv6 address 2606:4700:3032::ac43:b5e6 > > According to Cloudflare, the content is hosted at an IP address under > our control, on a Webserver on Port 80. I find this a bit odd, that they'd send you take-down requests for their own IP addresses when I search the domain in google, they show some site with cyrillic description (russian?), and you can even look at the cached page in google, and it does seem to host movies (just ran it through google translate). My guess is the entry page is probably geo fenced. I then clicked some of the russian links, was again redirected through cloudflare with their infamouse captchas, but was finally shown this link: https://hd-1.lordfilms.help/2019/01/06/vpered-v-proshloe-2007.html which, again, is hosted at cloudflare... It definitely looks illegal for consumers in DMCA countries... Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] sendinblue / newsletter sender whitelisting?
Hello Michael > In the last weeks we had requests from customers, whose "newsletter" via > sendinblue could not be delivered to us. In > the logs I see at the given time, that the IP of sendinblue was on the > blacklist of spamcop.net. That is, the mails > were rejected by us. > > The customer now says the mails go through everywhere else (I'm looking at > you bluewin.ch), just not with you. we're actively blocking many of their servers due to sending our customers spam, so that will invalidate that "everywhere else" statement a bit;) Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Handling of UCE / RBL while minor misconfigurations
> well, technically, they (UCEProtect) are correct. Sure, if I shoehorn my own rules, I can almost guarantee that _I_ will be compliant. That doesn't make them any more relevant though. > If an IP sends a mail with the From: header indicating a domain for > which an SPF record exists, and the sending IP is not supposed to send > it, then it is a misconfiguration and that IP should not be trying to > send such a mail at all. But SPF is supposed to be applied to the SMTP envelope address, NOT whatever happens to be put into any header lines... For headers you got your other voodoo, like DKIM. And I'm also not so sure that this is a misconfiguration, since that would assume I'd give SPF the same kind of authority as I give basic SMTP relaying, which I don't. I'll repeat myself: SPF is broken by design. But, I'll actually consider putting in an option into our mail configuration pannels, that lets customers who are forwarding mail to 3rd party servers, reject inbound mails if their forwarding would violate the sender policy. After all, it's our customers who pay us to handle their mail, not external mail senders, and thus customers should have the last word in this decision. Given though how many mail delivery errors never make it back to the sender, I wonder if this added complexity would really be beneficial. My gut feeling is: nope. The reply of UCEProtect fits my impression I got of them, and it confirms to me that I can't take them seriously. I'll let them throw tantrums in their playpen and move on. Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Handling of UCE / RBL while minor misconfigurations
Hey Jeroen, > SPF is only a part of a solution to the battle of spam. SPF isn't suited to combat SPAM at all (including the whole other DKIM etc enchilada), since it's quite trivial for spammers to define these records correctly in throwaway domains. Thus, no reasonable spam filter can honour (in a positive way) the presence of an SPF record, they can only punish the connection if there is an SPF record and the connection is in violation of that record. The really only benefit you could get from SPF is some kind of antispoofing protection, but at least in my experience, that is hardly ever a real problem to begin with. > It helps a lot to combat broken setups. > > If a setup is broken, they are not worthy of receiving mail in the first > place. > > Thus, if you hate on SPF, I can only conclude you have shot yourself in the > foot a lot with it. No, I hate SPF because it breaks basic SMTP relaying, or in more enduser speak: redirected mails. Mail is _NOT_ always delivered directly from origin to target, it is quite frequent, that mails get redirected to 3rd party systems. Some SPF advocates just accept their mails failing because they consider mail redirects to be evil. Fine. To really fix those redirect issues, _all_ possibly relaying servers would have to adopt some kind of sender rewriting scheme, which as far as I recall, can blow up sender email addresses to sizes that will exceed RFC standards in very few iterations. Also, in these cases the relaying server will originate 3rd party mails with its own domain name, possibly turning it into a spam funnel. So, for me, SPF is broken by design, and no amount of additional tinkering around its pitfalls will fix that. Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Handling of UCE / RBL while minor misconfigurations
Hello Urs, My take on your problem is the following: - SPF is bad and breaks mail delivery, don't use it. But, if someone defines SPF records, and they thus declare they want to shoot themselves into their feet, by all means, I encourage to block mails failing SPF, because that's what domain owners who define SPF records ask for. - everyone can setup blocking lists defining the oddest criteria for when an entry gets added. Someone in charge of a mailserver can decide based on his criteria, and his alone, what mails he wants to receive and what mail to reject. He can use whatever resources he wants, including bogus lists such as uceprotect. But, it would be prudent to inform yourself about what exactly you enable before you do so... - now, if someone deploys antispam gateways such as those from Sophos, and decides to just click "enable all block lists" or however that menu looks like, and with this enables lists such as uceprotect, then that person just cut their company off from a lot of valid mail. If he wanted to do that, it's his decision, but usually it helps to teach those admins about the errors of their ways, instead of blaming the list provider. - I personally consider uceprotect to be a rogue list with utopian views on how mail service works. Their unlist policy could be considered extortion, but the really responsible party is whoever enables such a list on their servers. just my personal views:) Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Sporadic DNS resolver error for *.mail.protection.outlook.com
> we see sporadic DNS resolver errors for A records of > *.mail.protection.outlook.com > > Only a few per day vs many successful lookups. I haven't noticed this, but we found out last week that Microsoft apparently has enabled a new cluster of servers for europe in networks 40.92.7[345].*. All of these currently completely lack PTR data, and the corresponding SOA suggests a last modification date of February 5, 2018: 92.40.in-addr.arpa. 3600IN SOA ns1.msft.net. msnhst.microsoft.com. 2018020502 7200 900 2419200 3600 they pop up in logs such as this: [40.92.75.99] claimed to be EUR04-VI1-obe.outbound.protection.outlook.com and rejected connections seem to carry only freemail services (hotmail, windowslivemail). We informed SOA and whois contacts last Wednesday, but haven't heard back from them. Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
Cheers Jeroen,
> If you are anti-spam, don't bother checking this (dom.com A); anybody
> who wants to receive mail will have an MX, if not, let them join the
> 2000s...
There are actually quite a few (definitely more than white noise) senders that
don't have MX, and only use A records.
Many of these are from what I call "isp-in-a-box" resellers, who a) don't know
how to properly setup their servers, and
b) since web-server-address and mail-server-address are the same, things "just
work" if they only point their domain
name to the IP address of their virtual server. While I don't think that's a
good setup, I'm not at the liberty of
denying our customers to receive mails from such senders :)
> Also, instead of bothering with the MX Lookup, verify and enforce SPF,
> DKIM and DMARC instead, they are meant for checking against the envelope
Oh, if a sender deliberately wants to break his mail delivery and defines such
records, you can be sure we'll test for
them, and classify the mail as SPAM if they fail. We don't encourage their use,
but you bet we'll enforce them if
they're set.
> From, MXs are not. Non-existence of a MX on a domain does not mean it
> does not get used for sending mail; thus you might have a small false
> positive rate there... (which you might chose to accept, you are the
> receiving end, hope you have an informative rejecting message ;) )
>
> Spammers will make sure that MX, SPF, DKIM and DMARC are all configured
> btw; they only really 'resolve' spoofing issues.
Yes, I consider SPF and friends evil, as I pointed out above, but will
definitely enforce them when provided. My stance
on the MAIL FROM address is: if we accept a mail for delivery/relay, we also
accept the responsibility to deliver back
DSN mails to the sender, if there is a problem with the finaly delivery of the
mail later on. For that, we need a
valid, usable sender address. If there isn't one, we won't accept the mail. It
is also a very effective tool to weed
out many spammers without resorting to content analysis (and is thus much more
efficient, as well). MX to localhost?
bye bye :)
> I assume you also allow '<>' for DSNs?
I do, but I severely restrict what we allow in these mails, their size, only a
single recipient, etc.
> If you do the above, you might want to check for "MX .", this indicates
> a domain that will never send mail as per RFC7505:
>
> https://tools.ietf.org/html/rfc7505
I don't have to check for this explicitly, because it will fail the A lookup
check, so it will be considered an invalid
domain for an email address. But thanks for the pointer, didn't know about this
rfc.
> But again: MX is for _receiving_, not _sending_ (From) thus checking it
> is a bit wrong, but at your prerogative.
I explained my reasoning above, why we do verify the sender like this.
> Last note: do _not_ use 'host' for debugging DNS related issues, always
> use the very useful 'dig' tool, or if you want use 'drill' instead.
> ('host' hides various error situations and does not properly show what
> you are actually querying...)
I actually do use dig normally, I used "host" here because the output is much
more terse and thus better suited to
explain a problem and keep the description smallish (my mail was too long
already for some people;-))
Ciao,
Markus
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
Short update on this problem, which should be fixed by now: - I was able to reach the responsible team, and they answered very quickly. I was positively surprised! - They confirmed there's a problem with the zone content on their Dyn nameservers - They then added additional NS records on level msa.msidentity.com to point only to Akamai servers (overriding the 50:50 split for msidentity.com) - The result now is that mail.msa.msidentity.com gets resolved only bei Akamai servers, and should thus resolve reliably. I don't know the reason why they couldn't just fix the zone copy that gets distributed to the Dyn servers, but the workaround fixed the problem at hand, so problem solved :) Congrats to the Microsoft AAD Network SRE team, I didn't hope to get any answer, but they took care of the problem right away! Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
Cheers Stephan, > I might be wrong but according to RFC 2821 it is ok to use a CNAME if > the target is resolvable to A or MX. > > 3.6 Domains > > Only resolvable, fully-qualified, domain names (FQDNs) are permitted > when domain names are used in SMTP. In other words, names that can > be resolved to MX RRs or A RRs (as discussed in section 5) are > permitted, as are CNAME RRs whose targets can be resolved, in turn, > to MX or A RRs. Local nicknames or unqualified names MUST NOT be > used. True, so guess I'll modify my validation rules according to this. Thanks! > However, the target domain in this case is not working correctly. I've found that inconsistency as well between their 2 main DNS providers. Akamai, using serials that seem to be unix timestamps, returns MX records. dynect.net using sequentially incrementing serials (much lower, Windows DNS? :)) doesn't return any MX. So, it's essentially pretty random whether the address resolves, or not... I've tried to communicate this to aadnet...@microsoft.com, as per: msidentity.com has SOA record ns1.p09.dynect.net. aadnetsre.microsoft.com. 23844 3600 600 604800 1800 but some part of me will be very surprised if I'll get any answer back from that address... Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
Hello Ralph > [TL;DR] ;-) sorry about that, but it's not about an MX to a CNAME, it's about the domain part being resolved directly via a CNAME (kind of like having a domain-level CNAME to another domain, except _THAT_ isn't allowed due to shadowing NS and SOA records). With something like "accountprotection.microsoft.com" they're probably not breaking that rule though. When you have time, I'd welcome an answer to my question ;) Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] Mail to CNAME a thing?
Hi there, I've just come across a weird mail reception problem of some mails from Microsoft. Our servers insist that a specified MAIL FROM address can be resolved correctly, and this usually boils down to the following checks on the domain-part of the email-address specified: - is there an MX? Does the target resolve using an A record (not a CNAME), and does it resolve to a publically reachable address (not RFC1918 or localhost etc) - if there is no MX, is there an A record that fulfils the same criteria as the MX target above? - if none of these are true, the address is considered to be invalid and mail is rejected Since about Feb 15, I've now come across mails from account-security-nore...@accountprotection.microsoft.com that get rejected. When I manually perform the above steps, I can see why, and I also see a first: the domain part is actually a CNAME, something I've not encountered mentioned in standards as being a legal way to perform address resolution when delivering email. But, I also don't recall reading about rules that explicitly deny this, contrary to the very explicit rules that for example deny having MX point to CNAME. The domain setup here is borked in multiple ways however: $ host -t mx accountprotection.microsoft.com Host accountprotection.microsoft.com not found: 3(NXDOMAIN) $ host -t a accountprotection.microsoft.com Host accountprotection.microsoft.com not found: 3(NXDOMAIN) BUT: $ host -t cname accountprotection.microsoft.com accountprotection.microsoft.com is an alias for mail.msa.msidentity.com. and even if we should allow use of a CNAME here, we'd have to apply the same rules as stated initially on the CNAME target, and these fail as well: $ host -t mx mail.msa.msidentity.com. Host mail.msa.msidentity.com not found: 3(NXDOMAIN) $ host -t a mail.msa.msidentity.com. Host mail.msa.msidentity.com not found: 3(NXDOMAIN) So, what's your take on this? Does someone see a legal way to resolv this sender, that I've missed? Am I right in considering these addresses to be unresolvable and thus reject these mails? Who would I have to report this to at Microsoft to have any chance of a human person looking at the issue? Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] Looking for person responsible for *@mms.sunrise.ch
Sorry to spam the list for this, but I was not able to find anything close to a technical support email contact on their web page... To avoid many round trip mails, here's the problem: we get incoming mails with senders like <+4176...@mms.sunrise.ch>. But: mms.sunrise.ch. 3600IN MX 10 mm3.sunrise.ch. Host mm3.sunrise.ch not found: 3(NXDOMAIN) So, those sender addresses are invalid, and get rejected on our mail servers. Might want to fix your DNS.. Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Bad Connectivity at UPC Home Internet
My guess is, UPC just has the occasional overbooked peering link problem. A while ago I was frequently watching youtube videos, and found the quality to drop considerably in the early evening hours, when probably many other customers also started to watch youtube. Enabling a VPN to the UK, sometimes even to the US, brought back the quality. So, in my interpretation, my home connection was NOT the culprit, but the backbone interconnection of UPC with the peers I was watching content from. I haven't had such frequent issues recently, but then I also mostly switched to watching twitch instead of youtube, and that will go over different peering links. Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Rack mounting Switch/Routers in Cold and Hot Isle DC
Hello Patrick, > In theory, one should mount the switches/routers in front (toward cold isle) > of the rack to have an optimal airflow, but then cabling get a little bit > messy. > > If this type of equipment is mounted in the back (toward hot isle), the > cabling can be done much cleaner, but the airflow isn't optimal and in worst > case, switches and routes take in hot air from other devices. the most elegant solution is to buy devices in a reverse airflow configuration. That is however not always possible. The worst type are switches with sideways airflow, since those will always suck up warm air. Those with regular airflow you can at least mount inverted into the racks (and get a cable mess, as you predicted). we just got a bunch of cheap 10GE switches for a test platform, and these only came with a regular airflow configuration. The workaround here was to order them with fiber SFP+ instead of copper DAC cables, since fiber cables are much easier (because they're thinner) to route through half the rack. whatever you do: set up polling of the inlet temperature with SNMP if your devices support such a MIB. ColoZH can get _very_ hot and it's vital you know whether you're slowly cooking your devices, or whether they're within specs. Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] QSFP to SFP+ breakout cables ?
Hi there, I'm looking for reasonably priced QSFP (40GE) to SFP+ (10GE) twinax breakout cables (3m long or so). I can order via ebay for ~$150 but I was wondering whether there's a local distributor who has a stock for them and doesn't sell them at 500CHF or more... Any recommendation? Also, what kind of adapter would I need to break out a QSFP to 4 SFP+ sockets (where I could then attach fiber SFP+)? Haven't seem something like that, but perhaps I'm searching wrong? Thanks for any hints ! Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] How to automate abuse complaints for ip based violations
Hi there, when looking through traffic analysis, I can more or less easily identify IP addresses that exhibit bad behavior (like massive port/address scanning, attempting to log into joomla/wp administration URLs, POP3/SMTP account scanning, etc) which need to be blocked. Now, since most of these IPs are not the actual culprits, but merely infected machines, it would be helpful for the internet health as a whole to report such incidents to their respective ISPs. Here's where the problem starts:) My manual approach would be to lookup whois data for the respective IP (which by itself can be a multi step process, since you first need to find the right registry), and look for an abuse-contact there. But, whois isn't exactly engineered for automated mass lookups (+), and if I did this I'm sure I'd probably be violating terms of use of at least some of the registry whois servers, and be locked out. So, what alternatives are there? I saw that abuse.net keeps a nice DNS based lookup service for domain names, but they unfortunately don't do this for IP addresses. How are others doing this? I know I occasionally received output of fail2ban scripts when working for a larger ISP. Are these all in-house local developments? Cheers, Markus (+) joomla/wp scans alone yielded 3000 ip addresses in one day for our little network... ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Replacement Fan for C2950-T-24?
Does anyone know a good source for replacement fans for the Cisco 2950-T-24? A silent version would be preferred. The fan is 40x20mm and has a 3-pin connector. Yes, I've already checked Digitec but they don't seem to have anything that matches. tried distrelec? they have plenty of papst fans which usually are very quiet. perhaps this one will work, even though it's flatter than the one you're looking for? https://www.distrelec.ch/axiall%C3%BCfter-dc-40-x-40-x-10-mm-12-vdc/papst/412-f-2h/698050/it--zubeh%C3%B6r cheers, markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Transparent 1Gig Ethernet over IP/Ethernet?
I need to transparently (especially LACP frames) transport a gigabit ethernet link with at least 1500 MTU over either IP or Ethernet. Jumbo frames are enabled on the L2 transport backbone. While I need full (some encap overhead will be acceptable) GigE wire speed, encryption is unnecessary. Since you don't need encryption, aren't these more or less the same requirements as to transport dot1q tags within an existing vlan, that is, q-in-q? The foundry/brocade approach would be to override the frame tag on the entry and exit ports and declare those ports as access-ports (untagged to transport-vlan XYZ), thus transporting anything that comes in there via vlan XYZ to the destination. Or is LACP more low-level and can't be tricked to be relayed by playing with frame types? Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] IP network not reachable from switzerland - 69.162.65.122, but from outside, eg belarus/brasil
so host 69.162.65.122 is only answering to ICMP echo requests, and listens to tcp25 and tcp80 could you be so kind and check, if you can connect to this host, and tell me, via which ISP / peering ? Does _not_ work when exiting via the preferred path (I see two primary routes, one via 6461_46475 and one via 12179_46475, whereas the latter has many 12179 prepended and is not normally used). I _could_ get there when exiting via our cogent link (and thus using the 12179 path) _and_ using the cogent link IP address. When I use the same path, but one of our own IP addresses, I can't get there. So, perhaps the problem is not with the reachability of your network from Switzerland, but the reachability of Swiss networks from that IP address? Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] IronPort E-Mail Reputation
4) Loopback* MSN/Hotmail http://postmaster.msn.com/Services.aspx#SenderSolutions Has anyone managed to register their AS or simply some networks with SNDS ? I keep getting the very helpful We're sorry! An error has occurred error on the registration page, and requesting (repeated) help from the contact email msn-s...@microsoft.com returns zip/null/nada... It's like sending mail into a black hole... Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Netclean - news
Excuse my ignorance, since I didn't make it to last SWINOG... the description on their web site implies the system is using BGP to distribute the black list. Assuming this just distributes IP addresses of web servers hosting questionable content, by blocking those, will that not block content of ALL hostings hosted on that IP address? What about hosters who also host other services on that IP address, like perhaps DNS and mail services? I recall a time where an email RBL was implemented using BGP blackholing, and we can into exactly those problems... Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] cybernet/swisscom - anti-spam measures and blacklists
Is anyone else getting emails rejected by cybernet/Swisscom with this message: 2007-11-14T09:54:49+0100 louiswu72 postfix1/error[8302]: 1FD0D2B0FA: to=nn, relay=none, delay=2.4, delays=2.4/0/0/0.01, dsn=4.0.0, status=deferred (delivery temporarily suspended: host mail.-.ch[212.90.199.8] refused to talk to me: 421-We are not currently accepting connections from 88.198.198.123. 421-Reason for temporary block: sending us spam 421 Please try again later. We're terminating this connection now.) This is not gray listing (it would say so if it were), that IP address did send SPAM to us, and got temporarily blacklisted for it. You can contact me privately to sort out the specifics ([EMAIL PROTECTED], or [EMAIL PROTECTED], in order of preference). Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] Looking for CISCO 2511/AS2511-RJ
Hi there, I'm looking for 8-10 of these babies, perferred would be AS2511-RJ (the ones with builtin RJ45 serial ports), but 2511 _with_ octopus cables would do too. Routers should have full flash/dram configuration. Anyone got a pile of these collecting dust in the basement? :) Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Re: blocking ports?
Jonathan, Sorry but I disagree with Per. ISPs have a duty to prevent email Spam which is a terrible curse for us all. If they decide that blocking port 25 outbound will help then they should do it. If you are a user, why can't you use the ISPs relay server? If you are a provider you ought to have your own mail server on a fixed IP address. You'd be amazed how many companies operate their own mail servers, even behind dynamic addresses (in which case they usually use some mailbox polling mechanism to feed their server from mail from the outside), but send outgoing mail directly with SMTP. Of course, one day we need a better protocol than SMTP (*Simple* Mail Transfer Protocol) which was never meant as a global email solution. But until then we have to do something to stop people abusing it. But by killing the payload, not the messenger, please... Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Any others having troubles with mails being rejected by:mail-fwd.mx.hostcenter.com
Therefore, the interface should be standardized, and the filter software should add a header, which provides an URL for the interface, to messages which pass through the filter. Many mail clients (among them those of our favorite business software vendor...) won't display Mail-Headers in any usable form, probably not clickable anyway Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Formmailer-Scripts and Spam
Markus Wild wrote: One that is less cumbersome than the type in the word in the weird image approach is to set a cookie-like hidden parameter from the server when it generates the form (I'm assuming php or perl behind Well, IMHO this is no better than my solution using JS What do you do if someone has cookies disabled? I said cookie-like, not cookies: input type=hidden name=yourgrandmother value=some encrypted hash with some encrypted hash being some encrypted (and binhex64 encoded) serialized record containing the sending IP, a timestamp and whatever else you fancy including. Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Watchguard FB 2 RAM
Does someone know what is the maximum amount of RAM the Firebox 2 accepts? 64MB isn't enough for latest jinstall (o; ;-) The FB3 does 256MB, I don't have a bigger module to try with. And for those who also have a FB3 lying around: the KBD connector assignment for this baby is: 1- Data 2- GND 3- VCC 4- Clock The flash geometry reported in the BIOS is 16 sect, 4 hd, 248 cyl. Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
