SPF = Sender Policy Framework (was: Microsoft spam solution<snip>)
Alan Connor
> In article <2Ai3d.4519$bL1....@news20.bellglobal.com>, John
> Doe wrote:
>
>> Sender ID got turned down by both the IETF and Time Warner/AOL
>> as a way to solve the spam problem. The issue has apparently
>> nothing to do with the technical merits of MSFT's solution,
>> but rather, with concerns of these parties and the open source
>> community that MSFT would somehow use this to get some sort of
>> leverage, based on past MSFT's business practices.
>
> Of course. M~FT needs to replace the public SMTP email system
> with something that hinders its competition and generates a
> revenue stream. Adding a patented feature does exactly that.
>
>
>> Here's a take on the subject from TF:
>>
>> http://gruia.blogware.com/blog/_archives/2004/9/17/142790.html
>>
>> Question: is there something being developed on this front
>> by any Linux vendor or third-pary open source developer? I
>> imagine the answer is "yes",
>
> Sender Policy Framework http://spf.pobox.com/
>
Looks promising. From that site:
<quote>
In this example, AOL.com is the sending domain, and
pobox.com is the receiver.
AOL publishes an SPF record, specifying which computers on
the Internet can send mail as us...@aol.com
1. When a real AOL user sends mail, pobox.com receives the
message from an AOL server.
2. Pobox checks AOL's SPF record, to make sure the server is allo
wed to send mail from AOL.
3. The server is listed, so Pobox gives the message a pass.
(Expensive content-based spam checks can be bypassed, saving reso
urces on the receiver side.)
-------------
1. When a spammer forges mail from AOL, Pobox receives the
messages from an outside server.
2. Pobox checks AOL's SPF record.
3. The server is not listed, so Pobox gives the message a
fail.
(Expensive content-based spam checks can be bypassed, saving reso
urces on the receiver side.)
....
If you do get spam that passed an SPF check, then you know you
should hold the sending domain responsible for the message.
</quote>
http://spf.pobox.com/howworks.html
AC
--
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb
Jonathan Bryce
> In this example, AOL.com is the sending domain, and
> pobox.com is the receiver.
>
> AOL publishes an SPF record, specifying which computers on
> the Internet can send mail as us...@aol.com
>
> 1. When a real AOL user sends mail, pobox.com receives the
> message from an AOL server.
>
> 2. Pobox checks AOL's SPF record, to make sure the server is allo
> wed to send mail from AOL.
> 3. The server is listed, so Pobox gives the message a pass.
>
> (Expensive content-based spam checks can be bypassed, saving reso
> urces on the receiver side.)
So the spammer sends mail from a trojaned AOL user with a fake aol.com
address, and the spam gets through.
Geoffrey King
> So the spammer sends mail from a trojaned AOL user with a fake aol.com
> address, and the spam gets through.
Thats a problem SPF isn't trying to solve. All the SPF does is stop
address spoofing.
--
Try `stty 0' -- it works much better.
Alan Connor
Yeh. That could happen. Or they could sign up for AOL (how many
months free?) using a hundred different names, spam from each
until they got shut down, then dump it and move to the next.
Same for any major ISP: Their bureaucracies are dumb as bricks
and slow as molasses in January, CYA being the name of the game,
and the people in charge aren't the ones that understand the
networking protocols and their real world applications.
But SPF still looks like it would help a lot. Could just be a
file the MTA accessed that was updated every hour from an SPF
server. That would be often enough, I'm guessing.
alt
> On Sun, 19 Sep 2004 23:39:55 +0100, Jonathan Bryce wrote:
>
>> So the spammer sends mail from a trojaned AOL user with a fake
>> aol.com address, and the spam gets through.
>
> Thats a problem SPF isn't trying to solve. All the SPF does is stop
> address spoofing.
>
It's still a big improvement.
--
Donovan Hill
Canadian, Linux User, All around nice guy!
huey.c...@gmail.com
...but only through AOL's mailserver farm, so they can detect and either
rate-limit or shut down consumer accounts that are sending ~way~ too
much mail for a consumer.
(next, you say: "Okay, so they send only a small number of messages each
through a large number of trojanned AOL users, and the spam gets
through")
...but still only through AOL's mailserver farm, so they can detect
large numbers of customers all sending substantively similar messages,
and shut down ALL of them.
--
Huey
Murray Watson
i...@eclipse.net.uk>, on Sun, 19 Sep 2004 23:39:55 +0100, Jonathan
Bryce says...
Read this before discarding SPF for it's intended purpose.
http://spf.pobox.com/rationale.txt
It's not a spam solution, it's a forgery prevention tool and it's a
no-lose situation for both sender and receiver. Quite simple for the
sender to implement and depending on your SMTP server it could be
simple for the receiver to implement.
The targeted advantage is not for the receiver but the sender. I'm
really surprised that banks and phishing targets like paypal haven't
jumped on immediately. A simple line of text in their DNS will help
thwart financial phishers and reduce their customer service costs.
Top left hand corner of the home page http://spf.pobox.com
SPF: Sender Policy Framework
The Anti-Forgery solution
That's making the world a
Safer place for email.
http://spf.pobox.com/faq.html#churn mentions spam but only to the
effect that it will disrupt some spammer methods, admitting to an
"arms race" but you now have a choice of whether you will allow a
spammer to victimize you by forging your domain, resulting in floods
of bounces back to you and diminishing the value of your domain name.
You are now "master of your domain" not implying the Seinfeld
connotation.
Adelphia already has a strict designation of what IP addresses are
authorised to send email with a from address containing
@adelphia.net.
v=spf1 mx ip4:68.168.78.0/24 -all
If it has a From: containing @adelphia.net, it must come from
68.168.78.0/24, no exceptions. Anything else and they expect that
you will treat it as spam. I applaud them for instituting SPF strict
and early regardless of any of their other flaws.
Several years back Juno.com was almost driven to extinction because
they were the top forged domain. @juno.com had become a "spam
signature".
There are some side effects that will impact spam, some things twice
removed. I think as a result, some trojans will evolve to attempt to
hijack the local Outlook to send spam, this will result in consumer
networks like Adelphia cleaning up their trojaned clients more
quickly.
Spammers will begin to publish their own SPF but will have to rotate
through domains rapidly, increasing work and cost.
They'll be forced to manage fewer, larger centralized DNS servers
with domains that can be revoked, if we can maintain the current
trend of registrars canceling spam domains. We've got to educate
them on how to remove registered name servers.
Dave Uhring
> We've got to educate them on how to remove registered name servers.
What does that mean?
Murray Watson
<pan.2004.09.20....@yahoo.com>, on Sun, 19 Sep 2004
21:15:42 -0500, Dave Uhring says...
> On Sun, 19 Sep 2004 21:56:51 -0400, Murray Watson wrote:
>
> > We've got to educate them on how to remove registered name servers.
>
> What does that mean?
It's in this thread Message-ID: <16d694b9.04091...@posting.google.com>
http://groups.google.com/groups?&threadm=16d694b9.0409131408.216e49c4%40posting.google.com
Dave Uhring
That does not answer the question about what a "registered name server"
is. When I register a domain the technical information I provide is the
domain name and the IP addresses or hostnames of the two name servers
which are authoritative for that domain.
What is a "registered name server" which you want removed?
Randolf Richardson
[sNip]
> That does not answer the question about what a "registered name server"
> is. When I register a domain the technical information I provide is the
> domain name and the IP addresses or hostnames of the two name servers
> which are authoritative for that domain.
>
> What is a "registered name server" which you want removed?
A "registered name server" is, essentially, a host record as
maintained by Network Solutions (I'm not sure if other Registrars do/can
participate in this, but I've heard that Network Solutions manages this
aspect of DNS and they provide management of host records as a free
service) and used by the root servers for DNS resolution more reliably.
The "host" can be looked up in Network Solutions' WHOIS server, for
example one of my host records is as follows:
telnet whois.networksolutions.com 43
host netware.inter-corporate.com
[sNip]
Hostname: NETWARE.INTER-CORPORATE.COM
Address: 24.87.56.253
System: ? running ?
[sNip]
<Connection terminated by remote.>
Regardless of how I configure my DNS zone to return a different IP
address for "netware.inter-corporate.com," the root servers will override
this by providing the information specified in the host record. This also
seems to speed up DNS resolutiona little bit, by the way, because the root
servers don't have to take addition steps to look up external NS records.
Since it would be impossible for DNS to function if we relied entirely
on DNS servers by name, the "host" record is needed to set up a "registered
name server."
One of my criteria for picking a Registrar is that they understand
this concept and can support it. So far only Network Solutions has
satisfied me in this regard, which is one of the many reasons I use them as
my Registrar.
--
Randolf Richardson, pro-active spam fighter - r...@8x.ca
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding to my
postings in the newsgroups.
Sending eMail to other SMTP servers is a privilege.
chris-...@roaima.co.uk
> But SPF still looks like it would help a lot. Could just be a
> file the MTA accessed that was updated every hour from an SPF
> server. That would be often enough, I'm guessing.
You do a real-time lookup via the DNS. Take a look at some of the
many articles describing how to use/implement SPF. One I liked
was published a few months ago by Linux Journal (part 1 of 2 is at
http://www.linuxjournal.com/article.php?sid=7327).
SPF's big advantage is that it provides for authentication of domains
without blocking domains that have not subscribed to its approach. It
does have disadvantages (header rewriting required for email forwarding,
no authentication of users, to name but two), but because it's as easy
as pie to sign up for what is effectively an anonymous dial-up account
from any ISP, I don't believe it's the right place to solve that problem.
Chris
Randolf Richardson
[sNip]
> SPF's big advantage is that it provides for authentication of domains
> without blocking domains that have not subscribed to its approach.
[sNip]
That all depends on how it gets implemented. Someone could just as
easily configure their SMTP servers to reject all IDNs (Internet Domain
Names) that don't have SPF records.
Alan Connor
> In comp.os.linux.security Alan Connor <zzz...@xxx.yyy> wrote:
>
>> But SPF still looks like it would help a lot. Could just be a
>> file the MTA accessed that was updated every hour from an SPF
>> server. That would be often enough, I'm guessing.
>
> You do a real-time lookup via the DNS. Take a look at some of
> the many articles describing how to use/implement SPF. One I
> liked was published a few months ago by Linux Journal (part 1
> of 2 is at http://www.linuxjournal.com/article.php?sid=7327).
>
Thanks. I'll read that.
> SPF's big advantage is that it provides for authentication of
> domains without blocking domains that have not subscribed to
> its approach. It does have disadvantages (header rewriting
> required for email forwarding, no authentication of users, to
> name but two), but because it's as easy as pie to sign up for
> what is effectively an anonymous dial-up account from any ISP,
> I don't believe it's the right place to solve that problem.
>
> Chris
SPF doesn't have to solve every problem that plagues email.
I think we agree on that. But it looks to me like it would
help with a lot of them.
I'd favor eliminating the Bcc header too: If someone wants
to keep the names of other subscribers to a mailing list
from each subscriber, then they'd have to send out a seperate
mail to each one. This would be *very* easy to implement.
Randolf Richardson
[sNip]
> I'd favor eliminating the Bcc header too: If someone wants
> to keep the names of other subscribers to a mailing list
> from each subscriber, then they'd have to send out a seperate
> mail to each one. This would be *very* easy to implement.
It's pretty obvious that you don't really know how SMTP works...
An eMail client will typically display "BCC:" information to the user
composing the message (so they can choose hidden recipients), but the
"BCC:" field will be omitted when sending multiple "RCPT TO:" commands for
a single SMTP Envelope (this is one of the ways that eMail is quite
different from Postal Mail; the Post Office can't duplicate letters when
multiple recipients are listed on a single envelope).
Also, mailing list servers don't typically use "BCC:" headers for the
same reason.
Bill Cole
Dave Uhring <daveu...@yahoo.com> wrote:
Correction: IP addresses AND hostnames. This is relevant to your
question...
> What is a "registered name server" which you want removed?
There is a free-standing A record carried by each TLD root for each
authoritative nameserver used by domains in the TLD. It used to be that
you had to register those nameservers as a separate process from domain
registration, but now it seems that the registry records get created
every time a new authoritative server is referenced by a domain record.
This provides a sort of backdoor nameservice that is effectively
bulletproof. The name is resolvable even if it is in a domain without
nameservice, because the TLD roots have that glue record.
--
Now where did I hide that website...
Sam
> I'd favor eliminating the Bcc header too:
Beavis: the Bcc: header is already "eliminated", either by the MUA right off
the bat, or by its smarthost.
> If someone wants
> to keep the names of other subscribers to a mailing list
> from each subscriber, then they'd have to send out a seperate
> mail to each one. This would be *very* easy to implement.
It's only easy because you don't have to implement it yourself.
Jonathan de Boyne Pollard
And indeed this is well known in certain circles, including the MARID
working group.
<URL:news://news.gmane.org./20040914064...@nic.fr>
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-spf-is-harmful.html>
Nonetheless, it continues to be advertised as such:
"SPF reduces inbound spam."
-- <URL:http://spf.pobox.com./execsumm.html>
"If the message fails SPF tests, it's a forgery.
That's how you can tell it's probably a spammer."
-- <URL:http://spf.pobox.com./faq.html>
(That first sentence is a lie, of course.)
"Eventually, as SMTP improves its immunity to spam,
we hope spammers will get discouraged."
-- <URL:http://spf.pobox.com./faq.html>
"'Why should SPF succeed when similar proposals have failed
in the past?' The spam problem was never as bad in the past
as it is now."
-- <URL:http://spf.pobox.com./faq.html>
"Saving the world from spam is an expensive duty."
-- <URL:http://spf.pobox.com./donations.html>
Murray Watson
"registered host" is more accurate, some call it a "registered
server". I'm not sure of any other uses for registered hosts other
than nameservers. I'm sure there are but it is predominantly used for
nameservers.
When your dns resolver looks-up hotmail.com to find the IP address for
hotmail's "www" server or it's mail server, it first looks to
root-servers.net to see who's responsibile for .com which is
gtld-servers.net.
gtld-servers.net is then queried to find the NS records (nameservers)
for hotmail.com. ns1.hotmail.com among others is returned, now the
resolver asks GTLD servers for the respective IP addresses for the
nameserver names returned by the prior query, how else will it know
the IP address of ns1.hotmail.com.
For the GTLD servers to function as a dns server of sorts for
hotmail.com to provide IP addresses of hotmail.com's dns servers,
hotmail.com must have registered specific hostnames and their
corresponding IP address as well as what the designated nameserver
names are for the domain hotmail.com. Hence the name "registered
host".
This setup works well for a hosting company like rackspace.com that
provides DNS for thousands of domains. If they change the IPs of
nameservers provided for their customers use, all they need to do is
change the IP address of the registered host. They won't have to do
anything on a per domain basis. junkdtectr.com will be pointing to
ns1.rackspace.com as it's nameserver.
That's my take on it anyway. Would someone please correct me if I've
got something wrong.
Dave Uhring
> Dave Uhring <daveu...@yahoo.com> wrote in message news:<pan.2004.09.20....@yahoo.com>...
>> On Sun, 19 Sep 2004 23:03:30 -0400, Murray Watson wrote:
>>
>> > In news.admin.net-abuse.email - article
>> > <pan.2004.09.20....@yahoo.com>, on Sun, 19 Sep 2004
>> > 21:15:42 -0500, Dave Uhring says...
>> >> On Sun, 19 Sep 2004 21:56:51 -0400, Murray Watson wrote:
>> >>
>> >> > We've got to educate them on how to remove registered name servers.
>> What is a "registered name server" which you want removed?
> For the GTLD servers to function as a dns server of sorts for
> hotmail.com to provide IP addresses of hotmail.com's dns servers,
> hotmail.com must have registered specific hostnames and their
> corresponding IP address as well as what the designated nameserver
> names are for the domain hotmail.com. Hence the name "registered
> host".
Now if Microsfot's hotmail.com domain were revoked would its domain name
still be associated with ns[1|2|3|4].hotmail.com and further associated
with IP addresses assigned to those nameservers at the GTLD servers?
If not then just what does this mean "We've got to educate them on how
to remove registered name servers."?
Alan Hodgson
> There is a free-standing A record carried by each TLD root for each
> authoritative nameserver used by domains in the TLD. It used to be that
> you had to register those nameservers as a separate process from domain
> registration, but now it seems that the registry records get created
> every time a new authoritative server is referenced by a domain record.
The registrars still have to explicitly register the nameservers.
They probably hide it from the users, though. The only thing that has
changed in regard to .com/.net glue records is that Verisign now
allows the same IP address to be listed many times with different host
names. Previously, a strict 1-1 relationship was preserved.
Blane Bramble
news:Obx3d.437$g42...@newsread3.news.pas.earthlink.net...
> On Mon, 20 Sep 2004 09:33:10 +0100, chris-...@roaima.co.uk
> <chris-...@roaima.co.uk> wrote:
>
>
> I'd favor eliminating the Bcc header too: If someone wants
> to keep the names of other subscribers to a mailing list
> from each subscriber, then they'd have to send out a seperate
> mail to each one. This would be *very* easy to implement.
>
I might be getting hold of the wrong end of the stick, but the "BCC header"
has nothing to do with email delivery - delivery addresses are part of the
SMTP envelope, and nothing to do with any of the headers (which are part of
the content). From a protocol point of view there is no correlation between
the recipient requested by SMTP and the information about who the message is
to within the message headers.
Blane.
Jason Steiner
>
> It's not a spam solution, it's a forgery prevention tool and it's a
> no-lose situation for both sender and receiver.
No loss, and incremental benefit.
It's worth doing just for the little bit it helps, and the more
domains that use it, the more it helps.
> The targeted advantage is not for the receiver but the sender. I'm
> really surprised that banks and phishing targets like paypal haven't
> jumped on immediately. A simple line of text in their DNS will help
> thwart financial phishers and reduce their customer service costs.
It's certainly helped me. There's at least one spammer out there
forging any address that appears in NANAE. I've noticed a definite
decrease in bounces since publishing an SPF record.
> Several years back Juno.com was almost driven to extinction because
> they were the top forged domain. @juno.com had become a "spam
> signature".
$ host -t txt juno.com
juno.com text "v=spf1 ptr:untd.com ptr:netzero.net ptr:juno.com ip4:64.136.0.0/18 ?all"
juno.com text "primary"
> There are some side effects that will impact spam, some things twice
> removed. I think as a result, some trojans will evolve to attempt to
> hijack the local Outlook to send spam, this will result in consumer
> networks like Adelphia cleaning up their trojaned clients more
> quickly.
And this is exactly the point. Spam is a problem of externalized
costs. The costs won't disappear, but if you can push them onto the
parties that actually have the power to stop it, it will stop.
jason
--
"Listen, my boy, I can't abide children. I know it's the style nowadays to
make a terrible fuss over you - but I don't go for it. As far as I'm concerned,
they're no good for anything but screaming, torturing people, breaking things,
smearing books with jam and tearing the pages." - The Neverending Story
Steve Baker
>I'd favor eliminating the Bcc header too: If someone wants
>to keep the names of other subscribers to a mailing list
>from each subscriber, then they'd have to send out a seperate
>mail to each one. This would be *very* easy to implement.
You think changing the SMTP protocol is *easy* to implement, eh,
Beavis?
Steve Baker
Alan Connor
Okay. Thanks. Is there any practical way to *demand* (by the rec-
eiving MTA) a correspondence between the envelope addresses and
the content addresses?
If there is, *then* we could eliminate the Bcc header :-))
Alexander Skwar
> Okay. Thanks. Is there any practical way to *demand* (by the rec-
> eiving MTA) a correspondence between the envelope addresses and
> the content addresses?
Sure. A lot of MTAs (at least Postfix) can do filtering on
the content or even just on the header. As soon you're able
to do that, than it's "easy" to implement something like this.
HOWEVER, be aware that right now such a measure would make it
impossible to receive from mailinglists and newsletters. Those
close to always use a "Bcc mechanism" to mail the mails.
And because of that, I don't see that a mail provider will
implement such a feature w/o risking to alienate the customers.
Alexander Skwar
--
The scum also rises.
-- Dr. Hunter S. Thompson
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Dimitri Maziuk
Have they figured out how to SPF without breaking SMTP yet?
Dima
--
Surely there is a polite way to say FOAD. -- Shmuel Metz
"Go forth and multiply". -- Paul Martin
Randolf Richardson
[sNip]
> Okay. Thanks. Is there any practical way to *demand* (by the rec-
> eiving MTA) a correspondence between the envelope addresses and
> the content addresses?
>
> If there is, *then* we could eliminate the Bcc header :-))
Count me out.
Many of the eMail lists I chose to subscribe to use this mechanism
when distributing a posting to the membership without changing the
"From:," "To:," and "Cc:" SMTP headers, thus making it easy for recipients
to know who the message was really addressed to. Change the "To:" field
from the eMail list's posting address to each individual recipient, and the
membership will be confused.
In the context of eMail lists alone, removing the BCC mechanism will
already cause too many problems.
Randolf Richardson
If I were to design an SMTP alternative/replacement, a BCC mechanism
would definitely be a part of it.
Chris Pugmire
> On 19 Sep 2004 17:26:02 GMT, Cameron L. Spitzer wrote:
>
>
>>In article <2Ai3d.4519$bL1....@news20.bellglobal.com>, John
>>Doe wrote:
>>
>>
>>>Sender ID got turned down by both the IETF and Time Warner/AOL
>>>as a way to solve the spam problem. The issue has apparently
>>>nothing to do with the technical merits of MSFT's solution,
>>>but rather, with concerns of these parties and the open source
>>>community that MSFT would somehow use this to get some sort of
>>>leverage, based on past MSFT's business practices.
>>
>>Of course. M~FT needs to replace the public SMTP email system
>>with something that hinders its competition and generates a
>>revenue stream. Adding a patented feature does exactly that.
>>
>>
>>
>>>Here's a take on the subject from TF:
>>>
>>>http://gruia.blogware.com/blog/_archives/2004/9/17/142790.html
>>>
>>>Question: is there something being developed on this front
>>>by any Linux vendor or third-pary open source developer? I
>>>imagine the answer is "yes",
>>
>>Sender Policy Framework http://spf.pobox.com/
>>
>
>
> Looks promising. From that site:
>
> <quote>
>
> In this example, AOL.com is the sending domain, and
> pobox.com is the receiver.
>
> AOL publishes an SPF record, specifying which computers on
> the Internet can send mail as us...@aol.com
>
> 1. When a real AOL user sends mail, pobox.com receives the
> message from an AOL server.
>
> 2. Pobox checks AOL's SPF record, to make sure the server is allo
> wed to send mail from AOL.
> 3. The server is listed, so Pobox gives the message a pass.
>
> (Expensive content-based spam checks can be bypassed, saving reso
> urces on the receiver side.)
>
> -------------
>
> 1. When a spammer forges mail from AOL, Pobox receives the
> messages from an outside server.
>
> 2. Pobox checks AOL's SPF record.
>
> 3. The server is not listed, so Pobox gives the message a
> fail.
>
> (Expensive content-based spam checks can be bypassed, saving reso
> urces on the receiver side.)
>
> ....
>
> If you do get spam that passed an SPF check, then you know you
> should hold the sending domain responsible for the message.
>
>
We have a variant on this that people may find interesting, by applying a 'default' spf
rule to all domains that don't have real ones the system becomes a lot tighter, and with failures
we give a reject at the recipient stage that includes instructions
for enabling delivery so failures are not critical
See http://netwinsite.com/spf.htm
ChrisP.
Jonathan de Boyne Pollard
c> forwarding, [...]
No, that's Sender ID. SPF involves envelope rewriting.
Alexander Skwar
Wrong. THere are MTAs, that do checks AFTER the . has been sent
and before the mail is queued.
Alexander Skwar
--
One of Bender's kids: Can we have Bender burgers again?
Bender: No, the cat shelter's onto me.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Mark Marcus
Don't let your hatred of AC get in the way of your normally astute
thinking. SMTP _could_ work this way. The protocol (as you know)
could go
EHLO...
MAIL FROM:...
RCPT TO....
DATA...
.
At the "." the MTA could kick a 550 or 553 message: "DATA and RCPT TO
don't match."
But, of course, more than half the mail in the world would never make
it to the destination. So I agree with your overall assessment, it
is a Beavis suggestion.
Mark Marcus
Protect Your Email Address and Make Money too!
http://www.xhome.org My Sales Code is 22819
Murray Watson
$5...@J.de.Boyne.Pollard.localhost>, on Mon, 20 Sep 2004 15:43:15 GMT,
Jonathan de Boyne Pollard says...
> MW> [SPF is] not a spam solution, [...]
>
> And indeed this is well known in certain circles, including the MARID
> working group.
Well then, there you have it. We agree on 1 thing straight away.
> <URL:news://news.gmane.org./20040914064...@nic.fr>
Sorry, can't readily access that.
> <URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-spf-is-harmful.html>
That needs some work, looks like it may have been authored about the
time I first mentioned using DNS to determine authorized servers here
in NANAE 6/1/2000. A lot has changed since then.
> Nonetheless, it continues to be advertised as such:
>
> "SPF reduces inbound spam."
> -- <URL:http://spf.pobox.com./execsumm.html>
Calling that "advertise" is a stretch. Nowhere do they indicate it's
a spam solution, they do point out how spam may be reduced by SPF but
they also point out how spammers will mitigate the damage, the stated
purpose remains, a forgery prevention tool. The truth is, most
people haven't been the victim of forgeries so they tend to minimize
that and focus on _spam_ inflating it out of context. If you have
been victimized by forgeries, it's devastating and SPF's merits for
forgery prevention stand on their own. It's not the best, most
secure method of forgery prevention but it's quick, easy, here and
now.
It will reduce spam but it's not a spam solution. You need to
maintain the statement qualifiers, "A significant majority of spam is
forged. SPF allows your mail servers to easily distinguish forgeries
from real mail". The assertion is forgeries=spam
reduce_forgeries=reduce_spam. I think that's reasonable.
> "If the message fails SPF tests, it's a forgery.
> That's how you can tell it's probably a spammer."
> -- <URL:http://spf.pobox.com./faq.html>
> (That first sentence is a lie, of course.)
Barring transient failures, and the insignificant amount of malicious
forging done by non-spammers, the assertion spf_fail=forgery=spam
will return true.
> "Eventually, as SMTP improves its immunity to spam,
> we hope spammers will get discouraged."
> -- <URL:http://spf.pobox.com./faq.html>
Nothing to do with SPF.
You obviously read the link I pointed to since that statement is from
the section titled "SPF doesn't really STOP spam, does it?"
http://spf.pobox.com/faq.html#churn
Where they cite many ways spammers will navigate around SPF. Hardly
advertising SPF as a spam solution.
> "'Why should SPF succeed when similar proposals have failed
> in the past?' The spam problem was never as bad in the past
> as it is now."
> -- <URL:http://spf.pobox.com./faq.html>
It depends on what you perceive the proposal to be. The home page
has this :
"SPF: Sender Policy Framework
The Anti-Forgery solution
That's making the world a
Safer place for email."
This is in the most predominant position on their home page and this
seems to me to be their proposal:
"What is SPF?
SPF is Sender Policy Framework (link to #howworks)
SPF fights email address forgery and makes it easier to identify
spams, worms, and viruses.
Domain owners identify sending mail servers in DNS.
SMTP receivers verify the envelope sender address against this
information, and can distinguish legitimate mail from spam before any
message data is transmitted."
http://spf.pobox.com/faq.html#howworks
You need to read "The Rationale: SPF Explained" which further
explains what the "proposal" is.
To state that the spam problem is at it's worst when the proposal
will have an effect on how spammers operate by further corralling
spammers into a smaller more readily identifiable space is
reasonable.
> "Saving the world from spam is an expensive duty."
> -- <URL:http://spf.pobox.com./donations.html>
Yup.
As the various media authors have done, you've read into SPF that its
purpose is to be a solution to spam. It's not and they're not
representing it as such. They've stated their goal and methods and
presented workarounds/fixes and patches for various technical issues.
In the process they've indicated how it will address one of the most
common uses of such email forgery today, spam, along with other
common places malicious forgeries are used as indicated in "What is
SPF?" above.
Murray Watson
<g0cnic...@shell.gaydeceiver.com>, on Mon, 20 Sep 2004 12:45:20 -
0700, Jason Steiner says...
> Murray Watson <JunkD...@adelphia.net> wrote:
> >
> > It's not a spam solution, it's a forgery prevention tool and it's a
> > no-lose situation for both sender and receiver.
>
> No loss, and incremental benefit.
>
> It's worth doing just for the little bit it helps, and the more
> domains that use it, the more it helps.
The effort to publish spf records for your domain to minimize the
possibility of that domain being used for someone else's purposes is
a no brainer. If there's a lock on my door, I lock it but then I'm a
fool, I use seatbelts also.
Installing spf on my MX to reject just 1 forged freemail spam, virus
or damned 419 scam a day is worth the effort.
> > The targeted advantage is not for the receiver but the sender. I'm
> > really surprised that banks and phishing targets like paypal haven't
> > jumped on immediately. A simple line of text in their DNS will help
> > thwart financial phishers and reduce their customer service costs.
>
> It's certainly helped me. There's at least one spammer out there
> forging any address that appears in NANAE. I've noticed a definite
> decrease in bounces since publishing an SPF record.
>
> > Several years back Juno.com was almost driven to extinction because
> > they were the top forged domain. @juno.com had become a "spam
> > signature".
>
> $ host -t txt juno.com
> juno.com text "v=spf1 ptr:untd.com ptr:netzero.net ptr:juno.com ip4:64.136.0.0/18 ?all"
> juno.com text "primary"
They survived then merged but they were the big dog in their day.
The original free email provider.
Murray Watson
<pan.2004.09.20...@yahoo.com>, on Mon, 20 Sep 2004
12:07:46 -0500, Dave Uhring says...
As I said,
chris-...@roaima.co.uk
c> forwarding, [...]
Jonathan de Boyne Pollard <J.deBoyn...@tesco.net> wrote:
> No, that's Sender ID. SPF involves envelope rewriting.
Apologies. I mis-remembered my reading of the spec on pobox.com
Chris
Paul Vader
>I might be getting hold of the wrong end of the stick, but the "BCC header"
>has nothing to do with email delivery - delivery addresses are part of the
That's right, in that there's no BCC transaction in SMTP. If beavis is
saying that BCCs are a problem for him, it's because his dumbass C/R system
can't handle them without spamming mailing lists. Remember, It's all about
Alan Connor. *
--
* PV something like badgers--something like lizards--and something
like corkscrews.
Paul Vader
>thinking. SMTP _could_ work this way. The protocol (as you know)
>don't match."
>
>But, of course, more than half the mail in the world would never make
>it to the destination. So I agree with your overall assessment, it
>is a Beavis suggestion.
Even lacking BCCs, any message sent to more than one mailserver will ALWAYS
have a mismatch between the SMTP recipients and the addressees. Apparently,
Beavis thinks that every mailserver gets every RCPT TO. Dumb. *
Alexander W. Skwar
> Mark Marcus <ma...@agentnews.sales.xhome.us> writes:
>
>>thinking. SMTP _could_ work this way. The protocol (as you know)
>>At the "." the MTA could kick a 550 or 553 message: "DATA and RCPT TO
>>don't match."
>>
>>But, of course, more than half the mail in the world would never make
>>it to the destination. So I agree with your overall assessment, it
>>is a Beavis suggestion.
>
>
> Even lacking BCCs, any message sent to more than one mailserver will ALWAYS
> have a mismatch between the SMTP recipients and the addressees. Apparently,
> Beavis thinks that every mailserver gets every RCPT TO. Dumb. *
What are you talking about?
Alexander Skwar
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Randolf Richardson
news.admin.net-abuse.email:
> Paul Vader wrote:
[sNip]
>> Even lacking BCCs, any message sent to more than one mailserver will
>> ALWAYS have a mismatch between the SMTP recipients and the addressees.
>> Apparently, Beavis thinks that every mailserver gets every RCPT TO.
>> Dumb. *
>
> What are you talking about?
Facts (and Paul Vader is absolutely right). This is how SMTP servers
work. Read the relevant RFCs for more details if you don't agree.
Randolf Richardson
> "Blane Bramble" <bl...@spamguard.lyzard.net> writes:
>
>>I might be getting hold of the wrong end of the stick, but the "BCC header"
>>has nothing to do with email delivery - delivery addresses are part of the
>
> That's right, in that there's no BCC transaction in SMTP. If beavis is
> saying that BCCs are a problem for him, it's because his dumbass C/R system
> can't handle them without spamming mailing lists. Remember, It's all about
> Alan Connor. *
That means the mechanism is broken because it's making incorrect
assumptions. I'm wondering if he's too lazy to get things fixed on his end,
and figures that changing the rest of the world may be easier. =D
Sam
> Sam wrote:
>> Beavis writes:
>>
>>
>>>Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>>eiving MTA) a correspondence between the envelope addresses and
>>>the content addresses?
>>
>>
>> No, Beavis. SMTP does not work this way.
>
> Wrong. THere are MTAs, that do checks AFTER the . has been sent
> and before the mail is queued.
And if someone is stupid enough to do just that in this case, they will be
rejecting all ordinary mailing list traffic, and forwarded mail. And that's
why SMTP doesn't work this way.
Next time, try to provide an answer to the actual question being asked.
Sam
> On Mon, 20 Sep 2004 17:38:25 -0500, Sam <s...@email-scan.com> wrote:
>
>>Beavis writes:
>>
>>> Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>> eiving MTA) a correspondence between the envelope addresses and
>>> the content addresses?
>>
>>No, Beavis. SMTP does not work this way.
>>
>
> Don't let your hatred of AC get in the way of your normally astute
> thinking. SMTP _could_ work this way. The protocol (as you know)
> could go
>
> EHLO...
> MAIL FROM:...
> RCPT TO....
> DATA...
> .
>
> At the "." the MTA could kick a 550 or 553 message: "DATA and RCPT TO
> don't match."
And what exactly do you propose to do about ordinary mailing list traffic,
and forwarded mail, where the envelope never matches the headers?
> But, of course, more than half the mail in the world would never make
> it to the destination. So I agree with your overall assessment, it
> is a Beavis suggestion.
So why even waste the electrons mentioning this completely hypothetical and
clearly useless possibility?
Mark Marcus
Sam, I don't want to argue with you because I've agreed with
everything you said. I was simply pointing out that the logic of SMTP
currently COULD support the mail handling that was being discussed
contrary to your assertion that "SMTP does not work this way." It
does: an MTA can kick the message when it receives the end of the
transmitted DATA and could verify the email content at that point.
However, as I qualified (and as youi later assert) even though the
SMTP protocol supports the logic doesn't mean that it's a good idea.
It's just that I was a bit more descriptive than "No. Beavis...."
Alexander W. Skwar
> Mark Marcus writes:
>
>
>>On Mon, 20 Sep 2004 17:38:25 -0500, Sam <s...@email-scan.com> wrote:
>>
>>
>>>Beavis writes:
>>>
>>>
>>>>Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>>>eiving MTA) a correspondence between the envelope addresses and
>>>>the content addresses?
>>>
>>>No, Beavis. SMTP does not work this way.
>>>
>>
>>Don't let your hatred of AC get in the way of your normally astute
>>thinking. SMTP _could_ work this way. The protocol (as you know)
>>could go
>>
>>EHLO...
>>MAIL FROM:...
>>RCPT TO....
>>DATA...
>>.
>>
>>At the "." the MTA could kick a 550 or 553 message: "DATA and RCPT TO
>>don't match."
>
>
> And what exactly do you propose to do about ordinary mailing list traffic,
> and forwarded mail, where the envelope never matches the headers?
Well, the envelope should match the headers. If there's a
To: foo@serverA
the envelope should contain
RCPT TO foo@serverA
But, some of you seem to lack some knowledge in SMTP. If there's
a
To: bar@serverB
there does NOT need to be a
RCPT TO bar@serverB
> So why even waste the electrons mentioning this completely hypothetical and
> clearly useless possibility?
How is it useless?
Alexander W. Skwar
> Alexander Skwar writes:
>
>
>>Sam wrote:
>>
>>>Beavis writes:
>>>
>>>
>>>
>>>>Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>>>eiving MTA) a correspondence between the envelope addresses and
>>>>the content addresses?
>>>
>>>
>>>No, Beavis. SMTP does not work this way.
>>
>>Wrong. THere are MTAs, that do checks AFTER the . has been sent
>>and before the mail is queued.
>
>
> And if someone is stupid enough to do just that in this case, they will be
> rejecting all ordinary mailing list traffic, and forwarded mail. And that's
> why SMTP doesn't work this way.
Well, if there's no Bcc mechanism, then that's not true. The name is
listed in To/Cc, so how is someone "rejecting all ordinary mailing list traffic,
and forwarded mail"?
> Next time, try to provide an answer to the actual question being asked.
Same to you. It seems to me, that all of you are rejecting the
idea, because that AC guy came up with it. Seems like nobody
considers the idea.
Maurice Janssen
>Well, the envelope should match the headers. If there's a
>
>To: foo@serverA
>
>the envelope should contain
>
>RCPT TO foo@serverA
What if I send an email to som...@domain1.net with a CC to
some...@domain2.net. The mail will be deliverd to the MX of
domain2.net with RCPT TO some...@domain2.net while the To: header in
the DATA phase says To: som...@domain1.net.
Ergo: no match.
--
Maurice mauricej (at) xs4all (dot) nl
Alexander W. Skwar
> In comp.os.linux.security, Alexander W. Skwar wrote:
>
>>Well, the envelope should match the headers. If there's a
>>
>>To: foo@serverA
>>
>>the envelope should contain
>>
>>RCPT TO foo@serverA
>
>
> What if I send an email to som...@domain1.net with a CC to
> some...@domain2.net. The mail will be deliverd to the MX of
> domain2.net with RCPT TO some...@domain2.net while the To: header in
> the DATA phase says To: som...@domain1.net.
Well, you will deliver two mails.
Server1:
RCPT TO: someone@domain1
To: someone@domain1
Cc: somebody@domain2
Server2:
RCPT TO: somebody@domain2
To: someone@domain1
Cc: somebody@domain2
> Ergo: no match.
Wrong.
Benno
"Alexander W. Skwar" <fr...@alexander.skwar.name> wrote in message
news:41513B37...@mid.message-center.info...
> > What if I send an email to som...@domain1.net with a CC to
> > some...@domain2.net. The mail will be deliverd to the MX of
> > domain2.net with RCPT TO some...@domain2.net while the To: header in
> > the DATA phase says To: som...@domain1.net.
>
> Well, you will deliver two mails.
>
> Server1:
> RCPT TO: someone@domain1
> To: someone@domain1
> Cc: somebody@domain2
>
> Server2:
> RCPT TO: somebody@domain2
> To: someone@domain1
> Cc: somebody@domain2
Unles you use a smart host in that case
SmartHost:
MAIL FROM: you@yourdomain
RCPT TO: someone@domain1
RCPT TO: somebody@domain2
DATA
The smart host has to copy and send the message to two diffrend servers.
Benno
Alexander W. Skwar
> "Alexander W. Skwar" <fr...@alexander.skwar.name> wrote in message
> news:41513B37...@mid.message-center.info...
>
>>>What if I send an email to som...@domain1.net with a CC to
>>>some...@domain2.net. The mail will be deliverd to the MX of
>>>domain2.net with RCPT TO some...@domain2.net while the To: header in
>>>the DATA phase says To: som...@domain1.net.
>>
>>Well, you will deliver two mails.
>>
>>Server1:
>>RCPT TO: someone@domain1
>>To: someone@domain1
>>Cc: somebody@domain2
>>
>>Server2:
>>RCPT TO: somebody@domain2
>>To: someone@domain1
>>Cc: somebody@domain2
>
>
> Unles you use a smart host in that case
Well, yes, that's right. However, smart hosts already do something
(like SMTP AUTH) to determine if they relay or not. In the case
of a relay, an authorized client may relay and thus for a relay
acting as a smart host, the check would make no sense.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Sam
> Sam wrote:
>> Alexander Skwar writes:
>>
>>
>>>Sam wrote:
>>>
>>>>Beavis writes:
>>>>
>>>>
>>>>
>>>>>Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>>>>eiving MTA) a correspondence between the envelope addresses and
>>>>>the content addresses?
>>>>
>>>>
>>>>No, Beavis. SMTP does not work this way.
>>>
>>>Wrong. THere are MTAs, that do checks AFTER the . has been sent
>>>and before the mail is queued.
>>
>>
>> And if someone is stupid enough to do just that in this case, they will be
>> rejecting all ordinary mailing list traffic, and forwarded mail. And that's
>> why SMTP doesn't work this way.
>
> Well, if there's no Bcc mechanism, then that's not true.
Of course it's true.
> The name is
> listed in To/Cc,
No it's not, not for a mailing list.
> so how is someone "rejecting all ordinary mailing list traffic,
> and forwarded mail"?
Because messages sent to the mailing list are addressed To:
li...@example.com, and when remailed by the listserver, to the subscribers,
verbatim, so now the message's envelope contains the recipients' addresses,
which, of courise, is not reflected in the To: header.
This is not rocket science. It's actually a very simple concept.
>> Next time, try to provide an answer to the actual question being asked.
>
> Same to you. It seems to me, that all of you are rejecting the
> idea, because that AC guy came up with it.
The idea is being rejected because it's stupid.
> Seems like nobody
> considers the idea.
Correct. It's a stupid idea.
Mark Marcus
<fr...@alexander.skwar.name> wrote:
>Maurice Janssen wrote:
>> In comp.os.linux.security, Alexander W. Skwar wrote:
>>
>>>Well, the envelope should match the headers. If there's a
>>>
>>>To: foo@serverA
>>>
>>>the envelope should contain
>>>
>>>RCPT TO foo@serverA
>>
>>
>> What if I send an email to som...@domain1.net with a CC to
>> some...@domain2.net. The mail will be deliverd to the MX of
>> domain2.net with RCPT TO some...@domain2.net while the To: header in
>> the DATA phase says To: som...@domain1.net.
>
>Well, you will deliver two mails.
>
>Server1:
>RCPT TO: someone@domain1
>To: someone@domain1
>Cc: somebody@domain2
>
>Server2:
>RCPT TO: somebody@domain2
>To: someone@domain1
>Cc: somebody@domain2
>
>> Ergo: no match.
>
>Wrong.
>
>Alexander Skwar
This is where those two problems come up: BCC and Groups/Mailing
Lists. Suppose that someone belong to a mailing list called "Stock
Automobiles"
RCPT TO someone@domain1
DATA
To: Stock Automobiles
No match, right? One can argue "well all they have to do is expand
the Group List..." but then that violates the inherent privacy for all
the members of the list and loses the information that the target was
the list.
Also consider the BCC:
RCPT TO someone@domain1
DATA
To: someone2@domain2
The argument I've heard was "well, don't use BCC." But that loses
functionality as described in RFC 822, RFC 2821, etc.
So like I said before, although the SMTP protocol can support this
type of matching, it really isn't workable. (By the way, we can't
translate BCC:'s to TO:'s because that flies in the face of RFC 2821).
Alexander W. Skwar
> Alexander W. Skwar writes:
>
>
>>Sam wrote:
>>
>>>Alexander Skwar writes:
>>>
>>>
>>>
>>>>Sam wrote:
>>>>
>>>>
>>>>>Beavis writes:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>>>>>eiving MTA) a correspondence between the envelope addresses and
>>>>>>the content addresses?
>>>>>
>>>>>
>>>>>No, Beavis. SMTP does not work this way.
>>>>
>>>>Wrong. THere are MTAs, that do checks AFTER the . has been sent
>>>>and before the mail is queued.
>>>
>>>
>>>And if someone is stupid enough to do just that in this case, they will be
>>>rejecting all ordinary mailing list traffic, and forwarded mail. And that's
>>>why SMTP doesn't work this way.
>>
>>Well, if there's no Bcc mechanism, then that's not true.
>
>
> Of course it's true.
Nope.
>> The name is
>>listed in To/Cc,
>
>
> No it's not, not for a mailing list.
Yes, it is. Or it would need to be.
>> so how is someone "rejecting all ordinary mailing list traffic,
>>and forwarded mail"?
>
> Because messages sent to the mailing list are addressed To:
> li...@example.com, and when remailed by the listserver, to the subscribers,
> verbatim, so now the message's envelope contains the recipients' addresses,
> which, of courise, is not reflected in the To: header.
>
> This is not rocket science. It's actually a very simple concept.
You're right. And that's why the recipients adress needs to be in To/Cc. I
really wonder, why you don't get it.
This concept of course makes the number of mails sent out a lot larger.
It may also add some load to mailing list server. However, some mailing list
managers (like Mailman) can already do this. It's called full "personalization",
because it allows the ml admin to add a personalization to the body; like "Hello
Alexander!" or somesuch.
> The idea is being rejected because it's stupid.
Why?
>> Seems like nobody
>>considers the idea.
>
> Correct. It's a stupid idea.
Okay. Why?
Alexander W. Skwar
Well, BCC is to be killed.
> Lists. Suppose that someone belong to a mailing list called "Stock
> Automobiles"
>
> RCPT TO someone@domain1
> DATA
> To: Stock Automobiles
>
> No match, right?
Yep, that's why there should be:
Cc: someone@domain1
> One can argue "well all they have to do is expand
> the Group List..." but then that violates the inherent privacy for all
> the members of the list and loses the information that the target was
> the list.
Nope, because the only recpient listed is someone@domain1. If the mail
is also to be delivered to sombody@domain2, a completely seperate
mail is to be sent out. In this mail, the only recipient is somebody@domain2.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Paul Vader
To repeat - not just for mailing lists. All messages sent to more than one
mailserver will ALWAYS have a mismatch between RCPT TO and inner mail
headers. All you have to do is send a message to two people that don't have
the same mail host. *
Alexander W. Skwar
> Sam <s...@email-scan.com> writes:
>
>>>listed in To/Cc,
>>
>>No it's not, not for a mailing list.
>
>
> To repeat - not just for mailing lists. All messages sent to more than one
> mailserver will ALWAYS have a mismatch between RCPT TO and inner mail
> headers.
Yes. And as you know, that's no problem.
> All you have to do is send a message to two people that don't have
> the same mail host. *
So?
Paul Vader
>> This is where those two problems come up: BCC
>
>Well, BCC is to be killed.
Says who? Alan Frelling Connor?
>> RCPT TO someone@domain1
>> DATA
>> To: Stock Automobiles
>>
>> No match, right?
>
>Yep, that's why there should be:
>
>Cc: someone@domain1
Oh yes - please reveal every name on a mailing list, or require the mailing
list to individually send customized messages to every subscriber. THINK. *
Alexander W. Skwar
> "Alexander W. Skwar" <antw...@alexander.skwar.name> writes:
>
>>>This is where those two problems come up: BCC
>>
>>Well, BCC is to be killed.
>
>
> Says who? Alan Frelling Connor?
Yes. And that's what this thread is about. Killing Bcc. But I don't
care if it's from AC.
>
>
>>>RCPT TO someone@domain1
>>>DATA
>>>To: Stock Automobiles
>>>
>>>No match, right?
>>
>>Yep, that's why there should be:
>>
>>Cc: someone@domain1
>
>
> Oh yes - please reveal every name on a mailing list, or require the mailing
> list to individually send customized messages to every subscriber.
Yes, exactly.
> THINK. *
You don't have to announce that, although it seems to be something
special for you.
Alexander Skwar
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Dimitri Maziuk
[ ... spf breaks smtp ... ]
> Well, BCC is to be killed.
So let's review. Here's a scheme that proposes to get every
sent e-mail message implicitly okayed by sender's sysadmin
by having said sysadmin modify commend field in the DNS.
It is implemented (last I looked) as a Perl patch glued onto
good ole Sendmail.
In order to make it work we need to break the standard we've
been using all these years.
It is marketed as a way to combat spam and comes with
disclaimer: "it's won't stop spam".
Gee, there's nothing wrong with this picture.
Dima
--
Yes, Java is so bulletproofed that to a C programmer it feels like being in a
straightjacket, but it's a really comfy and warm straightjacket, and the world
would be a safer place if everyone was straightjacketed most of the time.
-- Mark 'Kamikaze' Hughes
Alexander Skwar
> Alexander W. Skwar sez:
>
> [ ... spf breaks smtp ... ]
Who's talking about SPF? This thread isn't about SPF, despite
the subject.
>>Well, BCC is to be killed.
>
> So let's review. Here's a scheme that proposes to get every
> sent e-mail message implicitly okayed by sender's sysadmin
> by having said sysadmin modify commend field in the DNS.
You're talking SPF?
Alexander Skwar
--
A neighbor came to Nasrudin, asking to borrow his donkey. "It is out on
loan," the teacher replied. At that moment, the donkey brayed loudly inside
the stable. "But I can hear it bray, over there." "Whom do you believe,"
asked Nasrudin, "me or a donkey?"
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Mark Marcus
<fr...@alexander.skwar.name> wrote:
>Mark Marcus wrote:
.
.
>>
>>
>> This is where those two problems come up: BCC
>
>Well, BCC is to be killed.
>
Hmmm. Interesting concept. What do you give the probability of
changing an RFC that has been in place for two decades, getting the
community at large to accept it, and getting that same community to
rewrite their software to accomodate it?
It's an interesting academical exercise, but completely unworkable.
It's a class of change called "engineer elitism"--you think it's a
good idea but you want everyone to change their business model to
accomodate it. Sometimes it works, but mostly it doesn't.
BCC, by the way, is very important to businesses. When I see my name
in a To: or CC: line, I know I can do a "reply all." If I don't see
it, I know I've been BCC'd and I shouldn't respond. There are many
legitimate reasons why you'd WANT to BCC a person, if I need to
elaborate them, then you haven't worked in a significant position in
the real world.
>> Lists. Suppose that someone belong to a mailing list called "Stock
>> Automobiles"
>>
>> RCPT TO someone@domain1
>> DATA
>> To: Stock Automobiles
>>
>> No match, right?
>
>Yep, that's why there should be:
>
>Cc: someone@domain1
>
>> One can argue "well all they have to do is expand
>> the Group List..." but then that violates the inherent privacy for all
>> the members of the list and loses the information that the target was
>> the list.
>
>Nope, because the only recpient listed is someone@domain1. If the mail
>is also to be delivered to sombody@domain2, a completely seperate
>mail is to be sent out. In this mail, the only recipient is somebody@domain2.
>
>Alexander Skwar
This is workable assuming that your bandwidth can accomodate it. But
consider yahoo groups, some of whom have hundreds (thousands?) of
members. Most of whom are in AOL or YAHOO or HOTMAIL. Think about
all the extra traffic this is gonna generate...
Stefan Monnier
> also to be delivered to sombody@domain2, a completely seperate mail is to
> be sent out. In this mail, the only recipient is somebody@domain2.
OK, so you've now got a system where the recipient is always listed in
the Cc. Now what?
Stefan
Alexander Skwar
> On Wed, 22 Sep 2004 16:11:26 +0200, "Alexander W. Skwar"
> <fr...@alexander.skwar.name> wrote:
>
>
>>Mark Marcus wrote:
>
> .
> .
>
>>>
>>>This is where those two problems come up: BCC
>>
>>Well, BCC is to be killed.
>>
>
>
> Hmmm. Interesting concept. What do you give the probability of
> changing an RFC that has been in place for two decades, getting the
> community at large to accept it, and getting that same community to
> rewrite their software to accomodate it?
Hmmm... 0.000001? Maybe less, but certainly >0. But not much larger
than 0.
> BCC, by the way, is very important to businesses. When I see my name
> in a To: or CC: line, I know I can do a "reply all." If I don't see
> it, I know I've been BCC'd and I shouldn't respond.
Okay, interesting aspect. Haven't thought about this, but since
this is not my proposal, I don't have to think about it :)
There are many
> legitimate reasons why you'd WANT to BCC a person, if I need to
> elaborate them, then you haven't worked in a significant position in
> the real world.
Yeah right. Isn't it rather, that you cannot elaborate on
them, because you don't do any real work?
>>>Lists. Suppose that someone belong to a mailing list called "Stock
>>>Automobiles"
>>>
>>>RCPT TO someone@domain1
>>>DATA
>>>To: Stock Automobiles
>>>
>>>No match, right?
>>
>>Yep, that's why there should be:
>>
>>Cc: someone@domain1
>>
>>
>>> One can argue "well all they have to do is expand
>>>the Group List..." but then that violates the inherent privacy for all
>>>the members of the list and loses the information that the target was
>>>the list.
>>
>>Nope, because the only recpient listed is someone@domain1. If the mail
>>is also to be delivered to sombody@domain2, a completely seperate
>>mail is to be sent out. In this mail, the only recipient is somebody@domain2.
>>
>>Alexander Skwar
>
>
> This is workable assuming that your bandwidth can accomodate it. But
> consider yahoo groups, some of whom have hundreds (thousands?) of
> members. Most of whom are in AOL or YAHOO or HOTMAIL. Think about
> all the extra traffic this is gonna generate...
Well... Interesting aspect, HOWEVER yahoo groups certainly has more than
enough bandwidth, don't you think? No, it's rather that some popular
mailing lists run by "tiny" individuals would suffer the most. A large
company like Yahoo! certainly has to pay for bandwidth as well, but
they are in a better position when shopping for bw.
Alexander Skwar
--
I have that old biological urge,
I have that old irresistible surge,
I'm hungry.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Stefan Monnier
> consider yahoo groups, some of whom have hundreds (thousands?) of
> members. Most of whom are in AOL or YAHOO or HOTMAIL. Think about
> all the extra traffic this is gonna generate...
Have you measured it? I think there's evidence that the increase would be
very minor in practice. Probably SPF increases traffic at least as much.
This was extensively discussed when qmail came out since qmail does exactly
that (it just sends one email per recipient, even if they're all going to
the same MX).
Stefan
Alexander Skwar
For mass mailers, doing the mailing is a bit more expensive.
Alexander Skwar
--
How can you be in two places at once when you're not anywhere at all?
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Mark Marcus
<fr...@alexander.skwar.name> wrote:
>Mark Marcus wrote:
>> On Wed, 22 Sep 2004 16:11:26 +0200, "Alexander W. Skwar"
>> <fr...@alexander.skwar.name> wrote:
.. SNIP...
> There are many
>> legitimate reasons why you'd WANT to BCC a person, if I need to
>> elaborate them, then you haven't worked in a significant position in
>> the real world.
>
>Yeah right. Isn't it rather, that you cannot elaborate on
>them, because you don't do any real work?
>
Okay I'll bite. Here're three:
(1) It's dealing with a confrontation between two employees, but you
(as a manager) want to keep HR informally informed.
(2) Your project is discussing an aspect that could affect your
piece, so you want to keep your supervisor informed about a particular
input you're sending WITHOUT having him subsequently receive all the
"reply alls" that the team members invariably reply with.
(3) You are telling someone off, and you want to show an associate
that you're telling him off--without tipping your hand to that someone
that your response went to other parties.
Are you telling me you've never sent or received a BCC?
Alexander Skwar
> On Wed, 22 Sep 2004 19:00:59 +0200, Alexander Skwar
> <fr...@alexander.skwar.name> wrote:
>
>
>>Mark Marcus wrote:
>>
>>>On Wed, 22 Sep 2004 16:11:26 +0200, "Alexander W. Skwar"
>>><fr...@alexander.skwar.name> wrote:
>
> .. SNIP...
>
>> There are many
>>
>>>legitimate reasons why you'd WANT to BCC a person, if I need to
>>>elaborate them, then you haven't worked in a significant position in
>>>the real world.
>>
>>Yeah right. Isn't it rather, that you cannot elaborate on
>>them, because you don't do any real work?
>>
>
>
> Okay I'll bite.
:)
> Are you telling me you've never sent or received a BCC?
No, of course not ;) I'm always honest and play with open cards
all the time *G*
I said it before, and I say it again: That's one aspect of
BCCs, that I hadn't considered when I defended that anti-BCC
proposal. And the more I think about, the more your objection
makes sense to me as well.
Alexander Skwar
--
Garbage In -- Gospel Out.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
nob...@nowhere.com
: There are many
:> legitimate reasons why you'd WANT to BCC a person, if I need to
:> elaborate them, then you haven't worked in a significant position in
:> the real world.
: Yeah right. Isn't it rather, that you cannot elaborate on
: them, because you don't do any real work?
Can't speak for others but I regularly use BCC for sending out
notices to club members for a club I run. I use BCC so that
members have minimum exposure to spam and to maintain
confidentiality of member's emails ( members don't
see each other listed).
Not great security or the like but sure beats sending every note
with a nice long list of mineable addresses.
It would of course be _possible_ to separately send to
scads of folks but a major PITA at the same time.
Stan
--
Stan Bischof ("stan" at the below domain)
www.worldbadminton.com
Alexander Skwar
> It would of course be _possible_ to separately send to
> scads of folks but a major PITA at the same time.
Yes, if you'd need to do that by hand, then that'd be a major PITA. No
doubt. But if it were real that there's no Bcc, I'd suppose/hope, that
MUAs would take over that job. I think some Windows MUAs (The Bat, Mulberry?)
(optionally) already send out Bcc's seperately, because they add a line
like "you're receiving that mail as a Bcc" to the body.
This kinda defeats the whole purpose of Bcc's, though ;)
Alexander Skwar
--
When the government bureau's remedies don't match your problem, you modify
the problem, not the remedy.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Paul Vader
>> OK, so you've now got a system where the recipient is always listed in
>> the Cc. Now what?
>
>For mass mailers, doing the mailing is a bit more expensive.
Feh. Spammers aren't paying for sending spam - that's the zombie's job. *
Stefan Monnier
>>> also to be delivered to sombody@domain2, a completely seperate mail is to
>>> be sent out. In this mail, the only recipient is somebody@domain2.
>>
>> OK, so you've now got a system where the recipient is always listed in
>> the Cc. Now what?
> For mass mailers, doing the mailing is a bit more expensive.
Huh? It's probably a fairly minor difference (as mentioned elsewhere).
You mean you want to remve Bcc to make mass mailing 20% more expensive?
Come on, now, there's got to be some more significant benefit, or?
Stefan
Sam
> Sam wrote:
>>
>>> so how is someone "rejecting all ordinary mailing list traffic,
>>>and forwarded mail"?
>>
>> Because messages sent to the mailing list are addressed To:
>> li...@example.com, and when remailed by the listserver, to the subscribers,
>> verbatim, so now the message's envelope contains the recipients' addresses,
>> which, of courise, is not reflected in the To: header.
>>
>> This is not rocket science. It's actually a very simple concept.
>
> You're right. And that's why the recipients adress needs to be in To/Cc. I
> really wonder, why you don't get it.
So, instead of sending a single message to a thousand recipients @aol.com,
you want to send a thousand messages instead.
This is an extremely stupid idea, almost reaching the Beavis-stupid level.
> This concept of course makes the number of mails sent out a lot larger.
That's an understatement of the century.
> It may also add some load to mailing list server.
Another understatement of the century.
> However, some mailing list
> managers (like Mailman) can already do this.
And that's why the mailing list vendor I use does not have this "feature"
enabled in mailman. Customization maybe a fine thing for Aunt Matilda's and
Uncle Zeke's family mailing list, with ten subscribers, but it quickly stops
being fun soon thereafter.
> It's called full "personalization",
> because it allows the ml admin to add a personalization to the body; like "Hello
> Alexander!" or somesuch.
>
>> The idea is being rejected because it's stupid.
>
> Why?
See above.
>>> Seems like nobody
>>>considers the idea.
>>
>> Correct. It's a stupid idea.
>
> Okay. Why?
Because someone who actually writes E-mail software, instead of musing
philosophically about it, says so.
Sam
> Yes. And that's what this thread is about. Killing Bcc. But I don't
> care if it's from AC.
You should. It's a given, with 100% certainty, that whatever Beavis says or
suggests, the 180 degree opposite of it will be true, or make sense.
>> Oh yes - please reveal every name on a mailing list, or require the mailing
>> list to individually send customized messages to every subscriber.
>
> Yes, exactly.
No, obviously.
Sam
>> Hmmm. Interesting concept. What do you give the probability of
>> changing an RFC that has been in place for two decades, getting the
>> community at large to accept it, and getting that same community to
>> rewrite their software to accomodate it?
>
> Hmmm... 0.000001? Maybe less, but certainly >0. But not much larger
> than 0.
And, since you're in favor of it, you must believe that you're smarter than
99.999999% of everyone else.
> Well... Interesting aspect, HOWEVER yahoo groups certainly has more than
> enough bandwidth, don't you think?
Bandwidth, shmandwidth… Who cares, as long as it's not my bandwidth?
> No, it's rather that some popular
> mailing lists run by "tiny" individuals would suffer the most. A large
> company like Yahoo! certainly has to pay for bandwidth as well, but
> they are in a better position when shopping for bw.
Well, that's shows what reality you live in. It's actually the small fish
that use mailing list services at either a fixed cost, or with a periodic
message quota. And it's the big fish that actually has to provision for
their bandwidth, and which want to reduce it, as much as possible.
In your fantasy world big ISPs, like Yahoo, AOL, and most Cable ISPs, would
have no reason to use transparent web caches.
Unfortunately, your fantasy world does not resemble the real one, much.
Mark Marcus
.
. <<SNIP>>
.
>>
>> Okay. Why?
>
>Because someone who actually writes E-mail software, instead of musing
>philosophically about it, says so.
>
What kind of email software do you write? (no this is not a
challenge, but genuinely interested). I'm hoping one of the companies
I represent will partner with a developer of the right kind of
software.
Sam
> Stefan Monnier wrote:
>>>Nope, because the only recpient listed is someone@domain1. If the mail is
>>>also to be delivered to sombody@domain2, a completely seperate mail is to
>>>be sent out. In this mail, the only recipient is somebody@domain2.
>>
>>
>> OK, so you've now got a system where the recipient is always listed in
>> the Cc. Now what?
>
> For mass mailers, doing the mailing is a bit more expensive.
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!
You mean, they will now have to employ five thousand hacked zombie spam
relays, instead of two thousand?
John F Hall
>>> so how is someone "rejecting all ordinary mailing list traffic,
>>>and forwarded mail"?
>>
>> Because messages sent to the mailing list are addressed To:
>> li...@example.com, and when remailed by the listserver, to the subscribers,
>> verbatim, so now the message's envelope contains the recipients' addresses,
>> which, of courise, is not reflected in the To: header.
>>
>> This is not rocket science. It's actually a very simple concept.
>
>You're right. And that's why the recipients adress needs to be in To/Cc. I
>really wonder, why you don't get it.
So you're saying that if someone addresses an email to jfh@a, where I
don't read it, bit have arranged for it to be forwarded to jfh@b, the
"To:" line will be changed and I'm no longer allowed to know how the
sender addressed it.
>This concept of course makes the number of mails sent out a lot larger.
>It may also add some load to mailing list server. However, some mailing
>list managers (like Mailman) can already do this. It's called full
>"personalization", because it allows the ml admin to add a
>personalization to the body; like "Hello Alexander!" or somesuch.
What a *horrible* idea. What gives the list manager the right to alter
others' messages?
--
John F Hall
The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.
Sam
> On Wed, 22 Sep 2004 17:56:04 -0500, Sam <s...@email-scan.com> wrote:
> .
> . <<SNIP>>
> .
>>>
>>> Okay. Why?
>>
>>Because someone who actually writes E-mail software, instead of musing
>>philosophically about it, says so.
>>
>
> What kind of email software do you write? (no this is not a
> challenge, but genuinely interested). I'm hoping one of the companies
> I represent will partner with a developer of the right kind of
> software.
Beavis has been trying to figure out who I am for, oh, more than a year now.
It's not really that hard, but is beyong his capabilities (despite his
claims of being an E-mail expert), apparently, and I certainly won't make it
easy for him. You'll just have to prove that you're smarter than Beavis.
Like I said, it shouldn't be that hard.
Alan Connor
<j...@avondale.demon.co.uk> wrote:
Looks like a certain faction here doesn't want to discuss SPF,
but doesn't want to be honest and change the Subject: line
either.
Why is that?
-------------
From: http://spf.pobox.com/howworks.html
In this example, AOL.com is the sending domain, and
pobox.com is the receiver.
AOL publishes an SPF record, specifying which computers on
the Internet can send mail as us...@aol.com
A. When a real AOL user sends mail, pobox.com receives the
message from an AOL server.
B. Pobox checks AOL's SPF record, to make sure the server is allo
wed to send mail from AOL.
C. The server is listed, so Pobox gives the message a pass.
(Expensive content-based spam checks can be bypassed, saving reso
urces on the receiver side.)
OR
A. When a spammer forges mail from AOL, Pobox receives the
messages from an outside server.
B. Pobox checks AOL's SPF record.
C. The server is not listed, so Pobox gives the message a
fail.
(Expensive content-based spam checks can be bypassed, saving reso
urces on the receiver side.)
Skipping ahead:
If you do get spam that passed an SPF check, then you know you
should hold the sending domain responsible for the message.
end quoted material
Not the end of spam, but a big step in the right direction.
I'm not surprised that spammers pretending to be spam fighters
don't want to talk about it, and want people to think it is
much more complex than it is.
AC
--
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb
glgxg
I guess that he's never read the Linux IPv6 manual pages... :-)
Sam
> Looks like a certain faction here doesn't want to discuss SPF,
Beavis, you knucklehead: last week I implemented SPF in my mail server.
Furthermore, I hope that my modest contribution to the discussion in hand
was helpful in the eventual defeat of Microsoft's encumbered Sender-ID
proposal, to the benefit of SPF now being under consideration as an
alternative replacement.
Once again you're flapping your gums without having anything intelligent to
say on the matter.
> but doesn't want to be honest and change the Subject: line
> either.
>
> Why is that?
> -------------
>
> From: http://spf.pobox.com/howworks.html
[ drivelectomy ]
Beavis, I have no doubt that you had absolutely no idea what the entire web
page that you quoted meant to say.
> end quoted material
>
> Not the end of spam, but a big step in the right direction.
>
> I'm not surprised that spammers pretending to be spam fighters
> don't want to talk about it, and want people to think it is
> much more complex than it is.
James Riden
[SPF]
> Not the end of spam, but a big step in the right direction.
SPF is NOT an anti-spam measure, it's an anti-forgery measure.
> I'm not surprised that spammers pretending to be spam fighters
> don't want to talk about it, and want people to think it is
> much more complex than it is.
People like the SPF web page maintainer? "SPF breaks email
forwarding." -- http://spf.pobox.com/srs.html
It's NOT as simple as just adding 'example.com. IN TXT "v=spf1
a:smtp.example.com -all"' to your DNS servers.
(followups set)
--
James Riden / j.r...@massey.ac.nz / Systems Security Engineer
GPG public key available at: http://www.massey.ac.nz/~jriden/
This post does not necessarily represent the views of my employer.
Alexander Skwar
> Alexander Skwar writes:
>
>
>>>Hmmm. Interesting concept. What do you give the probability of
>>>changing an RFC that has been in place for two decades, getting the
>>>community at large to accept it, and getting that same community to
>>>rewrite their software to accomodate it?
>>
>>Hmmm... 0.000001? Maybe less, but certainly >0. But not much larger
>>than 0.
>
>
> And, since you're in favor of it, you must believe that you're smarter than
> 99.999999% of everyone else.
Aha. And you must know better what I want than I do.
>>Well... Interesting aspect, HOWEVER yahoo groups certainly has more than
>>enough bandwidth, don't you think?
>
> Bandwidth, shmandwidth… Who cares, as long as it's not my bandwidth?
You're quite an idiot, aren't you?
>> No, it's rather that some popular
>>mailing lists run by "tiny" individuals would suffer the most. A large
>>company like Yahoo! certainly has to pay for bandwidth as well, but
>>they are in a better position when shopping for bw.
>
> Well, that's shows what reality you live in. It's actually the small fish
> that use mailing list services at either a fixed cost, or with a periodic
> message quota. And it's the big fish that actually has to provision for
> their bandwidth, and which want to reduce it, as much as possible.
>
> In your fantasy world big ISPs, like Yahoo, AOL, and most Cable ISPs, would
> have no reason to use transparent web caches.
Yes, you *are* quite an idiot.
Alexander Skwar
--
It's been a business doing pleasure with you.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Alexander Skwar
> repl...@alexander.skwar.name writes:
>
>>>OK, so you've now got a system where the recipient is always listed in
>>>the Cc. Now what?
>>
>>For mass mailers, doing the mailing is a bit more expensive.
>
>
> Feh. Spammers aren't paying for sending spam - that's the zombie's job. *
Hm. Yes, that's true as well.
Alexander Skwar
--
Q: How was Thomas J. Watson buried?
Ö A: 9 edge down.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Alexander Skwar
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!
>
> You mean, they will now have to employ five thousand hacked zombie spam
> relays, instead of two thousand?
Hm. Are you an idiot or rather a moron? Or maybe both?
Alexander Skwar
--
"It's not just a computer -- it's your ass."
-- Cal Keegan
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Alexander Skwar
> In article <415184B4...@mid.message-center.info>,
> Alexander W. Skwar <antw...@alexander.skwar.name> wrote:
>
>>Sam wrote:
>>
>>>Alexander W. Skwar writes:
>
>
>>>> so how is someone "rejecting all ordinary mailing list traffic,
>>>>and forwarded mail"?
>>>
>>>Because messages sent to the mailing list are addressed To:
>>>li...@example.com, and when remailed by the listserver, to the subscribers,
>>>verbatim, so now the message's envelope contains the recipients' addresses,
>>>which, of courise, is not reflected in the To: header.
>>>
>>>This is not rocket science. It's actually a very simple concept.
>>
>>You're right. And that's why the recipients adress needs to be in To/Cc. I
>>really wonder, why you don't get it.
>
>
> So you're saying that if someone addresses an email to jfh@a, where I
> don't read it, bit have arranged for it to be forwarded to jfh@b, the
> "To:" line will be changed and I'm no longer allowed to know how the
> sender addressed it.
Hm, another valid objection to the idea.
> What a *horrible* idea. What gives the list manager the right to alter
> others' messages?
It's his list, his ressources.
Alexander Skwar
--
We'll try to cooperate fully with the IRS, because, as citizens, we feel
a strong patriotic duty not to go to jail.
-- Dave Barry
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Alexander Skwar
> Alexander W. Skwar writes:
>
>
>>Sam wrote:
>>
>>>> so how is someone "rejecting all ordinary mailing list traffic,
>>>>and forwarded mail"?
>>>
>>>Because messages sent to the mailing list are addressed To:
>>>li...@example.com, and when remailed by the listserver, to the subscribers,
>>>verbatim, so now the message's envelope contains the recipients' addresses,
>>>which, of courise, is not reflected in the To: header.
>>>
>>>This is not rocket science. It's actually a very simple concept.
>>
>>You're right. And that's why the recipients adress needs to be in To/Cc. I
>>really wonder, why you don't get it.
>
>
> So, instead of sending a single message to a thousand recipients @aol.com,
> you want to send a thousand messages instead.
I don't want anything at all. But what you wrote would be a consequence.
> This is an extremely stupid idea,
Why?
>>This concept of course makes the number of mails sent out a lot larger.
>
> That's an understatement of the century.
Okay. So?
>>>The idea is being rejected because it's stupid.
>>
>>Why?
>
> See above.
Where?
> Because someone who actually writes E-mail software, instead of musing
> philosophically about it, says so.
You? Okay, that's a rather a reason that it must be something good.
Alexander Skwar
--
Tonight you will pay the wages of sin; Don't forget to leave a tip.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Alexander Skwar
Okay, no doubt. You ARE an idiot and a moron.
Alexander Skwar
--
You speak of courage. Obviously you do not know the difference between
courage and foolhardiness. Always it is the brave ones who die, the soldiers.
-- Kor, the Klingon Commander, "Errand of Mercy",
stardate 3201.7
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
P.T. Breuer
> Beavis has been trying to figure out who I am for, oh, more than a year now.
> It's not really that hard, but is beyong his capabilities (despite his
> claims of being an E-mail expert), apparently, and I certainly won't make it
> easy for him. You'll just have to prove that you're smarter than Beavis.
> Like I said, it shouldn't be that hard.
As in "amazingly easy". You'll have to send him a note by courier
before he'd get it.
Peter
Randolf Richardson
I'm guessing that reading is a problem for him, period. =D
--
Randolf Richardson, pro-active spam fighter - r...@8x.ca
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding to my
postings in the newsgroups.
Sending eMail to other SMTP servers is a privilege.
Hallvard B Furuseth
>Sam wrote:
>>Alexander W. Skwar writes:
>>>Sam wrote:
>> So, instead of sending a single message to a thousand recipients
>> @aol.com, you want to send a thousand messages instead.
>
> I don't want anything at all. But what you wrote would be a consequence.
>>>This concept of course makes the number of mails sent out a lot larger.
>>
>> That's an understatement of the century.
>
> Okay. So?
[Re-inserted]
>> It may also add some load to mailing list server.
>
> Another understatement of the century.
All right, so you don't think the extra load on the servers matters, nor
the extra bandwidth, or that the users will end up paying for this. And
I suppose users with poor enough connection to notice the extra 20k or
so of headers in each message just ought to get themselves a better
connection.
How about actually reading and replying to the messages, then?
For openers, some user agents will take a little time to parse the 1000
recipients of a message. That probably doesn't matter much with single
messages, but it may matter when an entire mailbox is opened. Though I
suppose the affected people just ought to get themselves better
computers or mail readers, right?
Next, a message arrives to mailinglist with cc: to a few other people.
Someone redirect it to another mailinglist, with cc: to the first
mailinglist and those other people. Now try to reply to that in the
second mailinglist, excluding the first mailinglist but including those
other people. All you have got is a list of 20 recipients; no clue
which of them belong where.
For that matter, when I reply to something, I want to have some clue
about who I'm sending it to, if I ought to cc: it to somewhere else, or
if someone not on the mailinglist should be removed. I can do that with
a few mailinglist names and individual addresses in the headers; I can
not with just a mass of individual addresses.
Next, try to unsubscribe a mailinglist with long-lived discussions.
You'll still be receiving the old discussions; you are in their To: and
cc: headers.
I don't know if you think the mailinglist name shoul be kept in the
headres after the subscribers are added: If not, new subscribers will be
left out of old discussions; if yes, a lot of people will receive
duplicate and soon dozens of each messages. The mailinglist software
could strip duplicates, but that's a pretty fragile solution. For
example, some sites rewrite e-mail addreses to the recipient's
"official" address or something.
--
Hallvard
Jonathan de Boyne Pollard
S> And that's why the mailing list vendor I use does not have this
S> "feature" enabled in mailman. Customization maybe a fine thing for
S> Aunt Matilda's and Uncle Zeke's family mailing list, with ten
S> subscribers, but it quickly stops being fun soon thereafter.
"Customisation" of the message body on a per-recipient basis is largely
irrelevant to public mailing lists where more than just one entity can
post to the list (and indeed is just as _bad_ an idea as modifying
Reply-To: and modifying Subject: are). However, customisation of the
message _envelope_ on a per-recipient basis is very useful to all sorts
of mailing lists, as it permits the mailing list software to
automatically detect and unsubscribe the subscriber mailbox names to
which mail cannot be (possibly indirectly) delivered.
Jonathan de Boyne Pollard
S> says or suggests, the 180 degree opposite of it will be true, or
S> make sense.
Steven Maesslein has just posited, in another thread, that Microsoft's
pending patents covering it will be the death knell for SPF. It would
be exceedingly ironic if it turned out that Alan Connor saying
AC> SPF is an extremely good idea.
-- <URL:news:///_no4d.602$zG1...@newsread3.news.pas.earthlink.net>
was the actual death-knell for SPF. (-:
For the benefit of the denizens of misc.legal.computing:
<URL:http://angel.1jh.com./nanae/kooks/alanconnor.shtml#Spammer>
Alexander W. Skwar
> Alexander Skwar wrote:
>
>>Sam wrote:
>>
>>>Alexander W. Skwar writes:
>>>
>>>>Sam wrote:
>>>
>>>So, instead of sending a single message to a thousand recipients
>>>@aol.com, you want to send a thousand messages instead.
>>
>>I don't want anything at all. But what you wrote would be a consequence.
>>(...)
>>
>>>>This concept of course makes the number of mails sent out a lot larger.
>>>
>>>That's an understatement of the century.
>>
>>Okay. So?
>
>
> [Re-inserted]
>
>>>It may also add some load to mailing list server.
>>
>>Another understatement of the century.
>
>
> All right, so you don't think the extra load on the servers matters, nor
> the extra bandwidth, or that the users will end up paying for this.
You know, it's quite interesting to find out what I think :) Especially,
when the opposite is true and just some people read my words in a way,
that allows them to make a joke.
> And
> I suppose users with poor enough connection to notice the extra 20k or
What extra 20k? If you read the other messages, you'll find that
I proposed to send a seperate message for each and every recipient.
> How about actually reading and replying to the messages, then?
Why should I? Sam doesn't care to, so I don't care to read his
message either.
> For openers, some user agents will take a little time to parse the 1000
> recipients of a message. That probably doesn't matter much with single
> messages, but it may matter when an entire mailbox is opened. Though I
> suppose the affected people just ought to get themselves better
> computers or mail readers, right?
Whatever you like.
> Next, a message arrives to mailinglist with cc: to a few other people.
Which is already bad style, even with Bcc.
> Someone redirect it to another mailinglist, with cc: to the first
> mailinglist and those other people. Now try to reply to that in the
> second mailinglist, excluding the first mailinglist but including those
> other people. All you have got is a list of 20 recipients; no clue
> which of them belong where.
And where's the difference to the current situation?
> For that matter, when I reply to something, I want to have some clue
> about who I'm sending it to, if I ought to cc: it to somewhere else, or
> if someone not on the mailinglist should be removed. I can do that with
> a few mailinglist names and individual addresses in the headers; I can
> not with just a mass of individual addresses.
Yep. Remember? Mailinglists send out individual messages?
> Next, try to unsubscribe a mailinglist with long-lived discussions.
> You'll still be receiving the old discussions; you are in their To: and
> cc: headers.
Well. No. You are not. If you read what I wrote, you'll see.
But simply forget about it. Or make more fun by showing that you
just want to bitch at me for me being such an idiot or whatever you're
on.
Alexander Skwar
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Stefan Monnier
> you want to send a thousand messages instead.
Those cases are basically never seen in practice. Or at least, they're lost
in the noise. Some mail daemons like qmail already do "this stupid thing"
just because it's simpler that way.
>> This concept of course makes the number of mails sent out a lot larger.
> That's an understatement of the century.
Actually, no. It's an overstatement.
> Because someone who actually writes E-mail software, instead of musing
> philosophically about it, says so.
Do you have concrete measurements of real world SMTP transactions showing
that the increase in server-load, or network-use, or message-latency would
increase significantly?
The qmail people did actually do some measurements and their conclusion was
that the impact is very small. Now, they probably did have a vested
interested in getting this result, but I still haven't seen any actually
counter-claim.
Stefan