[TAG] (forw) Re: SRS development

[Rick Moen]

----- Forwarded message from Daniel Pittman <daniel at rimspace.net> -----

From: Daniel Pittman <daniel at rimspace.net>
To: TAG <tag at lists.linuxgazette.net>
To: luv-main at luv.asn.au
Date: Thu, 31 Aug 2006 14:20:35 +1000
X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Subject: Re: SRS development

Rick Moen <rick at linuxmafia.com> writes:
> Quoting Daniel Pittman (daniel at rimspace.net):
>
>> > Speaking from a domain administrator's perspective, one has _no downside_
>> > from publishing SPF RRs for one's domain.  It's good and useful data,
>> > providing the public with a definitive means of detecting and rejecting
>> > mail forged to dishonestly claim your domain as its origin.
>> 
>> As long as there are no *legitimate* outbound emails using your From
>> address, which is not the case in a wide range of circumstances.
>
> Huh?  Either I'm too tired, or that sentence doesn't parse.  

You are right: I missed a key clause, and it doesn't make sense as it
stands.  The clause in question was "from servers that you don't run."

[...]

> One more time: Why is it not in MY INTEREST AS A DOMAIN OWNER to
> publish SPF RRs in my DNS, given that it immediately and permanently
> prevents credible Joe Job forgery of those domains' mail?  You have
> not addressed my question.
>
> Because you almost certainly can't, sir.  It's a no-brainer boon to
> any domain admin.

It may be beneficial to you, with your userbase and use of email as it
stands.  That depends almost entirely on how you interact with sending
email; if it all comes from a set of servers that you run then, yes, SPF
can be of some benefit.

It isn't a boon for all users: anyone who uses a wide range of other
services that may result in email exiting a server that you don't
control, but with your details, is faced with a range of unpleasant
alternatives.

> All you can do is say "Some applications of it by some other MTAs,
> somewhere, could break $MY_FAVOURITE_FORWARDING".  Which is
> _irrelevant to the question_.

Fair enough.  I still don't agree with that assertion, but I don't think
you will change your mind on that front.

[...]

> Sorry to hear about your problems with forwarding, sending SMTP from
> arbitrary IPs, etc. -- but I fail to see why I should do nothing about
> spammers and malware authors forging my domains, just because _you_ have
> a possible mail-forwarding problem elsewhere entirely that has not
> nothing to do with my domains at all.

I wouldn't suggest doing nothing.  I just wouldn't suggest SPF, as it
represents a solution to the easy part of the "Joe Job" problem, and
hasn't really addressed the hard parts.

> On _that_ matter, basically, when you get tired of saying "No, wait!
> This emergence of warm-bloodedness and live birth is bad, and could make
> life inconvenient for many dinosaurs", you might consider the merits of
> evolving.  ;->

I might well consider those merits.  Just give me a few million years to
see how it works out for y'all. ;)


Seriously: I am sorry you feel that my objection that SPF and SRS break
real world use of email is not a good objection to the use of SPF.

You are right, though: I don't have any further argument to oppose it.

So, be my guest.  Go ahead and advocate the deployment of SPF more
broadly, and the widespread use of it.   ;)


Perhaps I am wrong, and the existing and valuable services are, in fact,
not as valuable -- or as existing -- as I believe.

Perhaps SPF does, in fact, address these issues and I can't see that, or
they are irrelevancies, a legacy of times gone by when the Interweb was
a friendlier place or something.


I am sorry, though, if you feel that is avoiding your questions.  
I don't believe it is, and it certainly isn't an intentional avoidance
of them.  

I think we simply have different values here: you obviously value the
benefits that SPF records bring you justify the cost, which is fine.  

I see SPF as a bad solution, because it cannot work in a number of
environments that I deal with.  Without that being solved[1] SPF is a
loss for us.

Regards,
        Daniel

Footnotes: 
[1]  ...through SRS being deployed by every service provider we use,
     or something similar.

-- 
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: contact at digital-infrastructure.com.au
                 http://digital-infrastructure.com.au/

----- End forwarded message -----
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Wed, 30 Aug 2006 22:01:13 -0700
To: luv-main at luv.asn.au
From: Rick Moen <rick at linuxmafia.com>
To: TAG <tag at lists.linuxgazette.net>
X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Subject: Re: SRS development

Quoting Daniel Pittman (daniel at rimspace.net):

