Mailing List Archive

On Wed, Mar 10, 2004 at 06:08:35PM -0600, Bob Apthorpe wrote:
> Hi,
>
> On Wed, 10 Mar 2004, Kelson Vibber wrote:
>
> > At 02:58 PM 3/10/2004, Mark C. Langston wrote:
> > >With SPF, I can decide whether or not MY domains use SPF. However, I have
> > >no control over whether the service currently providing my IP transit is
> > >using SPF, and thus whether any mail sent by me while using
> > >that transit is going to be affected by SPF (e.g., transparent proxies).
> >
> > I think you're misunderstanding something. The publishing side of SPF
> > resides solely in your DNS server. The verification side resides solely in
> > the receiving mail server. The outgoing SMTP server doesn't care about SPF.
>
> I believe that what Mark is getting at is that if
>
> - he prefers (say) to use his AOL address everywhere and
>
> - he sends mail using his AOL address through Earthlink's server, and
>
> - AOL publishes restrictive ("v=spf1 mx -all") SPF records

And

- Mark doesn't have any idea how to insert a "Reply-To:" header
in his email giving to his AOL address, or else his correspondents
use MTAs with no shred of support for this very ancient and
well-honored header.

...

> then any system that makes delivery determinations based on SPF would
> refuse, drop, or badly score his mail. Essentially, he's screwed because
> he doesn't control spoofing policy for his AOL address, AOL does. And
> that's a problem, at least for him and for everyone else relying on the
> current model of lax spoofing policy.

Unless he uses "Reply-To:" instead of attempting to spoof.

Am I missing something terribly obvious here? Mailing lists that
arrogate the destruction and replacement of existing "Reply-To:" headers?

--
Dan Wilder

On Wed, Mar 10, 2004 at 04:29:02PM -0800, Dan Wilder wrote:
>
> - Mark doesn't have any idea how to insert a "Reply-To:" header
> in his email giving to his AOL address, or else his correspondents
> use MTAs with no shred of support for this very ancient and
> well-honored header.

Mark has every clue about how to insert and correctly use a Reply-To:
header. Many MUAs, including many of those on mobile devices, don't
allow the user to insert said header.

Many more end-users are completely unaware of the existence of this
header, let alone how and when to use it, and/or how to get their mail
MUA to insert one.

As I just mentioned, we (those of us having this discussion) are not the
ones who'll be penalized unduly by the changes wrought by SPF or similar
approaches. It's the vast majority of end-users who don't have our
technical knowledge, but who want the freedom and flexibility they see
us enjoying.

"end-user education" has not been, is not, and never will be an adequate
answer to the question, "well, how to you propose overcoming this
problem here?" If it were, viruses and spam would be a non-issue today.


--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org

At 04:01 PM 3/10/2004, Mark C. Langston wrote:
>would you put comcast.net in your allow: for tcpwrappers to enable a
>single person access to your machines?

Of course not. There have been better solutions available for a long time.

>If not, then why would you allow an entire ISP the privilege of
>joe-jobbing your address?

Because it's better than letting the entire Internet do it, which is the
way it works right now.

I don't think SPF is going to be the be-all and end-all of anti-spoofing,
anti-spam, or anti-anything. But it's better than nothing, and while there
are other schemes out there, SPF is the first to get this level of
widespread testing. It's a stop-gap measure, but I'd rather implement a
stop-gap now and a better solution two years from now than wait two years
before doing anything.


Kelson Vibber
SpeedGate Communications <www.speed.net>

At 04:01 PM 3/10/2004, Mark C. Langston wrote:
>would you put comcast.net in your allow: for tcpwrappers to enable a
>single person access to your machines?

Of course not. There have been better solutions available for a long time.

>If not, then why would you allow an entire ISP the privilege of
>joe-jobbing your address?

Because it's better than letting the entire Internet do it, which is the
way it works right now.

I don't think SPF is going to be the be-all and end-all of anti-spoofing,
anti-spam, or anti-anything. But it's better than nothing, and while there
are other schemes out there, SPF is the first to get this level of
widespread testing. It's a stop-gap measure, but I'd rather implement a
stop-gap now and a better solution two years from now than wait two years
before doing anything.


Kelson Vibber
SpeedGate Communications <www.speed.net>

On Wed, Mar 10, 2004 at 02:58:31PM -0800, Mark C. Langston wrote:

> With SPF, I can decide whether or not MY domains use SPF. However, I
> have no control over whether the service currently providing my IP
> transit is using SPF, and thus whether any mail sent by me while using
> that transit is going to be affected by SPF (e.g., transparent proxies).

