Roman Medina-Heigl Hernandez wrote:
DJ Lucas escribió:
Return-Path: <[EMAIL PROTECTED]>
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
...
Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1])
by gangotri.ubuntu.com (Postfix) with ESMTP id 0C222318376
for <[EMAIL PROTECTED]>; Fri, 28 Jul 2006 04:10:09 +0100 (BST)
From: RoMaNSoFt <[EMAIL PROTECTED]>
Maybe I'm incorrect, but I believe there was a subtle misunderstanding
in the above conversation. The From: header is not the same as MAIL
FROM: command in smtp transaction. MAIL FROM for this message was
[EMAIL PROTECTED] Feel fee to find that message in your logs and
Thank you for the correction, you are right: my example is wrong but that
doesn't change the fact we were discussing since Noel and I were always
referring to the "mail from" (i.e. the sender). If some silly ticket system
spoofs the "From" header, there is a good chance that it spoofs the "mail
from" too...
verify. Anyway, the Postfix directive you are looking for is
"reject_unauthenticated_sender_login_mismatch".
http://www.postfix.org/postconf.5.html#reject_unauthenticated_sender_login_mismatch
Yes, I think that's the directive I was looking for.
That said, cheap web scripts often do use the recipient's address in the
transaction. Latest complaint I had was from some star rewards thing
for frequent visits to a restaurant (for which I promptly replied:
"choose a different restaurant" ;-) ).
I have been working on a similar if not the exact same problem from what
I've seen in this thread. The problem being from = to address and how to
stop spam that does this. My idea for a solution to this problem was to
require any mail claiming to be from a local account to authenticate
first when arriving from outside of the network and heading to a local
mailbox. As it has already been pointed out, there are cases where you
have false positives, in fact I found one yesterday with a user's
blackberry setup shortly after I set it up. I'm thinking that utilizing
check_client_access before check_sender_access under
smtpd_recipient_restrictions and adding exceptions for these few cases
is a sound solution. It's obviously not perfect because of the
administration overhead of having to watch for these special
circumstances. I have yet to test this. Any thoughts on this approach?