Chad Leigh -- Shire.Net LLC wrote:
On Mar 13, 2007, at 6:00 PM, Christopher Sean Hilton wrote:
On Mon, 2007-03-12 at 12:00 -0400, Marcelo Maraboli wrote:
I agree..... callbacks are not enough, you can reach a
false conclusion, that´s why I use SPF along with callbacks...
on the same message, my MX concludes:
"you are sending email "from [EMAIL PROTECTED]", but shire.net
says YOUR IP address is not allowed to send email on behalf
of that domain, therefore YOU ARE FAKE/FORGED" ..---> reject
regards,
I'm not sure what you mean by callbacks but if that involves talking to
mx.example.com and trying to figure out if [EMAIL PROTECTED] is
a valid address go ahead. I would consider a mailserver that answers
that question a security risk as it is freely giving away information
about your domain without notifying you. For a long time my mx servers
would answer any such question in the affirmative regardless of whether
or not the mail account existed.
Address verification callbacks take various forms, but the way exim does
it by default is to attempt to start a DSN delivery to the address and
if the RCPT TO is accepted it is affirmative. It is not usually use
VRFY. Most address verification is done by attempting to start some
sort of delivery to the address.
I'm assuming that DSN is Delivery Service Notification or return
receipt. If it is or if it somehow relies on the ability to deliver a
message via smtp to [EMAIL PROTECTED] then I don't see how it prevents spam.
As the above poster says SPF is the way to go. SPF gives the receiving
MTA a mechanism to vet inbound mail. For any combination of <mail
server> and <from address/from domain> there are three possible results
from an SPF check: The server is allowed to send mail for the domain;
The server is not allowed to send mail for the domain; And I cannot tell
because the owner of the domain hasn't published an SPF record. The only
problem with SPF is that it's not more widely implemented so the third
response is sadly more common than the first two.
I believe it also breaks when you have forwards.
I'm not sure that I would classify it as breakage. I always confuse
these but there is a problem with SPF vis-a-vis remails or old style
bounces of messages. The delivery from address specified as mail-from in
the smtp dialog and the envelope from specified in the mail's headers
will differ. And the one that SPF checks is the smtp dialog mail-from
address. So a spammer can setup SPF for his domain and mail will false
positive in the SPF check but the MTA can add a header which lists the
original sender. E.g. [EMAIL PROTECTED] lists himself as the
sender of a mail and lists smtp.spamsource.com as a valid source of mail
for his domain. He crafts an email with a from address of
[EMAIL PROTECTED] and fires is off to you. I'm fairly certain that my
MTA, postfix, will add an Original-Sender: [EMAIL PROTECTED]
header to any message that comes in under these circumstances. I
wouldn't be surprised if my Bayes filter is keying on this header.
In the end internet email is built on a flawed protocol. It'd be great
if you could verify that the letter that you got passed was really sent
by the person who name was really sent in the mail-from part of the smtp
handshake but you can't. For my part I neither want to burden people who
want to send me email with the chore of having to vet themselves nor
wade through excessive amounts of spam. I greylist with spamd and then
filter with spamassassin and it's Bayes filter. I find that this
combination works very well at negligible cost to people who want to
send me mail. YMMV
-- Chris
__o "All I was doing was trying to get home from work."
_`\<,_ -Rosa Parks
___(*)/_(*)___________________________________________________________
Christopher Sean Hilton chris | at | vindaloo.com
pgp: f5:30:0a:54:e1:55:76:9b:1f:47:0b:07:e9:75:0e:14
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