Ahhhaaaa. You are worried about loosing the ability to force your
thoughts upon other peoples policy.

Yes, you are correct. When you spoof someone else's domain name
and when that domain does not allow you to do so, third party gateways
may opt to block your message.

Easy way around it: use your own domain and set a policy for that domain
yourself. Try "v=spf1 +all".

> So, it boils down to a control issue. With SA, I have control, and when
> I don't have control, the worst that happens is that I'm inconvenienced
> by my email going to a folder I wasn't expecting.

> Imagine for a second that almost every MX on the planet implemented rDNS
> checks. Now imagine that your ISP suddendly botched their rDNS zones,
> and didn't fix them. Your mail starts bouncing, you weren't expecting
> it to, you weren't aware that the problem existed, and you're powerless
> to change the situation (except to change providers).

So? Imagine that your provider does one of the 1001+ other things it
could do wrong. Shit happens.

Using this kind of arguments means you want to get rid of every
protocol the Internet is built on. The "things can go wrong so
this protocol is breaking stuff" is valid for many RFCs.

> (Of course, I'm one of those strange people that seems to think that a
> client connecting directly to the destination MX is still fine. I think
> some of the SPF proponents may be operating under the assumption that
> any and all email should always be handed off through a smarthost
> somewhere, so that only MXes ever talk to MXes.)

If you are connecting to my MX, and if the domain name you are using in
your envelope_from is allowing your IP address, you would not be blocked.

If you are connecting to my MX, and if the domain name you are using in
your envelope_from is NOT allowing your IP address, you WILL be blocked.

See? You _are_ in control.

Either you use _your_ domain and set _your_ DNS records correct, or
you use someone else's domain and _they_ edit DNS. By doing so, they
are authorizing you do use _their_ domain name from _your_ computer.


The current setup @aol does allow you to use "yourname@aol.com" in
the envelope. Would they change "?all" into "-all", they are saying
you MUST not use their domain from your IP address.

SPF gives control back to aol and you seem to dislike that. Just
make sure your envelope_sender is NOT using THEIR name and you'll
be fine.

Alex
--
begin sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags

On Wed, Mar 10, 2004 at 06:08:35PM -0600, Bob Apthorpe wrote:

> > At 02:58 PM 3/10/2004, Mark C. Langston wrote:
> > >With SPF, I can decide whether or not MY domains use SPF. However, I have
> > >no control over whether the service currently providing my IP transit is
> > >using SPF, and thus whether any mail sent by me while using
> > >that transit is going to be affected by SPF (e.g., transparent proxies).
> >
> > I think you're misunderstanding something. The publishing side of SPF
> > resides solely in your DNS server. The verification side resides solely in
> > the receiving mail server. The outgoing SMTP server doesn't care about SPF.
>
> I believe that what Mark is getting at is that if
>
> - he prefers (say) to use his AOL address everywhere and
>
> - he sends mail using his AOL address through Earthlink's server, and
>
> - AOL publishes restrictive ("v=spf1 mx -all") SPF records
>
> then any system that makes delivery determinations based on SPF would
> refuse, drop, or badly score his mail. Essentially, he's screwed because
> he doesn't control spoofing policy for his AOL address, AOL does. And
> that's a problem, at least for him and for everyone else relying on the
> current model of lax spoofing policy.

This is *only* envelope spoofing. AOL has every right to deny Mark to
cause problems for AOL. AOL is the one processing the bounces if Mark
is doing something wrong. Could be as silly as "mrak@aol.com".

Easy way out: use your/a local address as envelope sender (RFC821), use
your aol address in "From:" (the RFC822 part).

This is something that can be implemented at the MUA and/or the MTA. Where
it is best to do so depends on the setup. It is something the systems
administrator can do; no user intervention needed.

This is, BTW, a solution for the forwarding problem as well. If your
MTA is sending messages to my MTA, I will deliver the resulting bounce
to your MTA and NOT TO $innocent_third_party.

Alex
--
begin sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags

On Wed, 2004-03-10 at 14:58, Mark C. Langston wrote:
> Imagine for a second that almost every MX on the planet implemented rDNS
> checks. Now imagine that your ISP suddendly botched their rDNS zones,
> and didn't fix them. Your mail starts bouncing, you weren't expecting
> it to, you weren't aware that the problem existed, and you're powerless
> to change the situation (except to change providers).

Stuff like that happens all the time. If someone on my subnet spams and
gets our class C listed in a RBL, my mail starts bouncing. I'm
powerless to stop it unless I change providers.

> THAT scenario is very much like the one SPF will create: end-user
> ignorance of the change, violation of end-user expectation w.r.t.
> delivery, and complete end-user powerlessness over the situation, except
> to change providers.

