Jump to content

Why not whitelists


macquigg

Recommended Posts

Try sending me an email (dmq 'at' pobox.com ) with a forged address "aol.com". Let me know what happens. I think it will be impossible for you to forge the name "aol.com". AOL doesn't allow it.

I just sent a message from my ISP account to my spamcop account using the address forged<at>aol.com and it came through with no problem. I am awaiting a tracking URL for that one. I also performed the test you requested and have not received any bounce message back, but I don't see how I could.

Tracking URL: http://www.spamcop.net/sc?id=z734380153z8f...5dd04a671cd63dz

My poboxes.com address acepted this same message as well as my yahoo account.

Link to comment
Share on other sites

  • Replies 64
  • Created
  • Last Reply
I just sent a message from my ISP account to my spamcop account using the address forged<at>aol.com and it came through with no problem.  I am awaiting a tracking URL for that one.  I also performed the test you requested and have not received any bounce message back, but I don't see how I could.

Which address did you forge? SPF checks the envelope, not any of the headers. Does spamcop.net check SPF records on incoming mail?

I did receive your email. See headers below. It went straight to my spam bucket, with 99% certainty, but it shouldn't have gotten that far if the envelope was forged. If not, you haven't really hidden your true domain.

-- Dave

Return-Path: <SRS0=1WH5=RB=aol.com=forged<at>bounce2.pobox.com>

Delivered-To: dmq<at>gainusa.com

Received: ( **SaniMail 89778 invoked from network** ); 19 Feb 2005 20:27:37 -0000

Received: from unknown (HELO lime.pobox.com) (208.58.1.198)

by mail5.mailsystem.us with SMTP; 19 Feb 2005 20:27:37 -0000

Received: from lime.pobox.com (localhost [127.0.0.1])

by lime.pobox.com (Postfix) with ESMTP id 810311B9A83

for <dmq<at>gainbroadband.com>; Sat, 19 Feb 2005 15:34:12 -0500 (EST)

Delivered-To: dmq<at>pobox.com

Received: from mxsf18.cluster1.charter.net (mxsf18.cluster1.charter.net [209.225.28.218])

by lime.pobox.com (Postfix) with ESMTP id 56B5D1B9A2E

for <dmq<at>pobox.com>; Sat, 19 Feb 2005 15:34:11 -0500 (EST)

Received: from mxip01.cluster1.charter.net (mxip01a.cluster1.charter.net [209.225.28.131])

by mxsf18.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j1JKYA43004461

for <dmq<at>pobox.com>; Sat, 19 Feb 2005 15:34:11 -0500

Received: from cpe-24-177-39-162.ma.charter.com (HELO steven.aol.com) (24.177.39.162)

by mxip01.cluster1.charter.net with ESMTP; 19 Feb 2005 15:34:09 -0500

X-Ironport-AV: i="3.90,100,1107752400";

d="scan'208"; a="580630140:sNHT3090204222"

Message-Id: <5.1.0.14.2.20050219153320.00b80ec0<at>wheresmymailserver.com>

X-Sender:

X-Mailer: QUALCOMM Windows Eudora Version 5.1

Date: Sat, 19 Feb 2005 15:34:06 -0500

To: dmq<at>pobox.com

From: Steven Underwood <forged<at>aol.com>

Subject: AOL test

Mime-Version: 1.0

Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-3AD5650E

*Moderator edited email addresses*

Link to comment
Share on other sites

Oops !! I just checked the SPF records for aol.com, and they *don't* prohibit other servers from using their name!! The last item in their list of valid senders is "?all", which means (as I understand it) *no policy* on other servers. This is some kind of interim setting, I suppose to allow others to look at aol's soon-to-be-enforced SPF records, and get ready for them to change the last item to "-all", which means "no other servers allowed".

Please try the same test with amazon.com. They have a definite "-all" at the end of their record.

-- Dave

P.S. If you want to check the SPF records for any domain go to http://mxtoolbox.com/spf.aspx

Link to comment
Share on other sites

