-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 2 Apr 2004, Gabriel Granger spewed into the bitstream:
GG>Hi All,
GG>
GG>I'm really new to SPF and it sounds great but I have some questions
GG>regarding it adoption in large international companies. Basically I
GG>work for a company and we have a product that allows clients to send
GG>emails to their customers (All opt-in) and not SPAM. My question is
GG>with regard to my companies clients where they are large international
GG>organisations where there might be 2 MX records for receiving mail, but
GG>maybe 10 - 20 out bound servers spread across the globe plus dialup
GG>users which will use which ever mail server they can send through based
GG>on the ISP their using in the country their in at that time.
GG>Implementation of SPF for some of these large companies could cause big
GG>problems for their remote/dialup users. And could cost hugh sums of
GG>money for them to comply with and use SPF fully without problems. Is
GG>anyone on this list using SPF or thinking about using in large
GG>international companies? Maybe I'm not getting my head around this
GG>properly?
<rant mode on>
With no offense to you Gabriel I should like to point out that
"...dialup users which will use which ever mail server they can send
through based on the ISP their using in the country their in at that
time."
is often pointed out as a "problem" which would cost money to solve. IMHO
that's just BS (again no offense intended). It's a problem only if they
refuse to understand that they created it through their abject refusal to
abide by the rules in the RFC's. Masquerading the envelope and sending
through a valid MX has been around (and a valid requirement) for years and
years and years. The days of "Mayberry Rules" (IOW when the net was a
kinder gentler place where you could leave your doors unlocked) are long
gone and companies and individuals need to wake up and smell what they're
cooking up in their own kitchens!
An individual or a company cannot complain about spam and viruses and not
accept responsibility for their part in solving the problem and the role
they play in perpetuating the environment which allows it to happen. For
eample, how many companies refuse to do anything to filter these:
(.+\.(ad[ep]|asd|ba[st]|c[ho]m|cmd|cpl|crt|dbx|dll|exe|hlp|hta|in[fs]|isp|lnk|js|jse|lnk|ocx|md[etw]|ms[cipt]|nws|ocx|ops|pcd|pi|pif|prf|reg|scf|scr|sct|sh[bms]|swf|uue|vb|vb[esx]|vxd|wab|ws[cfh]))
Why?
What person in their right mind sees a legitimate reason to allow the
transit of this kind of content? Yet I have been told by many of my
students (I teach Linux classes for Red Hat) that their employers would
never accept a ruleset which rejects those file extensions because it
might interfere with business in some way. Please note that I do not
advocate virus scanners on MTA's unless we're talking about scanning
legitimate attachments. The way I play ball is to simply drop (at the SMTP
port) all of the above listed file extensions. I don't want to scan
them... to hell with that... there is no reasonable explanation or
justification for requiring successful transmission of an executable file
attachment. ALLOWING IT IS THE SOURCE OF THE VIRUS PROBLEM (leaving aside
Microsoft's existence of course)! My systems do not allow transit of this
material *IN* or *OUT*. Then I have people say... "But vendors send me
*.exe's which are actually self decompressing zips!" and I say so what? I
refuse to place a single customer at risk because someone *ELSE* though
that was a good idea when it fact it's one of the least intelligent
solutions available for data transmission because it places entire
enterprises at risk! Have these people never *HEARD* of ftp? Geezuz!
Now... as to the joe-job factor... it is my intent to promote SPF and it's
use everywhere I go. I am currently in the early stages of writing an
advanced MTA course for our curriculum here at Red Hat (due sometime this
fall) and guess what one of the lectures/exercises is going to be about?
Right... implementation of SPF in sendmail and postfix!
So... am I going to promote it? You betcha!
- --
csm
Lunar Linux Project Lead
Disclaimer: "I am not a curmudgeon! No... really..."
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAbZYCq3bny/5+GAcRAskmAJ9NLeql6JCHWzlvUF66/YkcgRs9xgCfcQzD
f+PC3QyoIp/iT9EHkfuw3tg=
=TW9Q
-----END PGP SIGNATURE-----