Again, this already happens every day with RBLs. So why is SPF being
criticized as a poor solution to a non-existent problem, but RBLs are
okay to use?

> What I'm against is the nave assumption that once SPF is
> deployed, people will simply, quietly, and willingly go to the
> (sometimes rather great) lengths necessary to upgrade their servers to
> accomodate these, and change the configuration of all their deployed
> clients to take advantage of these changes.)

SPF won't cause people to go through the great lengths necessary to
upgrade their servers and clients, but spam, viruses, and forgeries
will. There are studies that claim spam makes up 60%+ of the Internet's
e-mail traffic. As that number continues to increase, people will
*have* to upgrade their servers to support anti-spam/virus/forgery
measures, or else the signal to noise ratio will continue to drop until
e-mail is useless.

Again, it isn't a magic bullet, but SPF helps. Don't write it off as
nothing just because it isn't perfect in every scenario.

- Jon

--
jon@tgpsolutions.com

Administrator, tgpsolutions
http://www.tgpsolutions.com

On Wed, 10 Mar 2004, Mark C. Langston wrote:

> Mark has every clue about how to insert and correctly use a Reply-To:
> header. Many MUAs, including many of those on mobile devices, don't
> allow the user to insert said header.
>
> Many more end-users are completely unaware of the existence of this
> header, let alone how and when to use it, and/or how to get their mail
> MUA to insert one.
>
> As I just mentioned, we (those of us having this discussion) are not the
> ones who'll be penalized unduly by the changes wrought by SPF or similar
> approaches. It's the vast majority of end-users who don't have our
> technical knowledge, but who want the freedom and flexibility they see
> us enjoying.
>
> "end-user education" has not been, is not, and never will be an adequate
> answer to the question, "well, how to you propose overcoming this
> problem here?" If it were, viruses and spam would be a non-issue today.

And I don't bother trying to explain CSS, SOAP, XML to my mother when
I tell her that her 100MHz computer running Netscape 3.0 will no longer
work when she tries to do her on-line banking. That she just needs
to get a newer machine because the bank udated its systems.

What about all those cell phone users who bought analog phones?
Do you try to explain the technical details of the FOUR different
competing/incompatible digital cell phone transmission methods to
your parents?

Technology advances, time marches on, last weeks gear is obsolete,
people grumble but they -do- upgrade.

Now, this whole argument is a bit silly. All that is needed is
for those mobile device service providers to make sure that their
gateways set the envelope-from to point to thier own servers and
put the user's prefered 'from' address into the header-from.

That will satisfy the SPF requirements and the message recipients
will see the expected 'From:' address.

If you want to gripe about the bounce issue, the mobile service
provider can handle that too. All they need to do is to have some
kind of database that notes the senders prefered 'From:' address
and will route any bounces that hit the envelope-from to that
prefered 'From:' address.
Heck the MSP can even advertise this as a featured service to
attract new customers.


--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

Hello Kelson,

Wednesday, March 10, 2004, 9:53:26 AM, you wrote:

KV> Or how about all those SpamAssassin rules that only score 1 point?
KV> They're obviously not enough to stop spam, so we should just
KV> remove them all.

If we were to remove those rules which score 1.0 or less, my missed
spam counts will go through the roof! A large minority of spam here
is identified as "probably spam" by Bayes, blacklists, or significant
rules, and then is identified as "yep, spam" by rules scoring 0.4 and
0.7 and 0.1 which push the total over my required hits threshold.

But hey, since SA is so readily configurable, you can update your
local.cf to change all scores 1.0 or less down to 0.0. You'll probably
improve your mail processing efficiency also (since I believe rules
with a zero score are skipped during processing).

Bob Menschel

On Wednesday 10 March 2004 11:08 pm, Bob Menschel wrote:
> KV> Or how about all those SpamAssassin rules that only score 1 point?
> KV> They're obviously not enough to stop spam, so we should just
> KV> remove them all.
>
> If we were to remove those rules which score 1.0 or less, my missed
> spam counts will go through the roof! A large minority of spam here
> is identified as "probably spam" by Bayes, blacklists, or significant
> rules, and then is identified as "yep, spam" by rules scoring 0.4 and
> 0.7 and 0.1 which push the total over my required hits threshold.

Exactly my point. Writing off SPF because it doesn't detect *all* spam is
like writing off these rules because *they* don't detect *all* spam. But
every little bit helps, and by layering multiple solutions together you have
a better chance of detecting *more* spam.

--
Kelson Vibber
SpeedGate Communications, <www.speed.net>