I just did a simple setting of the return address from within Eudora, and setting up my standard SMTP server but pobox.com seems to have trusted the address enough to place it in their SRS as seen in this header:

Return-Path: <SRS0=1WH5=RB=aol.com=forged[at]bounce2.pobox.com>

Any bounce would have gone to the forged<at>aol.com address which would actually work the way I want it to for sending (I want all replies going where I want them to).

http://dev.spf.pobox.com/emailforwarders.p...e%20sender'

I just did another quick test described below and as you see, the connection was accepted and not dropped or rejected at any point. Let me know if that one got through.

C:\&gt;telnet mx-pa-1.pobox.com 25
220 gold.pobox.com ESMTP Postfix
ehlo underwood.aol.com
250-gold.pobox.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250 8BITMIME
mail from: forged&lt;at&gt;aol.com
250 Ok
rcpt to: dmq&lt;at&gt;pobox.com
250 Ok
data
This is 354 End data with &lt;CR&gt;&lt;LF&gt;.&lt;CR&gt;&lt;LF&gt;
a This is a test using underwood.aol.com ahd mail from forged[at]aol.com

.
250 Ok: queued as 9C17E7115A
quit
221 Bye


Connection to host lost.

As you can see, I started typing my message before the 354 code returned, so I am not sure what the actual data will look like (if it accepted what was typed before the 354 code or not).

BTW, what about my message placed it in your spam box? There are no headers indicating that.

Link to comment
Share on other sites

Let's say I'm a spammer, and I've just registered 1000 new names. Since 1000 other spammers have also registered 1000 names, and all these names are rated "C" by default, they don't have much current value. We can spam all we want, but nobody is listening!! So how am I going to get some of these names up to a "B" rating where they will at least get through the initial block and to the spam filter, where I have a chance of fooling it with my latest "word salad"? I've got to get SpamCop, or some other company that puts out a widely used rating list, I've got to make them think I'm not a spammer. I can't apply under my own name, SpamCop has it in their database, so I find a friend who is willing to lie for me, and protect my identity in spite of a subpoena. I've done this fifteen times now, and I'm running out of friends. Also, SpamCop is getting very good at shutting down my domains, sometimes within hours of starting a spam run. After all that effort of getting a B rating, I can send only 100,000 ads for pen1s pilz, and the domain is slammed down to a "D" rating. D domains are worthless. I can send all the spam I want, and not 1 in 1000 will even accept my HELO. Even when I do get through, those 1000 other spammers are crowding me out. HELP!! I need some way to make this business profitable.

That's what they do now with IP addresses (only they are open proxies or trojanned machines). And, I think that some people are filtering on domain names as well.

I don't see where your system is any different than other filtering techniques now in place. Blocking an IP address or a domain name seems to me to be about equal in effect.

Miss Betsy

Link to comment
Share on other sites

OK, I just sent another test using amazon.com

220 gold.pobox.com ESMTP Postfix
ehlo underwood.amazon.com
250-gold.pobox.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250 8BITMIME
mail from: forged&lt;at&gt;amazon.com
250 Ok
rcpt to: dmq&lt;at&gt;pobox.com
250 Ok
data
354 End data with &lt;CR&gt;&lt;LF&gt;.&lt;CR&gt;&lt;LF&gt;
sent directly by telnetting into pobox.com smtp server using underwood.amazon.co
m for ehlo and forged&lt;at&gt;amazon.com for mail from: field, same as example I posted.

.
250 Ok: queued as 741BA5DFD4
quit
221 Bye

Did you get this one? BTW, I edited your earlier postings for valid email addresses, including my forged one which could be valid.

Link to comment
Share on other sites

I just did a simple setting of the return address from within Eudora, and setting up my standard SMTP server but pobox.com seems to have trusted the address enough to place it in their SRS as seen in this header:

Return-Path: <SRS0=1WH5=RB=aol.com=forged[at]bounce2.pobox.com>

This *is* disturbing. I don't understand why SRS needs to be so complex. Seems to me that a forwarder like pobox.com could convey its authentication of the sender by adding a simple unambiguous header:

