Hi, How on earth do I tell postfix to use diferent relays based on destination address, from addres, and posibly, ISP used to connect each time? That's the only way I could use relay servers instead of emailing direct - which I can't do, as all my providers seem to be blacklisted tonight. -- Cheers, Carlos Robinson
On Sunday 23 January 2005 04:27 pm, Carlos E. R. wrote:
Hi,
How on earth do I tell postfix to use diferent relays based on destination address, from addres, and posibly, ISP used to connect each time?
That's the only way I could use relay servers instead of emailing direct - which I can't do, as all my providers seem to be blacklisted tonight.
-- Cheers, Carlos Robinson
I do this in sendmail, but in postfix I'm guessing you dig around in /etc/postfix/transports -- _____________________________________ John Andersen
On Mon, 24 Jan 2005 12:27 pm, Carlos E. R. wrote:
How on earth do I tell postfix to use diferent relays based on destination address, from address, and posibly, ISP used to connect each time?
Best technical solution to the many-ISP situation is to have an authenticated SMTP host somewhere on the internet and always use it. So the SMTP host effectively says, "Set up an encrypted channel, and prove that you're you, then I'll let you relay from anywhere." Gmail provide this (and are pretty reliably available). Always sending through the same SMTP relay becomes necessary to enable SPF records. SPF are DNS records that specify which SMTP hosts are allowed to send mail for your domain. (reverse MX records) SPF fixes all those virii flooding the internet with yours and my email picked out of some outlook address book and filled in as the sender. SPF lets a mailhost say, "Not sent from an authorised host, DROP it". Have a look at: http://spf.pobox.com/ -- Michael James michael.james@csiro.au System Administrator voice: 02 6246 5040 CSIRO Bioinformatics Facility fax: 02 6246 5166
On Sunday 23 January 2005 07:29 pm, Michael James wrote:
Always sending through the same SMTP relay becomes necessary to enable SPF records.
Nonsense. There is nothing about an authenticated smtp connectipn that requires spf. SaslAuthD was around for years before spf ever appeared. -- _____________________________________ John Andersen
On Sun, 2005-01-23 at 19:35 -0900, John Andersen wrote:
On Sunday 23 January 2005 07:29 pm, Michael James wrote:
Always sending through the same SMTP relay becomes necessary to enable SPF records.
Nonsense.
There is nothing about an authenticated smtp connectipn that requires spf.
SaslAuthD was around for years before spf ever appeared.
John, Right below your name, in your signature, is a tiny graphic that I can't make out that has an even tinier red 'x' in the center of it. Next to that it says "Invalid signature" Are you *really* who you say you are or are these just spoof posts? ;-) (just kidding!) Just thought you might like to know about it. regards, - Carl
The Monday 2005-01-24 at 01:10 -0500, Carl E. Hartung wrote:
On Sun, 2005-01-23 at 19:35 -0900, John Andersen wrote:
John,
Right below your name, in your signature, is a tiny graphic that I can't make out that has an even tinier red 'x' in the center of it. Next to that it says "Invalid signature"
You probably have to import his signature. I see, in Mozilla: "Untrusted Good signature" which is what I should see. For the signature to be trusted, I would need to meet him, or have his signature signed by someone that I know personally and says it is him. Ie, a chain of trust (more, in the gpg howto). -- Cheers, Carlos Robinson
The Monday 2005-01-24 at 15:29 +1100, Michael James wrote:
Best technical solution to the many-ISP situation is to have an authenticated SMTP host somewhere on the internet and always use it.
True. It also has to be reliable. You know, one of the reasons I started using my own sendmail was to get information (receipts) for sent mail from the server. Postifix doesn't honor them, but I can look at the log and know what happened. When I use an external relay, I don't know. The server can keep retrying for five days... sometimes, the email got lost and I never knew till I contacted the recipient some other way.
So the SMTP host effectively says, "Set up an encrypted channel, and prove that you're you, then I'll let you relay from anywhere."
Gmail provide this (and are pretty reliably available).
People seem to be very interested in gmail. I confess I haven't even bothered to look.
Always sending through the same SMTP relay becomes necessary to enable SPF records.
It needs having a domain name and reverse lookup, I suppose, so dial-up is ruled out. Even getting reverse lookup working is not easy: I know people here on fixed adsl and domain names (.org usually) with no reverse resolving, because the IP belongs to the provider, and they deny that service. Or so I understand.
SPF are DNS records that specify which SMTP hosts are allowed to send mail for your domain. (reverse MX records) SPF fixes all those virii flooding the internet with yours and my email picked out of some outlook address book and filled in as the sender. SPF lets a mailhost say, "Not sent from an authorised host, DROP it".
Have a look at: http://spf.pobox.com/
I'll have a look, I'm curious. -- Cheers, Carlos Robinson
Carlos E. R. wrote:
How on earth do I tell postfix to use diferent relays based on destination address, from addres, and posibly, ISP used to connect each time?
Based on destination: /etc/postfix/main.cf[transport_maps], /etc/postfix/transport Based on from addr - not sure. Perhaps with header_checks. Based on which ISP - I think you can use something like this: relayhost = [smtp.isp1.com], [smtp.isp2.com] but I haven't actually tried it. /Per Jessen, Zürich -- http://www.spamchek.com/freetrial - sign up for your free 30-day trial now!
Per wrote regarding 'Re: [SLE] Relaying.' on Mon, Jan 24 at 04:36:
Carlos E. R. wrote:
How on earth do I tell postfix to use diferent relays based on destination address, from addres, and posibly, ISP used to connect each time?
Based on destination: /etc/postfix/main.cf[transport_maps], /etc/postfix/transport
Based on from addr - not sure. Perhaps with header_checks.
You use /etc/postfix/transports for choosing a transport based on destination address, and can specify said destination address either as a full address (user@do.main) or just a domain (do.main or .do.main). You can only select a transport based on the recipient address, though, not the sender address. AFAIK.
Based on which ISP - I think you can use something like this:
relayhost = [smtp.isp1.com], [smtp.isp2.com]
The relayhost parameter is used when the recipient doesn't match anything in the transports table(s). If you specify the hosts for two ISPs, the only time it'll go to the second is when the first is unreachable. Normally, the first will either accept the message, or reject with a specified code - which postfix will respect (rather than moving on to the next possible host). If you want to send to a different relay based on what ISP you're connected through, you'll have to set up a script that changes the default transport (or the whole transport map) each time you connect. What *I* would do in that situation, presuming Carlos wants to be just like me, is to make a transport map for each ISP I connect though, and another transport map that has things that are common to both ISPs. So, I've now got transport, transport_ISP1, and transport_ISP2 in /etc/postfix. Then, in my post-connect script for ISP1, I'd run postconf -e "transport_maps=hash:/etc/postfix/transport,\ hash:/etc/postfix/transport_ISP1" postfix reload and similarly for ISP2. That way, my global transport settings are preserved for both ISPs (/etc/postfix/transport), and the map for per-ISP settings are added depending on who I'm connected through. Make sure the global one is listed first, and check out the man page for "transport". --Danny, who likes postfix
Danny Sauer wrote:
What *I* would do in that situation, presuming Carlos wants to be just like me, is to make a transport map for each ISP I connect though, and another transport map that has things that are common to both ISPs. So, I've now got transport, transport_ISP1, and transport_ISP2 in /etc/postfix. Then, in my post-connect script for ISP1, I'd run postconf -e "transport_maps=hash:/etc/postfix/transport,\ hash:/etc/postfix/transport_ISP1" postfix reload
I think that's just what Carlos needs.
--Danny, who likes postfix
/Per, who second that. -- http://www.spamchek.com/freetrial - sign up for your free 30-day trial now!
The Monday 2005-01-24 at 11:33 -0600, Danny Sauer wrote:
You use /etc/postfix/transports for choosing a transport based on destination address, and can specify said destination address either as a full address (user@do.main) or just a domain (do.main or .do.main). You can only select a transport based on the recipient address, though, not the sender address. AFAIK.
I thought so, but I also thought I had heard somewhere that more complex rules could be used. You see, it can also make sense to choose a different transport based on the from address, similarly to what a MUA does.
If you want to send to a different relay based on what ISP you're connected through, you'll have to set up a script that changes the default transport (or the whole transport map) each time you connect. What *I* would do in that situation, presuming Carlos wants to be just like me, is to make a transport map for each ISP I connect though, and another transport map that has things that are common to both ISPs. So, I've now got transport, transport_ISP1, and transport_ISP2 in /etc/postfix. Then, in my post-connect script for ISP1, I'd run postconf -e "transport_maps=hash:/etc/postfix/transport,\ hash:/etc/postfix/transport_ISP1" postfix reload and similarly for ISP2. That way, my global transport settings are preserved for both ISPs (/etc/postfix/transport), and the map for per-ISP settings are added depending on who I'm connected through.
Ah, that is in the line of what I was thinking about. I was thinking of having two maps, and symlink the right one to "transport" at connect time, and run postmap and reload. This could be done from the /etc/ppp/ip-up.local script, which is run with root privileges. I only need to learn the name of the provider there. But the only parameters the script is fed with are: interface-name tty-device speed local-IP-address remote-IP-address ipparam The last one could be used for this: ipparam string Provides an extra parameter to the ip-up and ip-down scripts. If this option is given, the string supplied is given as the 6th parameter to those scripts. For that, I would have to convince wvdial to supply that parameter to the pppd daemon. Otherwise, if an arbitrary command could be run from wvdial, that would be it as well. If not, then I'll have to use a wrapper script to call wvdial, and I already do. I'll need to modify that one further...
Make sure the global one is listed first, and check out the man page for "transport".
--Danny, who likes postfix
Me too. -- Cheers, Carlos Robinson
The Tuesday 2005-01-25 at 02:57 +0100, I wrote:
The Monday 2005-01-24 at 11:33 -0600, Danny Sauer wrote:
What *I* would do in that situation, presuming Carlos wants to be just like me, is to make a transport map for each ISP I connect though, and another transport map that has things that are common to both ISPs. So, I've now got transport, transport_ISP1, and transport_ISP2 in /etc/postfix. Then, in my post-connect script for ISP1, I'd run postconf -e "transport_maps=hash:/etc/postfix/transport,\ hash:/etc/postfix/transport_ISP1" postfix reload and similarly for ISP2. That way, my global transport settings are preserved for both ISPs (/etc/postfix/transport), and the map for per-ISP settings are added depending on who I'm connected through.
Ah, that is in the line of what I was thinking about. I was thinking of having two maps, and symlink the right one to "transport" at connect time, and run postmap and reload. This could be done from the /etc/ppp/ip-up.local script, which is run with root privileges.
Question, before I go to sleep :-) suppose I have: destination1 smtp:ServerOfTheDay destination2 smtp:ServerOfTheDay destination3 smtp:ServerOfTheDay My idea is if it is possible to define "ServerOfTheDay" somewhere else, and only change that definition each time. Then, my map would be defined once, I would only have to say which relay has to be used each time. I have looked at "man transport", and it talks about mydestination, virtual_mailbox_domains, and relay_domains. Then it talks about domain, transport, and nexthop. I wonder if "transport" can be used for what I say, or that word has to be "smtp", uucp or some other token. Ok, I'm sending what I have pending and calling it a day. :-) -- Cheers, Carlos Robinson
Carlos wrote regarding 'Re: [SLE] Relaying.' on Mon, Jan 24 at 21:20:
The Tuesday 2005-01-25 at 02:57 +0100, I wrote:
The Monday 2005-01-24 at 11:33 -0600, Danny Sauer wrote:
What *I* would do in that situation, presuming Carlos wants to be just like me, is to make a transport map for each ISP I connect though, and another transport map that has things that are common to both ISPs. So, I've now got transport, transport_ISP1, and transport_ISP2 in /etc/postfix. Then, in my post-connect script for ISP1, I'd run postconf -e "transport_maps=hash:/etc/postfix/transport,\ hash:/etc/postfix/transport_ISP1" postfix reload and similarly for ISP2. That way, my global transport settings are preserved for both ISPs (/etc/postfix/transport), and the map for per-ISP settings are added depending on who I'm connected through.
Ah, that is in the line of what I was thinking about. I was thinking of having two maps, and symlink the right one to "transport" at connect time, and run postmap and reload. This could be done from the /etc/ppp/ip-up.local script, which is run with root privileges.
Question, before I go to sleep :-)
suppose I have:
destination1 smtp:ServerOfTheDay destination2 smtp:ServerOfTheDay destination3 smtp:ServerOfTheDay
My idea is if it is possible to define "ServerOfTheDay" somewhere else, and only change that definition each time. Then, my map would be defined once, I would only have to say which relay has to be used each time.
Do you mean by defining in /etc/hosts? Name lookups are cached, so a change would not take effect immediately. You can not define arbitrary variables in postfix, either. So, AFAIK, no, not really.
I have looked at "man transport", and it talks about mydestination, virtual_mailbox_domains, and relay_domains. Then it talks about domain, transport, and nexthop. I wonder if "transport" can be used for what I say, or that word has to be "smtp", uucp or some other token.
The word has to be smtp or another defined transport mechanism (such as filter). --Danny
Carlos wrote regarding 'Re: [SLE] Relaying.' on Mon, Jan 24 at 20:28:
The Monday 2005-01-24 at 11:33 -0600, Danny Sauer wrote:
You use /etc/postfix/transports for choosing a transport based on destination address, and can specify said destination address either as a full address (user@do.main) or just a domain (do.main or .do.main). You can only select a transport based on the recipient address, though, not the sender address. AFAIK.
I thought so, but I also thought I had heard somewhere that more complex rules could be used. You see, it can also make sense to choose a different transport based on the from address, similarly to what a MUA does.
I think that's sort of something the MUS *should* be doing. The MTA is handed a message with a recipient because the MTA is supposed to be the "next hop" on the way to the destination. Regardless of my opinion on the matter (and how useful it would be to your situation), postfix can't choose a nexthop based on the sender. The transport lookup is only done on the recipient address. If it looked up the sender and the recipient, it would need a way to determine which of the two it should prefer in the event of multiple matches, and that would double the amount of time spent in the trivial-rewrite phase. Now, you could potentially combine some address rewriting filter that, given a sender address, would change the recipient before passing it off to postfix - taking advantage of the user+extension@do.main syntax...
If you want to send to a different relay based on what ISP you're connected through, you'll have to set up a script that changes the default transport (or the whole transport map) each time you connect. What *I* would do in that situation, presuming Carlos wants to be just like me, is to make a transport map for each ISP I connect though, and another transport map that has things that are common to both ISPs. So, I've now got transport, transport_ISP1, and transport_ISP2 in /etc/postfix. Then, in my post-connect script for ISP1, I'd run postconf -e "transport_maps=hash:/etc/postfix/transport,\ hash:/etc/postfix/transport_ISP1" postfix reload and similarly for ISP2. That way, my global transport settings are preserved for both ISPs (/etc/postfix/transport), and the map for per-ISP settings are added depending on who I'm connected through.
Ah, that is in the line of what I was thinking about. I was thinking of having two maps, and symlink the right one to "transport" at connect time, and run postmap and reload. This could be done from the /etc/ppp/ip-up.local script, which is run with root privileges.
I only need to learn the name of the provider there. But the only parameters the script is fed with are:
interface-name tty-device speed local-IP-address remote-IP-address ipparam
Can you switch based on the IP address? Surely their netblocks don't overlap, so you could just use the given IP as a determining factor as to which map you'd use... --Danny,
The Tuesday 2005-01-25 at 10:56 -0600, Danny Sauer wrote:
I thought so, but I also thought I had heard somewhere that more complex rules could be used. You see, it can also make sense to choose a different transport based on the from address, similarly to what a MUA does.
I think that's sort of something the MUS *should* be doing. The MTA is handed a message with a recipient because the MTA is supposed to be the "next hop" on the way to the destination.
Yes... it should. Hold on, I don't know the acronynm "MUS". Someone said the other day how to look up those in google, but I forgot. I need a refresher course in google ;-) (I almost do not browse, my connected time costs money, so I minimize it)
Regardless of my opinion on the matter (and how useful it would be to your situation), postfix can't choose a nexthop based on the sender. The transport lookup is only done on the recipient address. If it looked up the sender and the recipient, it would need a way to determine which of the two it should prefer in the event of multiple matches, and that would double the amount of time spent in the trivial-rewrite phase. Now, you could potentially combine some address rewriting filter that, given a sender address, would change the recipient before passing it off to postfix - taking advantage of the user+extension@do.main syntax...
[I'll have to study that syntax]
Look. At this moment, I'm trying to download the kernel update. To do
this, I connect through teleline, because it has some more bandwidth than
tiscali (meaning that probably tiscali doesn't have an access router at my
local exchange, but sends the phone call forward perhaps 500 km away.
Ftp gets and average of 3-4 Kbps with them).
When I started tonight, I could send to this list. A moment ago, I can't.
Ok, I say, so say to postfix to route to suse through teleline (teleline
uses smtp with authentification). You know what happened? (English version
below):
Jan 26 02:03:21 nimrodel postfix/smtp[12505]: 4FFC020DD0:
to=
parameters the script is fed with are:
interface-name tty-device speed local-IP-address remote-IP-address ipparam
Can you switch based on the IP address? Surely their netblocks don't overlap, so you could just use the given IP as a determining factor as to which map you'd use...
If I knew all the ranges they have... remember, we are talking of a provider serving all of Spain. The ranges is not a thing they publish. I can dig each one, one at a time, but all of them... -- Cheers, Carlos Robinson
participants (6)
-
Carl E. Hartung -
Carlos E. R. -
Danny Sauer -
John Andersen -
Michael James -
Per Jessen