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
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 talking to 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 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 |

                  pgp: f5:30:0a:54:e1:55:76:9b:1f:47:0b:07:e9:75:0e:14

_______________________________________________ mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to