Greg Cirino - Cirelle Enterprises wrote:
> | > -----Original Message-----
> | > From: Bart Schaefer [mailto:schaefer@zanshin.com]
> | > > POP-before-SMTP requires no special client support. Just check your
> | > > mail before you send any. There is no "problem" to discuss.
>
> SMTP-AUTH is a much better solution than P-b4-S and is more secure
>
> Greg

We run an ISP, and have used a combination of pop-before-smtp and
SMTP-AUTH for the last several years. We use both because customers are
simply ineducable. When we can, we instruct folks to authenticate.

We have not experienced race conditions.

Since the tool tails a log file it is easy to tweak to parse the output
from an imap (pop-before-smtp simply being a shorter name than
parse-logfile-for-successful-authentication-under-other-protocol-before-allowing-smtp).

Yes, many clients attempt to send before a pop; but believe it or not,
the customers seem to prefer clicking "send/receive" twice rather than
call us and learn.

--
eric

We do pretty much the same thing. When moving the clients over from
Exchange to UW-IMAP authentication was a problem. So we chose to use
DRAC to integrate it with IMAP/POP3. It has been working great for two
years.

I will also agree with Eric that a high percentage of the users out
there are completely confused when we talk about things like setting
permissions on SMTP auth. It's hard enough explaining what pop3 is.

The pop-before-smtp in our case tracks by IP address. If they
auth/access with either POP3 or IMAP they can send through SMTP for up
to 30 minutes (default was 60, changed it before compile). As most
clients check their email every 15 or so this isn't a problem.

To ensure that we do not have problems we have several cronjobs the
number of emails sent over the prior hour, if the number for any given
client exceeds a threshold then we suspend the login account. It isn't
elegant but it works.

Here is one thing that we have encountered before though. We had a
client that used to send out his newsletter to about 4000 people once a
month but he didn't use SMTP to do it. He wrote a creative PHP page
that would do it for him. I think some of the spammers do this as well.
They can have a simple pre-designed web page that pulls they emails from
a database, then they start spamming until the ISP shuts client down
(during which time they get another freebee or cheap account). SMTP
AUTH would do nothing to prevent this.

Okay, now I'm just rambling...

Gary Smith




-----Original Message-----
From: Eric W. Bates [mailto:ericx_lists@vineyard.net]
Sent: Thursday, March 11, 2004 6:53 AM
To: spamassassin-users@incubator.apache.org
Subject: Re: pop-before-smtp Was: Opinions About SPF



Greg Cirino - Cirelle Enterprises wrote:
> | > -----Original Message-----
> | > From: Bart Schaefer [mailto:schaefer@zanshin.com]
> | > > POP-before-SMTP requires no special client support. Just check
your
> | > > mail before you send any. There is no "problem" to discuss.
>
> SMTP-AUTH is a much better solution than P-b4-S and is more secure
>
> Greg

We run an ISP, and have used a combination of pop-before-smtp and
SMTP-AUTH for the last several years. We use both because customers are

simply ineducable. When we can, we instruct folks to authenticate.

We have not experienced race conditions.

Since the tool tails a log file it is easy to tweak to parse the output
from an imap (pop-before-smtp simply being a shorter name than
parse-logfile-for-successful-authentication-under-other-protocol-before-
allowing-smtp).

Yes, many clients attempt to send before a pop; but believe it or not,
the customers seem to prefer clicking "send/receive" twice rather than
call us and learn.

--
eric

On Wed, Mar 10, 2004 at 04:37:00PM -0800, Mark C. Langston wrote:
> On Wed, Mar 10, 2004 at 04:29:02PM -0800, Dan Wilder wrote:
> >
> > - Mark doesn't have any idea how to insert a "Reply-To:" header
> > in his email giving to his AOL address, or else his correspondents
> > use MTAs with no shred of support for this very ancient and
> > well-honored header.
>
> Mark has every clue about how to insert and correctly use a Reply-To:
> header. Many MUAs, including many of those on mobile devices, don't
> allow the user to insert said header.

I didn't mean you! Some generic "Mark." I should have called him "Dan."

> As I just mentioned, we (those of us having this discussion) are not the
> ones who'll be penalized unduly by the changes wrought by SPF or similar
> approaches. It's the vast majority of end-users who don't have our
> technical knowledge, but who want the freedom and flexibility they see
> us enjoying.

But who also want, or will soon want, to be free of the burden of
exponentially increasing spam. The two objectives cannot both be attained.

--
Dan Wilder

On Thu, Mar 11, 2004 at 09:18:10AM -0800, Dan Wilder wrote:
>
> But who also want, or will soon want, to be free of the burden of
> exponentially increasing spam. The two objectives cannot both be attained.
>