Authenticate-SPF: [<IP Address>] <senders-domain> VERIFIED

( or FAILED as the case may be).

Any bounce would have gone to the forged<at>aol.com address which would actually work the way I want it to for sending (I want all replies going where I want them to).

Seems to me that a bounce should go back the same path it came, not to some header address that might be forged. See the section "Responsibility of Forwarders" in http://en.wikipedia.org/wiki/Email_Authentication

I just did another quick test described below and as you see, the connection was accepted and not dropped or rejected at any point.  Let me know if that one got through.

Yes, it came through. This time not to my spam bucket.

BTW, what about my message placed it in your spam box?  There are no headers indicating that.

Here is the report:

spam: ------------------------ Spamnix spam Report -------------------------

spam: Spamnix identified this message as spam. This report shows which

spam: rules matched the message and how many points each rule contributed.

spam:

spam: Content analysis details: (5.4 hits, 5.0 required)

spam: 5.4 BAYES_99 BODY: Bayesian spam probability is 99 to 100%

spam: [score: 100.0%; H*p:D*com:99 H*r:HELO:99]

spam: [H*c:charset:99 N:H*r:N.NN.NN:99 H*c:plain:99]

spam: [H*c:us-ascii:99 N:H*r:NNN.NNN.NN:99]

spam: [N:H*r:NN.NNN.NN:99 H*r:8.12.11:99 Virus:99]

spam: [N:H*x:N.N:99 H*x:Windows:99 Release:99]

spam: [N:H*m:NNNNNNNNNNNNNN:2 N:H*r:sk:cpe-NN-:98]

spam: [H*x:Version:98 H*F:D*aol.com:98 HTo:U*dmq:97]

spam: [Database:96 H*c:flowed:96 H*x:QUALCOMM:96]

spam: [Anti-Virus:96 H*x:Eudora:96 H*c:format:96]

spam: [N:N.N.NNN:96 N:HMime-Version:N.N:94]

spam: [HMime-Version:1.0:94 test:6 virus:92 H*m:com:12]

spam: [checked:86]

spam:

spam: spam level: *****

spam: --------------------- End of Spamnix spam Report ---------------------

Looks like it saw some inconsistency in the headers, but I can't really follow this.

Try the same test, but forging 'amazon.com'. Unlike aol.com, Amazon's SPF records indicate that only Amazon's servers are authorized senders for amazon.com. It will be interesting to see how pobox.com handles the forwarding.

-- Dave

Link to comment
Share on other sites

Seems to me that a bounce should go back the same path it came, not to some header address that might be forged. See the section "Responsibility of Forwarders" in http://en.wikipedia.org/wiki/Email_Authentication

A bounce should go back along the same path, a reply should be configurable. Except too many processes use the Reply-to: address to send their bounces, and this is where many of the problems occur with the accept-and-bounce rather than the reject-during-SMTP. It appears, however, pobox.com's SRS is using the reply-to address as well. My sending through charter's SMTP server was authenticated (SMTP after POP), so they could track my message back to me for that message.

The simple telnet to pobox.com servers test would need to assume my IP had not changed, which because it is a DHCP served address, is not a guarantee.

This *is* disturbing. I don't understand why SRS needs to be so complex.

SRS and SPF are different, but related. SRS is needed because for SPF, the forwarders need to change the envelope sender, so any reject during the SMTP transaction will come back to them and they need a way to return it to the sender they got it from. Multiple forwarders (not uncommon, I have 3 setup at the current time and could easily go to 5 if I wanted to) would need to repeat the process, breaking down the SRS Return-Path: field of what they added.

Try the same test, but forging 'amazon.com'. Unlike aol.com, Amazon's SPF records indicate that only Amazon's servers are authorized senders for amazon.com. It will be interesting to see how pobox.com handles the forwarding.

I did the simple telnet test using the amazon.com information as posted just above your last post. I agree that my sending from within Eudora is not really testing SPF at all because I am only modifying the Reply-to and From fields, perhaps not the Envelope from (which I can not see). Charter does allow me to relay through them if I POP my mailbox shortly before doing it, otherwise my initial connection is not accepted. If you did not receive my test directly to the pobox.com servers, I will try another using the charter.net servers.

