Contact Me
Home arrow Articles on toningenieur.info arrow IT department @KUG
IT department @KUG Print E-mail
Apr 13, 2010 at 04:51 PM

Sad, but true. The IT department of our university of music not only keeps the technical services at an impressivly insufficient level, they even get worse. I just received an email of their spokeswoman, containing so many technical and syntactical errors, they must have some spent extra time on this foolish act.

Below you can see an excerpt of the pdf (wow, usually such news come as a doc file) they sent out. Sorry, I only received a german version and I'm not going to translate this, it's just not worth it.

KUG madness

So let's start clearing up a few things that weren't understood correctly, as it appears to me.

1. SPF does not in any way increase my security, so please, don't say so. I'm not stupid and I refuse to tolerate such attempts of spoofing me.

2. I don't want to be part of a "Anti-Spam-Abwehr" thing (translated anti spam defense which reads in german as if one was against fighting spam. But wait - how could I, this is just an excellent example of the increased density of buzzwords per sentence, when a completely clueless person has to argue for something he/she doesn't really understand.

3. By advising the students to poll their mailbox through POP or IMAP, you neglect that if you do this via maildrop or fetchmail etc. you just ruin the headers, which could be frustrating for your spam filter since they see strange things (delivery by localhost but not trusted etc.). I did this for years, until I finally wanted to get rid of the error messages about outdated snake oil certificates and authentication problems, because their authentication backend was down twice a week.

4. And even if they keep trying, an URI was/is/will always (be) delimited by slashes, not backslashes, please, it's not that hard to remember and looks awkward. Backslashes are only ment to escape certain special characters and help with some funny OS from time to time.

5. The email system at the KUG has a long, long history of unreliability, being one of the "largest spam traps" that I know - they just couldn't figure out how to separate spam from ham 8) In addition, it already was a pain in the ass getting their webmail to forward emails consistently from your universities mailbox to a working and reliable mailbox system. We are obliged to read our official mailbox, in order to stay up to date with out universities email communication since this is the primary contact for all courses.

6. I checked the date of the announcement and much to my suprise it didn't say first of April: they claim that with SPF everything will be better, but they have to stop "flat forwarding" (sic Novellspeak), because otherwise SPF doesn't work. That of course is utterly nonsense. Maybe they don't know any better but even then it's grossly negligent bullshit at best. It seems as if someone really gets his education from the german wikipedia after selling his common sense. And why do they sacrifize common standard email forwarding in order to enable SPF records? I've been using SPF together with email forwarding at least for five years and it does not interfere in any way.

In addition, SPF doesn't help with UBE that much if you look at the numbers. Technically of course, it's nice to have SPF, but not a must. IMHO it's also a bit deprecated, as it only works well if everybody does it, which hasn't been true the last years, isn't true for now. Further more there are already structural successors (DKIM etc.) ready for the future. Oh, and just for the record, if SPF does anything at all, it increases the probability of an outgoing email not being scored down by other mailservers. It doesn't really help you with incoming emails, since you cannot rely only on a SPF record and never will in the foreseeable future in a serious production mail system, it is just one of numerous characteristics of an email.

So, once again my dear IT experts @the KUG, email forwarding has nothing to do with SPF, as SPF only relies on the propagation of certain distinctive submission entry points (usually called a submission gateway or outgoing mailserver/-relay) . You do that by adding a simple TXT RR record to your SOA file in DNS, claiming that $host/net is allowed to do relaying for your domain - pretty simple and straight forwarded.
Other mailservers then might eventually make a DNS query and compare the submission header of an email with the "official" information about legitimate submission gateways announced by the domain holders. As a fact, very, very few systems really do that, and these systems usually only increase the spam scoring of an incoming email, which shouldn't be a problem for otherwise legitimate content.

I guess what they ment is strongly related to their insufficiency of setting up an outgoing mailrelay (a talented student could do that at this level in less than a week incl. testing) that could be announced in the SPF record. Imagine an email provider providing only incoming mail services, but no outgoing smtp services ... that's what we have here. The problem that might appear through this is, that with forwarding people receive their KUG emails on their personal mailbox but if they want to click on the answer button at systems outside of the KUG net, they usually use the smtp server propagated by their ISP, which of course violates the KUG SPF record. That wouldn't be a problem if the KUG provided a simple outgoing relay that allows submission by authenticated user clients (as e.g. the TUG does). The technically correct solution would be a central mailrelay, nothing else. Eventually a little tiny VPN concentrator could do the trick as well for a few externals, if they fear modernizing their current smtp infrastructure so much. You can announce (VPN-) subnets in a SPF record as well, if you like to.

<Previous   Next>
Page generated in 0.003103 seconds