Hi all,
Would I be able to get an AT&T mail administrator to contact me off-list? We've recently moved our mailservers to a new IP address range, and the standard CGI forms haven't produced any progress for us in over a week now. Unfortunately this affects dozens of hosted clients...
The CGI form at http://wn.att.net/cgi-bin/block_admin.cgi has also got a dead link at the bottom, which shakes my confidence in its level of maintenance a little.
Thanks in advance,
Brad Laue escreveu:
Hi all,
Would I be able to get an AT&T mail administrator to contact me off-list? We've recently moved our mailservers to a new IP address range, and the standard CGI forms haven't produced any progress for us in over a week now. Unfortunately this affects dozens of hosted clients...
The CGI form at http://wn.att.net/cgi-bin/block_admin.cgi has also got a dead link at the bottom, which shakes my confidence in its level of maintenance a little.
Thanks in advance,
Any success?
I have been trying to mail @bellsouth for a while now, and I am stuckd
into this RBL. Filling the CGI form or mailing abuse@, postmaster, or
this address:
http://worldnet.att.net/global-images/general-info/abuse_mail.gif
Never helped. My IP address, which has very good reputation on mail
delivery on many other public RBLs, btw, is still blocked reason-less.
Patrick Tracanelli wrote:
Brad Laue escreveu:
Hi all,
Would I be able to get an AT&T mail administrator to contact me off-list? We've recently moved our mailservers to a new IP address range, and the standard CGI forms haven't produced any progress for us in over a week now. Unfortunately this affects dozens of hosted clients...
The CGI form at http://wn.att.net/cgi-bin/block_admin.cgi has also got a dead link at the bottom, which shakes my confidence in its level of maintenance a little.
Thanks in advance,
Any success?I have been trying to mail @bellsouth for a while now, and I am stuckd
into this RBL. Filling the CGI form or mailing abuse@, postmaster, or
this address:http://worldnet.att.net/global-images/general-info/abuse_mail.gif
Never helped. My IP address, which has very good reputation on mail
delivery on many other public RBLs, btw, is still blocked reason-less.
No luck as yet. I've sent an e-mail to postmaster@ and abuse_rbl@, hopefully I'll receive a reply from these.
Exclusionary blocklists are a great idea if they're constantly maintained. I'm unclear as to why mail administrators don't work more proactively with things like SenderID and SPF, as these seem to be far more maintainable in the long-run than an ever-growing list of IP address ranges.
There's a difference between maintainable and usable. Yes, letting the remote
end maintain their SenderID and SPF is more scalable, and both do at least a
plausible job of answering "Is this mail claiming to be from foobar.com really
from foobar.com?". However, there's like 140M+ .coms now, and neither of them
actually tell you what you really want to know, which is "do I want e-mail from
foobar.com or not?". Especially when the spammer is often in cahoots with the
DNS admins...
On the other hand, I can, by looking at my logs, develop a fairly good sense of
"do I have any real non-spam traffic from that address range?". Yes, it's more
work, but it's also more likely to actually answer the question that I wanted
answered.
maintained. I'm unclear as to why mail administrators don't work more
proactively with things like SenderID and SPF, as these seem to be far
more maintainable in the long-run than an ever-growing list of IP
address ranges.There's a difference between maintainable and usable. Yes, letting the remote
end maintain their SenderID and SPF is more scalable, and both do at least a
plausible job of answering "Is this mail claiming to be from foobar.com really
from foobar.com?". However, there's like 140M+ .coms now, and neither of them
actually tell you what you really want to know, which is "do I want e-mail from
foobar.com or not?". Especially when the spammer is often in cahoots with the
DNS admins...
identify framework with trust anchors and reputation management are not
things that spf or pra actually solve. spammers can publish spf and
senderid records and in fact arguably have more incentive to do so if it
can be demonstrated that your mail is more likely to be accepted on the
basis of their existence.
True, but wouldn't a blacklist of SPF records for known spam issuing domains be a more maintainable list than an IP block whitelist?
(I'm no doubt missing something very obvious with this question)
Brad
Yes, I think you are 
First of all, domains are easier to throw away than
IP Addresses, IP Lookups are more efficient than DNS SPF records, and SPF is
not really meant to address Spam problems, although it can address some
forgeries.
SPF works best to identify forgeries of large well known domains, but I think
you do not really understand what SPF records do, or how they work. Don't
worry, many email operators don't either, and simply put in an SPF record that
says that every IP can send email for that domain 
And think how large the theoretical database size would be for every domain,
compared to the limited size of the IPv4 space.. But this is better taken off
list you want to discuss SPF's usage in combatting spam.
140M+ .com where a malicious DNS server in East Podunk can be authoritative for
a domain actually in Bratslavia and domains are cheap and throw-away.
16M /24's, where you (mostly(*)) need to be able to actually route the packets,
so if you have a /24 in Bratslavia, you need something resembling a router
in Bratslavia as well, and somebody willing to light up the other end of
the cable, and you need a way to make BGP announcements (legal or otherwise
to be able to exploit it.
Choose wisely which you'd rather use for defense.
(*) Mostly - though the BGP hack demonstrated at last year's DefCon
did qualify as an Epic Win for kewl presentations.
Ah, very true. Still really hoping to get in touch with someone from AT&T.
Thanks for the info.
Brad Laue wrote:
Ah, very true. Still really hoping to get in touch with someone from AT&T.
Good luck. You might be a better response from posting a video complaint on Youtube. "AT&T Breaks Guitars" perhaps.
Justin
Because SenderID and SPF have no anti-spam value, and almost no
anti-forgery value. Not that this stops a *lot* of people who've drunk
the kool-aid from trying to use them anyway, but blacklists are still --
by a huge margin -- the most effective anti-abuse tool available.
That said, blacklists (like all such resources) should be maintained,
and those using them should provide working contact methods that
enable resolution of the inevitable mistakes. The problem thus isn't
so much the choice of/use of blacklist(s), it's incompetent mail system
administration.
---Rsk
OK, I'll bite--How exactly do you go about forging email from my domain name if the host receiving it is checking SPF?
Chris
It only stops forgery if the SPF record has a -all in it (as hubris.net does).
However, a lot of domains (mine included) have a ~all instead.
(And before anybody asks, yes ~all is what we want, and no you can't ask us
to try -all instead, unless we're allowed to send you all the helpdesk calls
about misconfigured migratory laptops"..
It only stops forgery if the SPF record has a -all in it (as hubris.net does).
However, a lot of domains (mine included) have a ~all instead.
I guess I've never really seen the point of publishing a SPF record if it ends in ~all. What are people supposed to do with that info?
Spamassassin assigns it a score of 0.6 but that is low enough it really doesn't have much since it doesn't assign any negative points for SPF_PASS.
(And before anybody asks, yes ~all is what we want, and no you can't ask us
to try -all instead, unless we're allowed to send you all the helpdesk calls
about misconfigured migratory laptops"..
I certainly understand that you may not be able to lock down your domain. We don't even try for customers for instance. However, if you can't, I guess I don't really see what good publishing a SPF record is if you tell people not to enforce it.
Chris
Dont let me stop you playing russian roulette with your users' email.
I guess I've never really seen the point of publishing a SPF record if
it ends in ~all. What are people supposed to do with that info?
Get your mail delivered to Hotmail, the last significant outpost of
SPF/Sender-ID. Other than that, I agree it's useless.
I also agree that any domain with live users (as opposed to mail
cannons sending ads or transaction confirmations) is likely to
experience pain with -all from all the overenthusiastic little MTAs
whose managers imagine that "stopping forgery" will lessen their spam
load rather than losing mail from roaming users.
R's,
John
John Levine wrote:
I guess I've never really seen the point of publishing a SPF record if
it ends in ~all. What are people supposed to do with that info?Get your mail delivered to Hotmail, the last significant outpost of
SPF/Sender-ID. Other than that, I agree it's useless.I also agree that any domain with live users (as opposed to mail
cannons sending ads or transaction confirmations) is likely to
experience pain with -all from all the overenthusiastic little MTAs
whose managers imagine that "stopping forgery" will lessen their spam
load rather than losing mail from roaming users.
In all fairness, the roaming users problem isn't a problem when one uses smtp auth and a constant submission point.
~Seth
Again I guess I don't understand. How are these MTA managers being "overenthusiastic"?
Publishing a SPF (with -all) is essentially me requesting that they reject any mail from my domain not coming from one of the approved hosts. I'm the one making the decision to ask them to bounce such mail. Seems to me they are only being responsible in actually enforcing a policy that I set for the domain.
Chris
While I'll remain neutral about the specifics of SPF (and all the other
solutions), the legacy problem comes up trying to secure any thing. If it (and I deliberately leave "it" undefined) had never worked, no one would complain. Of course, there will always be someone who goes too one extreme or the other extreme. People were dropping heavily spoofed domains before SPF anyway.
At what point do we consider legacy support not worth it? It took 10+ years, but now almost no SMTP servers allow open relay by default. Will it take another 10+ years to stop supporting misconfigured migratory laptops by default?
Chris,
In addition to pushing the spam assassin score a little more towards
tagging it as a spam, I use SPF to suppress backscatter from my
confirmation system. When I receive a message whose spam probability
is ambiguous (spamassassin score between 3 and 8), I generate a
confirmation request to the sender. This allows the sender to put the
message in front of me anyway if it turns out to have been a false
positive, as it occasionally does.
If you publish SPF records (even with ~all) and the source doesn't
match, I won't generate that request. You've given me sufficient
forward knowledge to detect the forgery so that I can silently drop
the spam and still comply with RFC 2821's "must."
Regards,
Bill Herrin