Link to comment
Share on other sites

Domain lists work *only* if the domain name is authenticated.  That is why they have not been possible until now.

Also, the receiver must use the *authenticated* name in matching his white/black lists, not some other name that the spammer might have forged.

24462[/snapback]

Actually I have been a long ignored :( supporter of using a whitelist

odd shot fired without response

Not sure what the reason for at least SpamCop e-mail to implement it?

Probably does blacklist guru's out of a job

Link to comment
Share on other sites

There are a couple of inherit problem with whitelists...

* Everyone must sign up to join them.

None can commuincate until all parties of a communication channel are subscribed.

* They're not bullet proof

What happens when a someone makes the effort to disrupt the service. 1000 spammers who acqurie 1000 valid accounts can lodge a lot of complaints.

What about a conspiracy? if someone doesn't like what someone else does... Who gets blocked, who doesn't?

* administration and judication would be a nightmare

Someone has which reports are valid or not. Otherwise ppl will be unjustly removed

If it was as simple as we wish, it would have been done.

In an ideal world, no problem it could work. But then, in an ideal world, would it be needed in the first place?

Link to comment
Share on other sites

There are a couple of inherit problem with whitelists... 

* Everyone must sign up to join them.

None can commuincate until all parties of a communication channel are subscribed.

24552[/snapback]

To use Bonded Sender whitelist is free and as easy to use as a Blacklist

* They're not bullet proof

What happens when a someone makes the effort to disrupt the service.  1000 spammers who acqurie 1000 valid accounts can lodge a lot of complaints.

What about a conspiracy?  if someone doesn't like what someone else does...  Who gets blocked, who doesn't?

Bonded sender to be listed are not free and require a Bond each SINGLE spam Complaint costs that user US$20

* administration and judication would be a nightmare

Someone has which reports are valid or not.  Otherwise ppl will be unjustly removed

Bonded Server is free for one to use as a whitelist to subscribe it has to be paid for

If it was as simple as we wish, it would have been done.

In an ideal world, no problem it could work.  But then, in an ideal world, would it be needed in the first place?

It is needed now will people use it is another matter. That letter from your Bank or Solicitor WOULD arrive if Bonded sender was used

Check out BondedSenders Riot act to see

Link to comment
Share on other sites

A bounce should go back along the same path, a reply should be configurable.  Except too many processes use the Reply-to: address to send their bounces, and this is where many of the problems occur with the accept-and-bounce rather than the reject-during-SMTP. 

With authentication, it should not be necessary to bounce during the same SMTP session. As long as the authenticated address is saved, a bounce can go to that address sometime later.

The simple telnet to pobox.com servers test would need to assume my IP had not changed, which because it is a DHCP served address, is not a guarantee.

Regardless of whether you use telnet or DHCP, or any other protocol, when you establish an SMTP session, the receiver should authenticate your domain and make sure that the IP address on the incoming packets is an authorized address for that domain. Seems to me the domain to be authenticated should be whatever is used in the HELO command that requests the SMTP session. All others should be irrelevant.

SRS and SPF are different, but related.  SRS is needed because for SPF, the forwarders need to change the envelope sender, so any reject during the SMTP transaction will come back to them and they need a way to return it to the sender they got it from. 

I still think this could be done more clearly by having the forwarder just prepend a header:

Authenticate: SPF1 [<IP Address>] <senders-domain> PASS

Then when a bounce comes back, the forwarder just needs to peel off the top Authenticate line and use that to forward the bounce. I understand the forwarder cannot trust what comes back from the receiver, but that could be verified by just having the forwarder store a hash code for every forwarded message. If a fresh hash on a bounced message doesn't match anything forwarded in the last 24 hours, don't forward the bounce.

http://en.wikipedia.org/wiki/Email_Authentication

Multiple forwarders (not uncommon, I have 3 setup at the current time and could easily go to 5 if I wanted to) would need to repeat the process, breaking down the SRS Return-Path: field of what they added.

I don't understand the need for multiple forwarders in series. I have two, but they both forward to my current ISP. Nevertheless, authentication should work in your situation also.

As I understand it, SRS saves only the first sender's domain, and not that of any previous forwarders. This seems terribly insecure to me. There needs to be an authenticated domain for each forwarder.

I did the simple telnet test using the amazon.com information as posted just above your last post.  I agree that my sending from within Eudora is not really testing SPF at all because I am only modifying the Reply-to and From fields, perhaps not the Envelope from (which I can not see).  Charter does allow me to relay through them if I POP my mailbox shortly before doing it, otherwise my initial connection is not accepted.  If you did not receive my test directly to the pobox.com servers, I will try another using the charter.net servers.

Your test message with the forged amazon.com got through:

Return-Path: <SRS0=ekIn=RC=amazon.com=forged at bounce2.pobox.com>

Seems like SRS is broken ( at least at pobox.com )!! That surprises me, because these are the folks pushing SPF/SRS. I'll ask them about this incident, and post the result here later.

Your telnet test looks good. That should allow you to fake anything, including the SMTP "envelope" info.

-- Dave

Link to comment
Share on other sites

I don't see where your system is any different than other filtering techniques now in place.  Blocking an IP address or a domain name seems to me to be about equal in effect.

The key difference is that with the current system, list providers like SpamCop have to react quickly every time a spammer gets a new IP address. Instead, the burden should be on domain owners, who will have to prove to SpamCop that their domain is *not* a source of spam. Only those domains that are serious about operating public mail servers will bother to get rated.

-- Dave

Link to comment
Share on other sites

The key difference is that with the current system, list providers like SpamCop have to react quickly every time a spammer gets a new IP address. Instead, the burden should be on domain owners, who will have to prove to SpamCop that their domain is *not* a source of spam.

First of all, IIUC, there is no way to determine that a domain owner does not allow spam to be sent easily (except through the current blocklists). And two, there are, at least, two outfits that are trying to do that - Bonded Sender which fines members if spam is reported and Habeus who sues them for copyright infringement if a spammer uses the Habeus header. I don't know what they do if someone signs up and then spams.

And that is another problem, most whitehat ISPs are rarely listed and have no interest in either blacklists or whitelists. As well as mailing list managers who rarely have a problem or have learned how to deal with it (there was one a while back who couldn't understand how people on his PAID list could report a mailing).

SpamCop wouldn't be interested because, IIUC petzl's posts, Bonded Sender is part of Ironport who owns spamcop. Also, because part of the mission is to stop a spam run. For whitehats, that happens as soon as they get the spamcop report. The primary purpose is not to blacklist any IP address permanently.

Some other blocklist might be more interested.

Miss Betsy

Link to comment
Share on other sites

SpamCop wouldn't be interested because, IIUC petzl's posts, Bonded Sender is part of Ironport who owns spamcop.  Also, because part of the mission is to stop a spam run.  For whitehats, that happens as soon as they get the spamcop report.  The primary purpose is not to blacklist any IP address permanently.

Some other blocklist might be more interested.

Miss Betsy

24564[/snapback]

I see BondedSender and SpamCop as ideal and complementery to each other and if one of BondedSenders customers does start spamming it's

(1) easily traced by SpamCop

&

(2) easily and immediatly blocked by SpamCop

Remember for properly configured e-mail servers SpamCop easily blocks the SOURCE without blocking the server it went through

Once dedicated and Whitelisted e-mail servers become the norm, it will mean only whitelisted e-mail servers will be accepted by well everyone and children starting on internet will only associate spam with spam (that exellent meal in a tin)

Link to comment
Share on other sites

I still think this could be done more clearly by having the forwarder just prepend a header:

Authenticate: SPF1 [<IP Address>] <senders-domain> PASS

Then when a bounce comes back, the forwarder just needs to peel off the top Authenticate line and use that to forward the bounce.

Your authenticate: header does not contain an email address to send the message back to. How is it ever going to get back to the sender? IP Addresses change, sometimes very often, and do not necessarily equate to any specific user. Also, many ISP's provide several email addresses with each account, so even if you got the correct account, how are you going to determine the sending address?

As I understand it, SRS saves only the first sender's domain, and not that of any previous forwarders. This seems terribly insecure to me. There needs to be an authenticated domain for each forwarder.

That is NOT what I understand. In fact, that is one of the comlaints against SRS, that the line length can quickly become longer that the allowable lenght to be transmitted.

I don't understand the need for multiple forwarders in series. I have two, but they both forward to my current ISP. Nevertheless, authentication should work in your situation also.

I don't trust my ISP with my secure address because that is where a large amount of spam comes from (for an account I have NEVER used) that I wish to report. And there are other similiar situations. These all forward to my poboxes.com address which then forwards to my spamcop.net address. This will also make it easy to relieve myself of lots of spam when I drop the poboxes.com address (support issues) in May and start using my spamcop.net address directly. Spamcop also allows my to use plussed addressing so I can still know where the address came from.

Link to comment
Share on other sites

Your authenticate: header does not contain an email address to send the message back to.  How is it ever going to get back to the sender?  IP Addresses change, sometimes very often, and do not necessarily equate to any specific user.  Also, many ISP's provide several email addresses with each account, so even if you got the correct account, how are you going to determine the sending address?

Authenticate: SPF1 [<IP Address>] <senders-domain> PASS

Let's make a distinction between the author and the sender. The Authenticate: header contains only informtion that has been authenticated. There is no way to authenticate the author's name, as that is known only within the sender's domain. The bounce should go to postmaster[at]<senders-domain> The postmaster can then decide whether to use the information in the From: header to forward the bounce back to the author. Most bounces will be for problems the domain owner should take care of ( authentication failure, possible spam, etc.)

It looks to me like the ball has been dropped on this one last vital piece to make SPF a fully functional system that can be used even with forwarders. DomainKeys avoids the problem by going "end-to-end" with a digital signature, but I don't know if computational costs are an issue.

We really do need a standard that will allow forwarders to participate in an IP-authenticated transfer. The standard should allow for different authentication protocols (SPF1, SPF2, SenderID, etc.). The captured IP address should be displayed, even if it is only a temporary address. Then we should show the domain name, determined by whatever method the protocol calls for. Finally, we need the result of the authentication on that name, using whatever keywords are specified in the protocol.

After these four standard parts can come any number of free-form parameters ( hash code, time stamp, etc.) These need not be standardized, because they serve only as a "cookie" for the forwarder's own processes.

-- Dave

Link to comment
Share on other sites

The bounce should go to postmaster[at]<senders-domain> The postmaster can then decide whether to use the information in the From: header to forward the bounce back to the author. Most bounces will be for problems the domain owner should take care of ( authentication failure, possible spam, etc.)

Then you have made the bounces useless for about the only reason they are at all useful, when someone has fat fingered an address. The postmaster address will be so overwhelmed that those messages will not get noticed/dealt with. Postmaster addresses will become bit buckets with the message simply discarded.

Link to comment
Share on other sites

Then you have made the bounces useless for about the only reason they are at all useful, when someone has fat fingered an address.  The postmaster address will be so overwhelmed that those messages will not get noticed/dealt with.  Postmaster addresses will become bit buckets with the message simply discarded.

24586[/snapback]

If a postmaster ignores a flood of messages about authentication failure, he won't be able to send mail to *any* receiver that does authentication. That leaves the spam category. If the message is rejected because it is from a known spamming domain, you probably don't want to reply anyway. They will know very well why their messages are being ignored.

For messages that get past authentication, and past the "pure spam domain" blocklist, then we have a situation much like today, but with most of the worst spam already discarded. The options include everything we do now, (report to SpamCop, etc.) but with the additional information on domain rating, and with the option to reply to the postmaster at the actual domain that sent the message.

Nothing is taken away. We just have some very useful new options.

-- Dave

Link to comment
Share on other sites

Seems like SRS is broken ( at least at pobox.com )!!  That surprises me, because these are the folks pushing SPF/SRS.  I'll ask them about this incident, and post the result here later.

24562[/snapback]

OK, we now have what I think is a correctly set up forwarder, bmsi.com. Here is a telnet session trying to fake 'amazon.com' in a mail to 'dmq at bmsi.com'.

220 mail.bmsi.com ESMTP Sendmail 8.13.1/8.13.1; Tue, 22 Feb 2005 00:24:02 -0500

HELO smtp.egreinsch.com

250 mail.bmsi.com Hello egrrtr [141.156.111.136], pleased to meet you

MAIL FROM: <forged at amazon.com>

550 5.7.1 <forged at amazon.com>... SPF fail: see http://spf.pobox.com/why.html

And here is the top header on a correctly addressed email from gain.com to 'dmq at bmsi.com':

Return-Path: <SRS1=UPSe=bmsi.com==6Vba5=RE=gain.com=dmq at bounce2.pobox.com>

Notice I used two forwarders: bmsi.com, then pobox.com

Looks like SRS works if it is set up correctly. The problem is social engineering. The warring camps are not talking to each other. To address this problem, I started a discussion on the SPF mailing list v2.listbox.com/200502/index.html]http://archives.listbox.com/spf-discuss[at]v2...0502/index.html "Email Forwarder's Protocol (EFP)".

-- Dave

Link to comment
Share on other sites

I just came across an wonderful piece of art and explanation on how things will work a year from now, assuming email authentication is widely adopted.

http://spf.pobox.com/aspen.html

Looks like SpamCop might be in a good position to participate - lots of subscribers worldwide, an up-and-running real-time feedback system, a good reputation in the business.

-- Dave

Link to comment
Share on other sites

And with SPF / SRS already under discussion under your existing Topic .. why is this needed in it's own "new" Topic? Never mind the "if it's accepted" clause putting the whole thing in limbo anyway ... again, failing to grasp the need for yet another discussion on something you've already got underway ...

Link to comment
Share on other sites

I also think this should be moved into the other SPF thread.

Sorry for the confusion. It looked like we were done with the discussion on SPF and authentication technology in general.

P.S.  I have gotten actual spam from customers of about half of the domains listed as "good".

I think those domains were just pulled out of a hat, for illustration purposes, not to make any point that they were better. Are you seeing any differences, on average, between good domains and bad, or is the spam pretty much coming evenly from everywhere? Does AOL, for example, have lower than average? They claim to have eliminated their outgoing spam. "We do not send it any more." -- AOL postmaster Carl Hutzler http://www.circleid.com/article/917_0_1_0_C/

It would be interesting to see some actual numbers of spam reports from AOL compared to other well-known domains.

Link to comment
Share on other sites

Sorry for the confusion.  It looked like we were done with the discussion on SPF and authentication technology in general.

Hardly "done" if you're going to continue ....???? As with the last "new Topic" you tried to start, this one has also been merged into this existing collection of commentary.

I think those domains were just pulled out of a hat, for illustration purposes, not to make any point that they were better.  Are you seeing any differences, on average, between good domains and bad, or is the spam pretty much coming evenly from everywhere?

"good domain" "bad domain" "reputable domain" ...???? Personally, I still don't get your definition .. as how is one supposed to look at a Domain name and make that call?

Does AOL, for example, have lower than average?  They claim to have eliminated their outgoing spam. "We do not send it any more." -- AOL postmaster Carl Hutzler  http://www.circleid.com/article/917_0_1_0_C/

It would be interesting to see some actual numbers of spam reports from AOL compared to other well-known domains.

Even if you had a number, what would it mean? To compare AOL's worldwide system and millions of users with a local ISP that provides for 2,000 people and hosts 100 web-sites ...??? what would that do for you? In your seemingly never-ending run-on about pointing at issues and tossing out the "simple" solutions but not wanting to waste tme doing research, have you ever looked at http://www.spamcop.net/w3m?action=map ???

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...