Carlos E. R. schreef:
The problem, or problems, are several. For one thing, the smtp relay servers my ISPs provide are not reliable: they may fail to send an email, and worse, they don't inform me of that, or they do several days late.
The fact that they don't inform you immediately, is quite normal. Most MTA's are configured to try to deliver a message for a couple of days before reporting a delivery error. You don't want to be informed about every transient error in delivery.
But even if I use the relay, they have policies that impede my use of them seriously, like only accepting email with a "From" address of theirs.
Their servers, their rules.
Therefore, I can not send all my email through only one relay server, or not at all for redirection accounts (like sourceforge).
In that case, chances are that you need to configure these upstream hosts in your MUA, instead of your MTA. I'm sure KMail (which you appear to be using) has no problem with multiple upstream hosts. Why are you so determined to want to run your own MTA? The fact that you can't send e-mail with a sourceforge.net adress, is because the sourceforge.net SPF record doesn't approve that. Regardless of the ISP, you can't fix that. By sending these messages yourself, won't change that and likely will cause many rejects from systems that check SPF records.
Unfortunately, Postfix transport file does not has rules to select which relay server to choose based on the FROM address, only on the TO part. I need that feature.
The feature is there in Postfix since version 2.0 was released (sender_based_routing = yes), but the author recommends against using it. It will cause all kinds of nasty issues, for instance when the sender is not so clear (the null sender adress for NDN's).
I was told (thanks, Arjen) to try 'esmtp' (http://esmtp.sourceforge.net/) - I've downloaded it, waiting for compilation -but a comment I read makes me afraid that it will not work well with non permanent connections.
Do you mean you have a dialup (modem) connection? In that case you have no business running a mailserver. In all other cases, you're already having problems now, how much worse can it be?
Thus, I have no alternative (yet?) but to use Postfix for direct sending.
You still don't seem to understand that you're figthing an uphill battle. The problems you're suffering from right now will only increase, rather than decrease. ISP's are getting more strict in who is allowed to relay through their systems, who is allowed to use their domain names and from which systems these messages should be delivered. SPF is just one of the ways to enforce this and is being deployed now (by 'terra.es' for instance, although their (pretty lenient) SPF record will not allow to reject messages).
In my opinion, the best solution would be a method to really identify who is sending, regardless of the type of IP he is using. A cryptographic signature, probably, for the "FROM" header, not the contents (signing the contents is a problem with domainkeys with lists like SuSE's)
Good luck. Maybe in twenty years time, but for the foreseeable future I think we are pretty much stuck with the system as it is right now. Anything that requires massive changes in MUA's (like DomainKeys) is likely to take many years.
At least in Spain, with a court order, it is possible to identify the spammer with the IP, because there are listings correlating each IP and timestamp to the phone used, and thus, the person responsible.
This doesn't work on a global scale. As a non-resident I can't possibly get a court order and sue a spammer abroad. And as you already told, many ISP's are not that responsive when it comes to complaints. So while it may be technically and legally possible to find a spammer, practically it is of little use. Besides this, the main reason for not allowing residential customers (even on static IP's) to send e-mail directly is virusses, not spam (although some virusses act as a spamrelay, so the difference is not clear cut). Regards, Arjen