On Fri, 22 Aug 2008 06:39:37 pm Alessandro Vesely wrote: > Mark Constable wrote: > >> That state of affairs is obviously wrong... > > > > Absolutely. A sidebar at http://www.openspf.org/SRS says... > > > > [...] if you do check SPF, and you wish to > > reject messages that fail SPF, then you must do one of two things > > to avoid rejecting legitimate mail: > > > > . whitelist forwarder IP addresses > > . use forwarders that rewrite the sender > > It is also possible to do both of them. Rather than patching an SRS > implementation into Courier, I'd be out to enhance authlib in order to > allow easier management of whitelisting: It would be enough to > overload the RELAYCLIENT feature such that after authentication, > depending on options, the sender is only allowed to send mail to a > given recipient. That way, rather than insert their host's IP into a > whitelist, you give their host an id/password pair by which you > authorize it to forward to a given mailbox only. The advantages are > > * long lasting links (no changes required when IPs change,) > > * single mailbox granularity, which implies > > * accurate bookkeeping of who is authorized to forward what. That way, > the receiving host would have a database of incoming authorizations > mirroring the database of forwarding recipes at the senders': A doubly > linked list where we now have an unmaintainable singly linked one. > > Rewriting the sender should be operated according to sender's local > policies, depending on what kind of forwarding is being operated. I > guess Sam is correct when he suggests that this ought to be done with > maildrop.
As usual, I am missing some dots. Perhaps there are 2 situations that need different solutions. I think the above applies to a host that is doing the forwarding in such a way that it will be accepted by the destination mailserver that employs SPF checking, by rewriting the From_ line. So, for example, every dot courier file that has a [EMAIL PROTECTED] entry needs to apply some maildrop rules to massage the message before it's re-injected back into the system. If that is right then, although it's ugly and I'm not sure exactly how to do it, I can imagine it is feasible. That takes care of me doing the right thing for my users who need to forward messages offsite. However, does this mean that there is simply no way, ever, to accept or bypass the SPF block for messages coming into our mailserver from another host that does not rewrite similar forwarded messages? In other words, the absolute bottom line is that, if I want to accept messages that are aliased or forwarded from other hosts that do not use SRS or rewrite the From_ header, but do use an SPF TXT record, that I have to disable SPF checking? --markc ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
