So by "blacklist/whitelist domains instead of IPs" you mean via a or mx record mechanisms for/of the domain which the SPF1 record is published, and not some foreign domain such as Yahoo.com, unless you were refering to Yahoo's SPF record, which BTW, they don't have:(
And hopefully more SPF1 records will end with -all
For some lame reason, the SPF Wizard generates records ending with ~all with no explanation.
Ah, thanks. BTW, by "message header [32]" (footnote referring to RFC 2822) is this refering to the cosmetic MIME/message From/sender email address that must not be changed/affected (whereas the SMTP/Envelope sender MUST be changed)?
(I'm merely commenting to GP; the university isn't mine.) I wonder why sender verification/callout is so popular. How far do most MTA's go in their test SMTP conversation? Do they drop after receiving a 250 to their HELO or their MAIL FROM or their RCPT TO? I also wonder if there are legit reasons why the SMTP/Envelope sender *would* be spoofed. If that email address domain doesn't have SPF1 records, then wouldn't that be sufficient knowledge to the world that they might allow their domain to be spoofed/forged by 3rd-party mailers and listserv's?
Why would VZ send a bounce message for each message that the listserv sent over the several month span (as opposed to an in-session protocol error indicating the VZ mailbox alias didn't exist or the mailbox was full)?
However, SPF would give you the ability to blacklist/whitelist domains instead of IPs - domains change less often. You could whitelist yahoo.com and not have to update the database every time yahoo adds a server to their cluster.
I don't follow; can SPF really whitelist domains? Isn't the point of the record that domain names can't be trusted to be not spoofed/forged? I know SFP1 has several mechanisms such as the MX and A records, but I'm pretty sure those are resolved to their IP address so the SPF-checking application is comparing apples to apples, no?
Somebody like spamhous could run a DNS-based database that determines whether a domain is spammy, non-spammy, or unknown based on complaint data (much as they currently do for IPs now).
Such as IronPort's SenderBase.com Also, for domains contained within the message body, there are SURBL.org and URIBL.com
Individuals could obviously make up their own minds regarding unknown domains, but if a domain has a reputation for not sending spam, why block it just because they don't own a T1?
Yeah, I wouldn't block merely if the IP is dynamic, but I would consider scoring it spammy as long as that score alone doesn't reach the spam block or spam redirect thresholds.
I submitted a link to your post to the SPAM-L mailing list and quickly received a reply that Verizon fixed this very issue. I asked for details but was told that it was not public info and without consent the person can't comment to me.
Regarding the tech's "Sender cannot be verified," what kind of test did your university's listserver fail...SPF validation, Greylisting, rDNS, FCrDNS, and based on the message's SMTP/Envelope sender email address domain, the listerserver's IP address, its HELO name, or?
SPF1 checks are for either adding to the block score as a probable spoof/forgery if the record ends with ~all (softfail) or else for dropping during the SMTP conversation with appropriate protocol error if the record ends with the -all (hardfail) mechanism. Conservative estimates of spammy domains with valid SPF1 records are at least 15%. I personally would never accept based solely on SFP1 pass, but I would do so if the message purported to be from one of the domains in a personal list of known-goods (non-spammy domains).
Wasn't there a subsequent split between VeriSign and Network Solutions? Who mantains the master.com registrar database now? Did it go from Internic to VeriSign/NetSol to now just NetSol.com?
Anidroccg to crad cniyrrag lcitsiugnis planoissefors at an uemannd
utisreviny in Bsitirh Cibmuloa, and crartnoy to the duoibus cmials of
the ueticnd rcraeseh, a slpmie, macinahcel ioisrevnn of ianretnl
cretcarahs araepps sneiciffut to csufnoe the eadyrevy oekoolnr.
Translation:
According to card carrying linguistics professionals at an unnamed
university in British Columbia, and contrary to the dubious claims of
the uncited research, a simple, mechanical inversion of internal
characters appears sufficient to confuse the everyday onlooker.
Slashdot Mirror
Yes; new envelope and same message inside. Same-envelope forwarding is oft chastized/larted on the SPAM-L list of most-humble mail admins :)
So by "blacklist/whitelist domains instead of IPs" you mean via a or mx record mechanisms for/of the domain which the SPF1 record is published, and not some foreign domain such as Yahoo.com, unless you were refering to Yahoo's SPF record, which BTW, they don't have :(
And hopefully more SPF1 records will end with -all
For some lame reason, the SPF Wizard generates records ending with ~all with no explanation.
Ah, thanks. BTW, by "message header [32]" (footnote referring to RFC 2822) is this refering to the cosmetic MIME/message From/sender email address that must not be changed/affected (whereas the SMTP/Envelope sender MUST be changed)?
(I'm merely commenting to GP; the university isn't mine.) I wonder why sender verification/callout is so popular. How far do most MTA's go in their test SMTP conversation? Do they drop after receiving a 250 to their HELO or their MAIL FROM or their RCPT TO? I also wonder if there are legit reasons why the SMTP/Envelope sender *would* be spoofed. If that email address domain doesn't have SPF1 records, then wouldn't that be sufficient knowledge to the world that they might allow their domain to be spoofed/forged by 3rd-party mailers and listserv's?
Why would VZ send a bounce message for each message that the listserv sent over the several month span (as opposed to an in-session protocol error indicating the VZ mailbox alias didn't exist or the mailbox was full)?
However, SPF would give you the ability to blacklist/whitelist domains instead of IPs - domains change less often. You could whitelist yahoo.com and not have to update the database every time yahoo adds a server to their cluster.
I don't follow; can SPF really whitelist domains? Isn't the point of the record that domain names can't be trusted to be not spoofed/forged? I know SFP1 has several mechanisms such as the MX and A records, but I'm pretty sure those are resolved to their IP address so the SPF-checking application is comparing apples to apples, no?
http://openspf.org/mechanisms.html
Somebody like spamhous could run a DNS-based database that determines whether a domain is spammy, non-spammy, or unknown based on complaint data (much as they currently do for IPs now).
Such as IronPort's SenderBase.com Also, for domains contained within the message body, there are SURBL.org and URIBL.com
Individuals could obviously make up their own minds regarding unknown domains, but if a domain has a reputation for not sending spam, why block it just because they don't own a T1?
Yeah, I wouldn't block merely if the IP is dynamic, but I would consider scoring it spammy as long as that score alone doesn't reach the spam block or spam redirect thresholds.
I submitted a link to your post to the SPAM-L mailing list and quickly received a reply that Verizon fixed this very issue. I asked for details but was told that it was not public info and without consent the person can't comment to me.
Regarding the tech's "Sender cannot be verified," what kind of test did your university's listserver fail...SPF validation, Greylisting, rDNS, FCrDNS, and based on the message's SMTP/Envelope sender email address domain, the listerserver's IP address, its HELO name, or?
SPF1 checks are for either adding to the block score as a probable spoof/forgery if the record ends with ~all (softfail) or else for dropping during the SMTP conversation with appropriate protocol error if the record ends with the -all (hardfail) mechanism. Conservative estimates of spammy domains with valid SPF1 records are at least 15%. I personally would never accept based solely on SFP1 pass, but I would do so if the message purported to be from one of the domains in a personal list of known-goods (non-spammy domains).
Does this mean we all have to start tagging?
That's great...brilliant idea...[/sarcasm]
Round 1, Slashdot Diggs For Dirt
Round 2, Dig Slashes Back
Round 3, Slash Diggs Grave
Round 4, Both Sides Look Dirty
Round 5, Audience Can't Tell SlashDigg Apart
Good that not everyone gets it, as I intend for double entendres/puns to not be obvious/trite/stereotypical.
Cute but not too bright. Almost every keyword of mine in this thread is from The Matrix. The Oracle already knows Neo.
Yeah, sure you are. That's what they all say.
Yeah, you missed it, but maybe there will be a glitch in the Matrix so you watch for it again.
Besides, I consider Ubuntu to be "Under Construction" too.
You need a phone line connection.
Oracle, I've searched the Linux Matrix and I still believe Neo is the one.
Not meant to reduce spam but to verify sender...SPF/Sender-ID/DomainKeys anyone?
No, the arc of the rainbow of Oz.
In other words: No, Oz arc.
And comparing with OWL (Openwall Linux) as well. http://www.openwall.com/Owl/
http://www.thinkgeek.com/tshirts/generic/3813/
Wasn't there a subsequent split between VeriSign and Network Solutions? Who mantains the master .com registrar database now? Did it go from Internic to VeriSign/NetSol to now just NetSol.com?
This is from the Slashback along time ago:
Anidroccg to crad cniyrrag lcitsiugnis planoissefors at an uemannd
utisreviny in Bsitirh Cibmuloa, and crartnoy to the duoibus cmials of
the ueticnd rcraeseh, a slpmie, macinahcel ioisrevnn of ianretnl
cretcarahs araepps sneiciffut to csufnoe the eadyrevy oekoolnr.
Translation:
According to card carrying linguistics professionals at an unnamed
university in British Columbia, and contrary to the dubious claims of
the uncited research, a simple, mechanical inversion of internal
characters appears sufficient to confuse the everyday onlooker.
Don't mean to be a Troll, but is there clear communication at a GnomeMeeting?
Does the eBook version have color images? http://www.apress.com/book/bookDisplay.html?bID=10 052