> You are right: I missed a key clause, and it doesn't make sense as it
> stands.  The clause in question was "from servers that you don't run."

OK, imagine I'm right now sitting at a machine I don't run.  I want to
send outbound SMTP mail with an originating domain of "linuxmafia.com".
I see several obvious ways, all of which work, and many of which my
users already use routinely:

1.  Configure a MUA to send using SMTP AUTH on 587/tcp to linuxmafia.com.
    Note that this is a _bog-standard_ solution, pretty much universally
    available.  Just to make double-sure of that, I just checked on a 
    copy of _Microsoft Outlook_.  Even _it_ does it!  It's right there
    in "Add a new e-mail account."

    And, before you say it, your time-honoured ridiculous objection about
    the hotel blocking access to outbound ports or a mandatory
    transparent SMTP proxy isn't likely to apply:  587/tcp doesn't
    invite blocking measures, as its IETF-mandated standard of being 
    used only for _authenticated_ SMTP tends to prevent it from becoming
    the public-menacing sewer that 25/tcp is.

2.  Fire up a Web browser.  Connect to Squirrelmail.

3.  SSH to my shell on linuxmafia.com.  Use mutt.  (If necessary, and 
    on someone's Crippled OS machine, copy putty.exe yet again from 
    the USB flash drive in my pocket.)  This option is available only to
    users who have shell access and like console mailers -- which I do
    -- but that limitation doesn't apply to any of the other answers.

4.  SSH forwarding and a nullmailer.  (And, if they're blocking outbound
    22/tcp, that's perfectly OK:  sshd is also listening on 23/tcp and a 
    couple of others.)

Note:  I've mentioned all of these before.


I'm aware you said "from _servers_ that you don't run".  Sorry, I don't
route my mail (or my users' mail) through servers I don't run.  However,
if I _did_, and relied on either /etc/aliases entries or ~/.forward 
entries on it to redirect my domain's mail, and _if_ that server were so
antique and decrepit that I weren't allowed to copy libsrs into ~/bin 
and use it for my redirects, _then_ I'd just add the machine's IP to my
domain's SPF record, making it an additional authorised MX.  No SRS required.

Don't tell me you didn't think of that?


> It may be beneficial to you, with your userbase and use of email as it
> stands.  That depends almost entirely on how you interact with sending
> email; if it all comes from a set of servers that you run then, yes, SPF
> can be of some benefit.

See rejoinder, above.

> It isn't a boon for all users: anyone who uses a wide range of other
> services that may result in email exiting a server that you don't
> control, but with your details, is faced with a range of unpleasant
> alternatives.

See rejoinder above, and tell me which part of it doesn't work.  
(Hint:  It all works.)

> I wouldn't suggest doing nothing.  I just wouldn't suggest SPF, as it
> represents a solution to the easy part of the "Joe Job" problem, and
> hasn't really addressed the hard parts.

Maybe you're not getting the fact that having rendered Joe Job forgeries
no longer feasible _matters_.  And my having done that didn't damage
anything for anyone -- not me, not my users, and not anyone else.

_If_ I relied on .forward and /etc/aliases forwarding between SMTP hosts for
my in-domain outbound mail, I'd need to revamp to use libsrs.  Which
does work, by the way -- and it's not like it's difficult to deploy,
just a small Perl library, for Ghu's sake.  But I don't need those
things, in part because I long ago classed those as part of the problem,
and something to phase out -- just as open mail relays were, a decade
ago.

> So, be my guest.  Go ahead and advocate the deployment of SPF more
> broadly, and the widespread use of it.   ;)

As chance would have it, that'll be in the next issue of _Linux Gazette_. ;->

> I see SPF as a bad solution, because it cannot work in a number of
> environments that I deal with.

1992:  "I see shutting down open relays as a bad solution, because it
breaks a number of the usage models I deal with."

> ...through SRS being deployed by every service provider we use, or
> something similar.

I'll have to admit I'm curious about _what_ you do that's so dependent
on /etc/aliases-style mail forwarding.  Maybe you're solving the wrong
problem.  Personally, I got away from all that stuff, years and years
ago!

-- 
Cheers,                             * Contributing Editor, Linux Gazette *
Rick Moen                       -*- See the Linux Gazette in its new home: -*-
rick at linuxmafia.com                       <http://linuxgazette.net/>         

----- End forwarded message -----