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?

Reply via email to