So, your position is that we should surrender the liberties we now enjoy
for additional security? A large part of me says that the two need not
be mutually exclusive.


--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org

Kelson Vibber <kelson@speed.net> wrote:
> I won't put words in Chris' mouth, but it seemed to me his point
> *wasn't about SMS* - rather, it seemed to be that, since phones'
> capabilities are constantly changing, now would be a logical time
> to add *useful* features like SMTP-AUTH.

Your assumption is dead-on accurate.

In fact, I wouldn't use a cellphone for email that didn't have it.
(verizon: can you hear me now?)

--

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Chris Barnes AOL IM: CNBarnes
chris-barnes@tamu.edu Yahoo IM: chrisnbarnes
Computer Systems Manager ph: 979-845-7801
Department of Physics fax: 979-845-2590
Texas A&M University

On Thu, Mar 11, 2004 at 10:16:13AM -0800, Mark C. Langston wrote:
> On Thu, Mar 11, 2004 at 09:18:10AM -0800, Dan Wilder wrote:
> >
> > But who also want, or will soon want, to be free of the burden of
> > exponentially increasing spam. The two objectives cannot both be attained.
> >
>
>
> So, your position is that we should surrender the liberties we now enjoy
> for additional security? A large part of me says that the two need not
> be mutually exclusive.

That isn't my position.

My position is there's no prior reason to assume there is no tradeoff.
In some cases, certainly there isn't. In the cases where a tradeoff
is present, what may be acceptable is always a legitimate subject for
discussion.

However this thread has gone on for an awful long time, and is
at this point very far off-topic. I've said my piece and will
now be quiet.

--
Dan Wilder

|----- Original Message -----
|From: "Gary Smith" <gary@primeexalia.com>

|Here is one thing that we have encountered before though. We had a
|client that used to send out his newsletter to about 4000 people once a
|month but he didn't use SMTP to do it. He wrote a creative PHP page
|that would do it for him. I think some of the spammers do this as well.
|They can have a simple pre-designed web page that pulls they emails from
|a database, then they start spamming until the ISP shuts client down
|(during which time they get another freebee or cheap account). SMTP
|AUTH would do nothing to prevent this.

That's a different issue, once the user has any kind of auth the
server will act as an open relay to them (as it is supposed to).

Sending mail via PHP is a common practice. and we see both
spam and non-spam originating from this type of source. The
unfortunate part is the base implementation of the mail() function
sends mail from the server rather than via an SMTP server, but
spammers don't care about that.

(not to say all users of the default mail() function are spammers).

This is also a good argument for using SA to filter content.

We have clients that love spam (spam is their friend) and
those at the other end of the spectrum that go into cardiac
arrest if they get one spam. So we let them set their own level
and I don't hear about it.

I have been researching the SPF model and see some benefit
in the scoring ability to identify the afore mentioned servers as
well as protection from the joe-jobs.

One of our domains got hit hard a while back with a joe-job and
it became a real job emptying out the postmaster mail box with
the bounces, so we just sent everything that wasn't a real address
to the bit bucket. From what I've read, SPF is supposed to send
the bounces back to the last server in the chain and not the
reply-to address... not 100% about this -- still new.

My guess is the SA implementation will be a scoring method
and not a bounce which sounds like the best way to deal with
this (traffic wise). This way even a fail will be able to be scored
appropriately depending on the scenario.

Greg

-----Original Message-----
From: Eric W. Bates [mailto:ericx_lists@vineyard.net]
Sent: Thursday, March 11, 2004 6:53 AM
To: spamassassin-users@incubator.apache.org
Subject: Re: pop-before-smtp Was: Opinions About SPF



Greg Cirino - Cirelle Enterprises wrote:
> | > -----Original Message-----
> | > From: Bart Schaefer [mailto:schaefer@zanshin.com]
> | > > POP-before-SMTP requires no special client support. Just check
your
> | > > mail before you send any. There is no "problem" to discuss.
>
> SMTP-AUTH is a much better solution than P-b4-S and is more secure
>
> Greg

We run an ISP, and have used a combination of pop-before-smtp and
SMTP-AUTH for the last several years. We use both because customers are

simply ineducable. When we can, we instruct folks to authenticate.

We have not experienced race conditions.

Since the tool tails a log file it is easy to tweak to parse the output
from an imap (pop-before-smtp simply being a shorter name than
parse-logfile-for-successful-authentication-under-other-protocol-before-
allowing-smtp).

Yes, many clients attempt to send before a pop; but believe it or not,
the customers seem to prefer clicking "send/receive" twice rather than
call us and learn.

--
eric