Sam Varshavchik wrote:

Julian Mehnle writes:

Alessandro Vesely [EMAIL PROTECTED] wrote:

It is still not clear why one would rewrite senders. SPF should work
if everybody takes the burden of declaring what are the mail servers
they use.


Suppose I have an account with the CPAN project and thus have the e-mail
address <[EMAIL PROTECTED]>.  Instead of fetching mail from there via
POP3/IMAP, I set it to forward mail to my other address
<[EMAIL PROTECTED]>.  The mehnle.net MTA does SPF checking.

...

To solve the problem, cpan.org would have to rewrite the envelope sender
to something at cpan.org before forwarding the message.

This is a very classical forwarding scenario.


If you know that you're going to get forwarded mail, then you'll just have to turn off SPF; or, with some additional planning, disable SPF checking for mail received from CPAN's IP address (this can actually be done in Courier, using the smtpaccess file).


Though I'm not necessarily advocating the SRS issue itself, the fact that you *can* disable the checks does little to soothe the nerves of email users who don't even realize the mail is being blocked right away. That is, putting the exceptions into the config is always a reactionary process. Nor would this necessarily be something you can plan for, as in Julian's scenario where a user can arbitrarily decide to have mail forwarded to them. Again, not pushing SRS necessarily, but if there is something that can bridge the gap between absolutely no SPF enabled and bye-bye email, that'd be a big help. SPF clearly is something intended to be phased in -- going to the point of allowing advisory messages in email headers rather than totally dumping the messages. Anything that prevents mail delivery without a means of providing an out -- globally ,if need be -- seems to fly in the face of how they've been pushing SPF (IMHO).


Bill


------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to