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
I'm not sure what you mean by callbacks but if that involves
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
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.
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
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
because the owner of the domain hasn't published an SPF record. The
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.
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net
email@example.com mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"