OT: Posting from another unsubscribed address for a subscriber?
Hi all, Sorry for the OT post. I currently have my new email address of hylton@conacher.co.za subscribed to this list. I have just also subscribed this address so I can solve the problem I am having. If I receive list mail on the hylton@conacher address, I cannot reply to it from the conacher address bucause my ISP will not route the mail as they autheniticate the sender ie the sender hylton@conacher is not the email address of the connected member on their network and they therefore drop the mail into the ether. Is there a way I can send email to the list that is identified by the ISP as being from the correct paying account and delivered to the SuSE listserver as being from another email address, in this case a suscribed address. Perhaps something like the Cc address(SLE <suse-linux-e-hylton=conacher.co.za@suse.com>)? Your assistance MUCH appreciated.
Organization: Ptilopteri in Pandemonium * Hylton Conacher (ZR1HPC) <hylton@global.co.za> [04-10-06 20:36]:
Is there a way I can send email to the list that is identified by the ISP as being from the correct paying account and delivered to the SuSE listserver as being from another email address, in this case a suscribed address. Perhaps something like the Cc address(SLE <suse-linux-e-hylton=conacher.co.za@suse.com>)?
Why don't you get a free gmail account and use it to send and receive mail. Gmail has pop access an smtp for free. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
Am Dienstag, 11. April 2006 05:18 schrieb Patrick Shanahan:
(...) Why don't you get a free gmail account and use it to send and receive mail. Gmail has pop access an smtp for free.
I wonder how many people on this list use gmail and even propagate it. Ok, maybe there are some nice features with it - but don't you care about your privacy? As much as I know google searches all your emails for stuff that could be used to profile your customs and preferences. As we know Google does *everything* for money, without any restriction, it cooperates with Censorship of Publications Boards (e.g. China), even deliveres information to the actual criminal US governement and so on... I'd say to abandon and giving away my privacy just for using a simple email program is far away from what I call a "free service". Daniel -- Daniel Bauer photographer Basel Switzerland professional photography: http://www.daniel-bauer.com special interest site: http://www.bauer-nudes.com
I wonder how many people on this list use gmail and even propagate it. Ok, maybe there are some nice features with it - but don't you care about your privacy?
What privacy? I use Gmail for this list (one of many). This mailing list is publically archived/indexed by dozens of different mail archives (including Google)... and it's searchable by anyone with almost any search engine. If I use GMail only for this list - which I do, I don't see what privacy I'm loosing that I haven't already lost by participating in this list. C.
Am Dienstag, 11. April 2006 10:38 schrieb Clayton:
I wonder how many people on this list use gmail and even propagate it. Ok, maybe there are some nice features with it - but don't you care about your privacy?
What privacy? I use Gmail for this list (one of many). This mailing list is publically archived/indexed by dozens of different mail archives (including Google)... and it's searchable by anyone with almost any search engine.
If I use GMail only for this list - which I do, I don't see what privacy I'm loosing that I haven't already lost by participating in this list.
C.
Agreed. As long as gmail is used *only* to take part in public lists and similar there's nothing to say against it. Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-04-10 at 17:01 +0200, Hylton Conacher (ZR1HPC) wrote:
If I receive list mail on the hylton@conacher address, I cannot reply to it from the conacher address bucause my ISP will not route the mail as they autheniticate the sender ie the sender hylton@conacher is not the email address of the connected member on their network and they therefore drop the mail into the ether.
Is there a way I can send email to the list that is identified by the ISP as being from the correct paying account and delivered to the SuSE listserver as being from another email address, in this case a suscribed address.
I don't know what you use to send your email. But, for example, if you use an email client like Mozilla - I know you do - - you can send the email corresponding to each account through the smtp server of that account. You shouldn't then have any problem. Other alternative would be that your ISP authenticated you and allowed you to send email with any from address you choose, regardless of which. That, which should be normal, is not in some countries and isps. I have suffered that situation too. The other alternative, the one I use, is to use your local smtp server (postfix) to send your email direct. This is frown upon by a number of administrators that are lucky enough to have good providers and these problems are remote and unknown to them - so much frown upon that they use lists to block emails sent direct from dynamic addresses. {Yeah, I know the reasons they have, but I can not agree} I heard that postfix supports now choosing the relay based on the from address, but I haven't learnt how yet. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEO4gKtTMYHG2NR9URAqTXAJ9MyjnIPoCkMZWlhErTGpkrZG14/QCfVUIt CXy5g029ZbbZedg/WM4OgeA= =otAU -----END PGP SIGNATURE-----
* Carlos E. R. <robin1.listas@tiscali.es> [04-11-06 06:43]:
I heard that postfix supports now choosing the relay based on the from address, but I haven't learnt how yet.
# TRANSPORT(5) TRANSPORT(5) # # NAME # transport - Postfix transport table format # # SYNOPSIS # postmap /etc/postfix/transport # # postmap -q "string" /etc/postfix/transport # # postmap -q - /etc/postfix/transport <inputfile # # DESCRIPTION # The optional transport(5) table specifies a mapping from # email addresses to message delivery transports and/or # relay hosts. The mapping is used by the trivial-rewrite(8) # daemon. # # This mapping overrides the default routing that is built # into Postfix: # # mydestination # A list of domains that is by default delivered via # $local_transport. This also includes domains that # match $inet_interfaces or $proxy_interfaces. # # virtual_mailbox_domains # A list of domains that is by default delivered via # $virtual_transport. # # relay_domains # A list of domains that is by default delivered via # $relay_transport. # # any other destination # Mail for any other destination is by default deliv- # ered via $default_transport. # I did this until it became toooo much of a hassle. Seems everyone wants to block non-static ip addresses. I now relay via my isp and can still use the gmail return addresses, but I do *not* use gmail's smtp service. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-04-11 at 09:35 -0400, Patrick Shanahan wrote:
* Carlos E. R. [04-11-06 06:43]:
I heard that postfix supports now choosing the relay based on the from address, but I haven't learnt how yet.
# TRANSPORT(5) TRANSPORT(5) # # NAME # transport - Postfix transport table format
Yes, but: ] TABLE FORMAT ] The input format for the postmap(1) command is as follows: ] ] pattern result ] When pattern matches the recipient address or domain, use ] the corresponding result. We need to match on the sender address, not only the recipient address, because here isp relays only allow sending with their own domains in the "From" field. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEO70rtTMYHG2NR9URAsoCAJsG8mgaXSjMSe9wjSE0Z+7QZ7vpawCfS0DM XFK4VVwwb+aMXYMYTnbyDZE= =r5AF -----END PGP SIGNATURE-----
Hylton Conacher (ZR1HPC) wrote: <snip>
If I receive list mail on the hylton@conacher address, I cannot reply to it from the conacher address bucause my ISP will not route the mail as they autheniticate the sender ie the sender hylton@conacher is not the email address of the connected member on their network and they therefore drop the mail into the ether.
Is there a way I can send email to the list that is identified by the ISP as being from the correct paying account and delivered to the SuSE listserver as being from another email address, in this case a suscribed address. Perhaps something like the Cc address(SLE <suse-linux-e-hylton=conacher.co.za@suse.com>)?
Your assistance MUCH appreciated.
Thank you both to Patrick and Carlos whose reply I received twice as I had to subscribe my ISP email address. I gotta remember to unsub one of them soon :) I have a GMail account but currently do not use it to even 1% of its potential as I have to have an email account at a local ISP so that I have to use so that I can connect to the internet. I have my ISP's SMTP server as th relevant entry. I have so far managed to glean from my ISP that they authenticate all outgoing email to check that the sender is the person connected/allowed to connect to their network. Patrick got me thinking though...Perhaps I could insert the GMail SMTP server entry in my local client, correctly identified by Carlos as Mozilla 1.7.2, as opposed to my ISP SMTP server? Could I use the GMail SMTP server without logging onto GMail? I have just checked with my ISP though and they say that my SMTP server entry must be their one, not that I believe them though. So the mail client setup here could be: - 3 Inboxes, each with their own email address - The SMTP entry of GMail - A dialup connection using one of the email addresses to authenticate myself to the ISP. When I send email from any one of the three email addresses I have, it will all be delivered regardless of the sending email address? An idea? comments?
* Hylton Conacher (ZR1HPC) <hylton@global.co.za> [04-12-06 14:58]:
So the mail client setup here could be: - 3 Inboxes, each with their own email address - The SMTP entry of GMail - A dialup connection using one of the email addresses to authenticate myself to the ISP.
When I send email from any one of the three email addresses I have, it will all be delivered regardless of the sending email address?
An idea? comments?
I have not used gmail's smtp service, but it *may* require that you use your gmail account address. My roadrunner account does not require this, so I have not bothered to try gmail-smtpm and am able to use a gmail From: address. Their instructions and/or a simple trial email should provide you with the answer. Another problem may arise, the last time I used mozilla for mail (some time long ago), you were only allowed *one* pop account configuration, but could use multiple imap accounts. Gmail has no imap capabilities. A simple solution to this would be two or more mozilla profiles. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
On Wednesday 12 April 2006 15:18, Patrick Shanahan wrote:
* Hylton Conacher (ZR1HPC) <hylton@global.co.za> [04-12-06 14:58]:
So the mail client setup here could be: - 3 Inboxes, each with their own email address - The SMTP entry of GMail - A dialup connection using one of the email addresses to authenticate myself to the ISP.
When I send email from any one of the three email addresses I have, it will all be delivered regardless of the sending email address?
An idea? comments?
I have not used gmail's smtp service, but it *may* require that you use your gmail account address. My roadrunner account does not require this, so I have not bothered to try gmail-smtpm and am able to use a gmail From: address.
Their instructions and/or a simple trial email should provide you with the answer.
Another problem may arise, the last time I used mozilla for mail (some time long ago), you were only allowed *one* pop account configuration, but could use multiple imap accounts. Gmail has no imap capabilities.
A simple solution to this would be two or more mozilla profiles. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2 I just responded with smtp from my home server using my gmail from.
-- Christopher Taylor - Registered Linux User #383327
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-04-12 at 15:18 -0400, Patrick Shanahan wrote:
Another problem may arise, the last time I used mozilla for mail (some time long ago), you were only allowed *one* pop account configuration, but could use multiple imap accounts. Gmail has no imap capabilities.
No, you can set as many pop or imap account as you want, and each account may use the smtp server you like, either local or remote.
A simple solution to this would be two or more mozilla profiles.
I think that was a limitation of netscape 4, but I'm not sure. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEPX1rtTMYHG2NR9URAiPkAJ49zdEwzgtZOTs5iTGvb3cNd+1QTACfaOEi nXtI2Z45piEYzfmTGSkb+hY= =wKZR -----END PGP SIGNATURE-----
Patrick Shanahan wrote:
* Hylton Conacher (ZR1HPC) <hylton@global.co.za> [04-12-06 14:58]:
So the mail client setup here could be: - 3 Inboxes, each with their own email address - The SMTP entry of GMail - A dialup connection using one of the email addresses to authenticate myself to the ISP.
When I send email from any one of the three email addresses I have, it will all be delivered regardless of the sending email address?
An idea? comments?
I have not used gmail's smtp service, but it *may* require that you use your gmail account address. My roadrunner account does not require this, so I have not bothered to try gmail-smtpm and am able to use a gmail From: address.
Their instructions and/or a simple trial email should provide you with the answer. I'll give it a try and report back in a bit.
Another problem may arise, the last time I used mozilla for mail (some time long ago), you were only allowed *one* pop account configuration, but could use multiple imap accounts. Gmail has no imap capabilities.
A simple solution to this would be two or more mozilla profiles. Thankfully the Mozilla(1.7.2) that I am using does not have this account limitation but it does only allow a single SMTP server entry. I wonder if Thunderbird has the same limitation as I am hoping to move onto it in a soon to be released boxed release.
Hylton Conacher (ZR1HPC) wrote:
Patrick Shanahan wrote:
Another problem may arise, the last time I used mozilla for mail (some time long ago), you were only allowed *one* pop account configuration, but could use multiple imap accounts. Gmail has no imap capabilities.
A simple solution to this would be two or more mozilla profiles. Thankfully the Mozilla(1.7.2) that I am using does not have this account limitation but it does only allow a single SMTP server entry. I wonder if Thunderbird has the same limitation as I am hoping to move onto it in a soon to be released boxed release.
Mozilla 1.7.12 supports multiple SMTP servers, as does SeaMonkey
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-04-15 at 12:26 +0200, Hylton Conacher (ZR1HPC) wrote:
A simple solution to this would be two or more mozilla profiles. Thankfully the Mozilla(1.7.2) that I am using does not have this account limitation but it does only allow a single SMTP server entry. I wonder if
That's not true. I have six, at least. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEQUQdtTMYHG2NR9URAlCmAJ98+K7EJqINY40CnKgN6SVBXAmwZwCfVzeQ /gTlilodP7WrHxQG+ctzPfc= =WHBt -----END PGP SIGNATURE-----
Hylton Conacher (ZR1HPC) wrote:
Patrick Shanahan wrote:
* Hylton Conacher (ZR1HPC) <hylton@global.co.za> [04-12-06 14:58]:
So the mail client setup here could be: - 3 Inboxes, each with their own email address - The SMTP entry of GMail - A dialup connection using one of the email addresses to authenticate myself to the ISP.
When I send email from any one of the three email addresses I have, it will all be delivered regardless of the sending email address?
An idea? comments?
I have not used gmail's smtp service, but it *may* require that you use your gmail account address. My roadrunner account does not require this, so I have not bothered to try gmail-smtpm and am able to use a gmail From: address.
Their instructions and/or a simple trial email should provide you with the answer.
I'll give it a try and report back in a bit. FYI: Using the GMail server as an SMTP server does NOT work for me when I am sending messages with a from gmail address, at least not in Mozilla 1.7.2. <snip>
Thread closed
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-04-22 at 20:38 +0200, Hylton Conacher (ZR1HPC) wrote:
FYI: Using the GMail server as an SMTP server does NOT work for me when I am sending messages with a from gmail address, at least not in Mozilla 1.7.2.
Then you haven't set up mozilla correctly, because it works for me. Just follow their instructions. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFES9hctTMYHG2NR9URAuhxAJ9F4sx/L5o754Vr2dDfwEvSpq4jkgCePz87 AmJALLzU3KEQsMm85EGZIYU= =n5jY -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-04-12 at 12:45 +0200, Hylton Conacher (ZR1HPC) wrote:
Patrick got me thinking though...Perhaps I could insert the GMail SMTP server entry in my local client, correctly identified by Carlos as Mozilla 1.7.2, as opposed to my ISP SMTP server? Could I use the GMail SMTP server without logging onto GMail?
Yes, of course. You set up the account in Mozilla-mail; you then choose the smtp server in the advanced section of the account "server setting" setup, from one of the many separate "outgoing servers (smtp)" (in the "Advanced" button) you had previously setup in Mozilla-mail. Gmail simply requires you to authentificate; ie, select "User name and pass" and "TLS".
I have just checked with my ISP though and they say that my SMTP server entry must be their one, not that I believe them though.
Possibly.
So the mail client setup here could be: - 3 Inboxes, each with their own email address - The SMTP entry of GMail
As many smtp servers as you want, posibly a different one for each account.
- A dialup connection using one of the email addresses to authenticate myself to the ISP.
When I send email from any one of the three email addresses I have, it will all be delivered regardless of the sending email address?
Pardon? - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEPX+ytTMYHG2NR9URAsLzAJ9swzCEUQg4iTM/l+ly7V0K14Nh1gCfbRjy 0Y/uonbDD0eTZKyAC4VSwUA= =B16D -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Wednesday 2006-04-12 at 12:45 +0200, Hylton Conacher (ZR1HPC) wrote:
Patrick got me thinking though...Perhaps I could insert the GMail SMTP server entry in my local client, correctly identified by Carlos as Mozilla 1.7.2, as opposed to my ISP SMTP server? Could I use the GMail SMTP server without logging onto GMail?
Yes, of course.
You set up the account in Mozilla-mail; you then choose the smtp server in the advanced section of the account "server setting" setup, from one of the many separate "outgoing servers (smtp)" (in the "Advanced" button) you had previously setup in Mozilla-mail. Gmail simply requires you to authentificate; ie, select "User name and pass" and "TLS". Tnx Carlos, I learn everyday!! I didn't realize that I could have more
I'll have to give this a try. than one SMTP server. I see now that the Outgoing server entry is the default SMTP sever and under the advanced button I can add/specify a SMTP server I would rather use. As a result maybe I won't have to use the GMail SMTP server to deliver ALL my email. <snip>
So the mail client setup here could be: - 3 Inboxes, each with their own email address - The SMTP entry of GMail
As many smtp servers as you want, posibly a different one for each account. :)
- A dialup connection using one of the email addresses to authenticate myself to the ISP.
When I send email from any one of the three email addresses I have, it will all be delivered regardless of the sending email address?
Pardon? Ok, more explanation follows:
I have a Tiscali dialup account that includes a single email address on their network. I also have a GMail account and another email address on my own domain. So in essence I have a single dialup connection but have configured Mozilla to allow me to send email from either of the three email addresses I have. The unfortunate thing is/possibly was, was that any mail sent from any of the email addresses I own had to be delivered by the tiscali SMTP server. Tiscali, in all their wisdom, seemed to decide that they would not send email from another domain if they received it from a client connected to their network ie I dial into them and am therefore allowed to send email from the email account they gave me but it seems not from another domain email address ie hylton@conacher.co.za. Seems most strange as I thought SMTP servers were merely mail relays between hosts who didn't initially confirm the authentication of the sender.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-04-15 at 13:13 +0200, Hylton Conacher (ZR1HPC) wrote:
When I send email from any one of the three email addresses I have, it will all be delivered regardless of the sending email address?
Pardon? Ok, more explanation follows:
I have a Tiscali dialup account that includes a single email address on their network. I also have a GMail account and another email address on my own domain. So in essence I have a single dialup connection but have configured Mozilla to allow me to send email from either of the three email addresses I have.
The unfortunate thing is/possibly was, was that any mail sent from any of the email addresses I own had to be delivered by the tiscali SMTP server. Tiscali, in all their wisdom, seemed to decide that they would not send email from another domain if they received it from a client connected to their network ie I dial into them and am therefore allowed to send email from the email account they gave me but it seems not from another domain email address ie hylton@conacher.co.za.
Ah, yes, I understand. The funny thing is that dialup tiscali.es allows sending email with any address in the from field, with no authentication method, BUT! You have to be connected with an IP of theirs. On the other hand, if my IP belongs to another network, they do not allow me to send even if my from is @tiscali.es. Absurd. By the way, tiscali.es is out of business. They sold their customers et al to "Wanadoo" (France Telecom España S.A). On the other hand, teleline.es (my other dialup provider) requires you to authenticate, an will not allow you to send with any "from" except @teleline.es. I haven't yet learnt what my current provider does. So, yes, I understand your problem. That's the main reason I use postfix to send directly.
Seems most strange as I thought SMTP servers were merely mail relays between hosts who didn't initially confirm the authentication of the sender.
No, an smtp that does relay has to authenticate. The only one that doesn't is the destination server of the email. It's a measure to hamper somehow the indiscriminate sending of spam through any smtp server. If you have to authenticate, you are accountable for what you send and can be sued. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEQUcktTMYHG2NR9URAiXeAJ4yNvgFEUeSb1O95OZ6dsSyHV788QCdHyrs gqE7iX2JhIm/nkhWolPlx5I= =b5Jt -----END PGP SIGNATURE-----
On Sunday 16 April 2006 02:18, Carlos E. R. wrote:
The Saturday 2006-04-15 at 13:13 +0200, Hylton Conacher (ZR1HPC) wrote:
When I send email from any one of the three email addresses I <big snip> I haven't yet learnt what my current provider does.
So, yes, I understand your problem. That's the main reason I use postfix to send directly.
Interesting discussion. But now another question. What are the basic requirements to send email direct with postfix?
On Sunday 16 April 2006 02:18, Carlos E. R. wrote:
The Saturday 2006-04-15 at 13:13 +0200, Hylton Conacher (ZR1HPC) wrote:
When I send email from any one of the three email addresses I
<big snip>
I haven't yet learnt what my current provider does.
So, yes, I understand your problem. That's the main reason I use postfix to send directly.
Interesting discussion. But now another question. What are the basic requirements to send email direct with postfix? Glad it tickled the brain CB :) I am also interested in the solution to your query however about mailservers as I am looking at setting one up one locally that will connect to an ISP via dialup at certain timse of
C. Brouerius van Nidek wrote: the day, send its outgoing mail and receive my mail from as many domains as I decided to have email addreses on. I wonder if the ISP will still check that the sender' email domain is the person who dialed up? Carlos, what happened to your Postfix server when you dialed up, and the cnx was authenticated. Did you send email from a domain not owned by Tiscali or being an SMTP server is the checking not done between your one and the ISP one? I understand the authentication is there to prevent SPAM etc but what have other folks done, who have more than a single email address on a domain not owned by their ISP, to send that domain email? Is there a way around it if I am using dialup?
Carlos E. R. wrote:
The Saturday 2006-04-15 at 13:13 +0200, Hylton Conacher (ZR1HPC) wrote:
When I send email from any one of the three email addresses I have, it will all be delivered regardless of the sending email address?
Pardon?
Ok, more explanation follows:
I have a Tiscali dialup account that includes a single email address on their network. I also have a GMail account and another email address on my own domain. So in essence I have a single dialup connection but have configured Mozilla to allow me to send email from either of the three email addresses I have.
The unfortunate thing is/possibly was, was that any mail sent from any of the email addresses I own had to be delivered by the tiscali SMTP server. Tiscali, in all their wisdom, seemed to decide that they would not send email from another domain if they received it from a client connected to their network ie I dial into them and am therefore allowed to send email from the email account they gave me but it seems not from another domain email address ie hylton@conacher.co.za.
Ah, yes, I understand. The funny thing is that dialup tiscali.es allows sending email with any address in the from field, with no authentication method, BUT! You have to be connected with an IP of theirs. On the other hand, if my IP belongs to another network, they do not allow me to send even if my from is @tiscali.es. Absurd.
I agree, totally absurd, especially since I dial up to them and authenticate on one of their dynamic IPs first before sending mail.
By the way, tiscali.es is out of business. They sold their customers et al to "Wanadoo" (France Telecom España S.A). Tiscali went out here about 6 montha ago and now the servers are owned by the MWEb ISP. They are, at teh moment, keeping the server names that Tiscali used but I am sure they will change to xxxx.mweb.co.za in a while.
On the other hand, teleline.es (my other dialup provider) requires you to authenticate, an will not allow you to send with any "from" except @teleline.es. sounds like my current provider. Can they still refuse to send your email if you are using your own SMTP server, albeiy on dialup?
I haven't yet learnt what my current provider does.
So, yes, I understand your problem. That's the main reason I use postfix to send directly. Sorry I need a bit of explanation here.
Do I understand correctly that once you have dialed in and authenticated that the Postfix server just uses the internet connection and actually not the ISP's SMTP server, other than as a SMTP relay?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-04-16 at 18:59 +0200, Hylton Conacher (ZR1HPC) wrote:
By the way, tiscali.es is out of business. They sold their customers et al to "Wanadoo" (France Telecom España S.A). Tiscali went out here about 6 montha ago and now the servers are owned by the MWEb ISP. They are, at teh moment, keeping the server names that Tiscali used but I am sure they will change to xxxx.mweb.co.za in a while.
¡Ha! So, it wasn't only Spain where they failed. Interesting. I'm not surprised... you can not be out of service for a full weekend, with even the help desk phone not working, and when it works, they know nothing. ...
Sorry I need a bit of explanation here.
Do I understand correctly that once you have dialed in and authenticated that the Postfix server just uses the internet connection and actually not the ISP's SMTP server, other than as a SMTP relay?
Ok, let's see. There are different methods. Many accounts provide a pop/imap box, plus an smtp server. With programs like mozilla you can configure each account separately, each with their different fetching and sending methods. On the other hand, good isps may, or should, provide and smtp server which you may use to send all your email, regardless to which account they belong. Consider: you may have your own domain name, but you do not have your own sending server, so you use the smtp server of the isp for that purpose. What can your postfix do? By default, postfix (or sendmail, or whatever) will send mail on its own, without the help of any other smtp server. Postfix is an smtp server, so it can send email to any destination by its own resources. What happens it you are on dial-up? Mainly, you do not have a fixed IP. Coupled to that, reverse dns will not work, or will not point to your name. Can you still send mail directly? Sure! well... not quite. Many recipient servers will frown on it and refuse receiving email from you, because many spammers have abused and used the direct send method to bypass controls. Fortunately, SuSE has not implemented that policy, not absolutely, at least. Your postfix can be told to use a relay server based on the destination (the "transport" table), for those cases that the recipient server refuse talking to you. Unfortunately, for us, it is not possible, or I don't know how, to select diferent relays based on the from addres, as we can do with Mozilla. That's the situation. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFERBn6tTMYHG2NR9URAhPwAKCFXyiuxrC2hRp6wo9ggV7LRL5hZwCfTh9D u9i74kd7F8wn/tZb2Dnut90= =YNo+ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-04-18 at 00:42 +0200, I wrote:
Your postfix can be told to use a relay server based on the destination (the "transport" table), for those cases that the recipient server refuse talking to you. Unfortunately, for us, it is not possible, or I don't know how, to select diferent relays based on the from addres, as we can do with Mozilla.
That's the situation.
I forgot one detail: postfix can be told how to atuthentificate to smtp servers, using the "sasl_passwd" file and some configuration changes. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFERBrbtTMYHG2NR9URAqPSAJ400QKTkmgjB3wot23qS4nourtaIQCfY9ys YD0E97fbgVKp3tSQ1g0nDmk= =H9mX -----END PGP SIGNATURE-----
THANKS Carlos, my reply/understanding is in-line. Carlos E. R. wrote:
The Sunday 2006-04-16 at 18:59 +0200, Hylton Conacher (ZR1HPC) wrote:
By the way, tiscali.es is out of business. They sold their customers et al to "Wanadoo" (France Telecom España S.A).
Tiscali went out here about 6 montha ago and now the servers are owned by the MWEb ISP. They are, at teh moment, keeping the server names that Tiscali used but I am sure they will change to xxxx.mweb.co.za in a while.
¡Ha! So, it wasn't only Spain where they failed. Interesting.
Sorry I need a bit of explanation here.
Do I understand correctly that once you have dialed in and authenticated that the Postfix server just uses the internet connection and actually not the ISP's SMTP server, other than as a SMTP relay?
Ok, let's see. There are different methods.
Many accounts provide a pop/imap box, plus an smtp server. With programs like mozilla you can configure each account separately, each with their different fetching and sending methods.
On the other hand, good isps may, or should, provide and smtp server which you may use to send all your email, regardless to which account they belong. Consider: you may have your own domain name, but you do not have your own sending server, so you use the smtp server of the isp for that purpose. Well I have a domain with another ISP and dial into Tiscali, just as the access is paid until Nov 2006 already, and I've been with the same ISP
Obviously they, in what ever country, did not care about their customers. thru 3 takeovers and since 1990.
What can your postfix do?
By default, postfix (or sendmail, or whatever) will send mail on its own, without the help of any other smtp server. Postfix is an smtp server, so it can send email to any destination by its own resources. OK, understood that Postfix is the MTA.
What happens it you are on dial-up? Mainly, you do not have a fixed IP. Coupled to that, reverse dns will not work, or will not point to your name. Can you still send mail directly? Sure! well... not quite. Many recipient servers will frown on it and refuse receiving email from you, because many spammers have abused and used the direct send method to bypass controls. Fortunately, SuSE has not implemented that policy, not absolutely, at least. It would seem that even setting up my own Postfix server at home would not help with all the SMTP mail authentication to prevent spammers.
Your postfix can be told to use a relay server based on the destination (the "transport" table), for those cases that the recipient server refuse talking to you. Unfortunately, for us, it is not possible, or I don't know how, to select diferent relays based on the from addres, as we can do with Mozilla. Such is life on dial-up :P
So in essence, provided an individual/company uses the ISP of their domain holder(ISP-1), they can use the ISP SMTP servers. If an individual/company wants to obtain a domain at another ISP(ISP-2) and dial into ISP-1 to send mail from the IAP2 domain, it is not 'allowed' to cut down on spam? There is something I am missing however :( Something about the authentication :( What hapens to folk who maintain their own SMTP servers(Postfix/Sendmail etc)? Are they still restricted in sending mail from another another domain(ISP-2) via a different ISP(ISP-1)? Let me illustrate with an example on how I understand the SMTP process: 1. Assume that I had a two domains registered, each with a different ISP. ISP-1 www.global.co.za ISP-2 www.conacher.co.za 2. I have a single Postfix SMTP server for both domains, but I cannot afford to keep it online 24/7 and so I have a dialup account with ISP-1. 3. On first dialup to ISP-1 my SMTP server authenticates and retrieves its dynamic IP from ISP-1. It first sends the outgoing email from both domains to the next closest SMTP server(ISP-1's SMTP server) and then receives email from POP mail stores at each domain. My SMTP server then disconects itself from ISP-1. 4. The mail received by ISP-1's SMTP server is marked as certified as ISP-1 was able to confirm that the sender was someone who they knew and who had dialed into the ISP-1 network. The message details from the message sender do not matter as they came from an authenticated source. If there is a problem with one of the messages sent then ISP-1 will be able to identify me as the sender and I could face legal action. 5. The mail leaves ISP-1 and is received by the next SMTP server. That SMTP server does not need to authentiacte the messages it has received from ISP-1 as they would only have been forwarded onto the net if they had been authenticated by the originating ISP. 6. The third SMTP server delivers the mail into the mail store of the recipient, sending back any return receipts requested. What am I missing in steps 3/4/5. Does each SMTP server need to authenticate the sender, why? Are dialup postfix SMTP servers an option or are they really just POP message stores? I am going to need to set-up a Postfix server closely resembling the above example and I wonder if it is possible and or if thre are caveats? Tnx again Carlos et al.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-04-20 at 13:08 +0200, Hylton Conacher (ZR1HPC) wrote:
THANKS Carlos, my reply/understanding is in-line.
As it should always be.
So in essence, provided an individual/company uses the ISP of their domain holder(ISP-1), they can use the ISP SMTP servers. If an individual/company wants to obtain a domain at another ISP(ISP-2) and dial into ISP-1 to send mail from the IAP2 domain, it is not 'allowed' to cut down on spam?
It depends on what rules the smtp server you want to use as relay server imposses on you. They can allow you, or not. Their choice.
There is something I am missing however :( Something about the authentication :(
What hapens to folk who maintain their own SMTP servers(Postfix/Sendmail etc)? Are they still restricted in sending mail from another another domain(ISP-2) via a different ISP(ISP-1)?
If your provider is a good one they will not impede you from using their smtp as a relay server for all your email regardless of the from address you use.
Let me illustrate with an example on how I understand the SMTP process:
1. Assume that I had a two domains registered, each with a different ISP. ISP-1 www.global.co.za ISP-2 www.conacher.co.za
2. I have a single Postfix SMTP server for both domains, but I cannot afford to keep it online 24/7 and so I have a dialup account with ISP-1.
3. On first dialup to ISP-1 my SMTP server authenticates and retrieves its dynamic IP from ISP-1.
Nonononono. You get your IP much earlier that that, via ppp negotiation when the modem connects.
It first sends the outgoing email from both domains to the next closest SMTP server(ISP-1's SMTP server) and then receives email from POP mail stores at each domain. My SMTP server then disconects itself from ISP-1.
It sends email to the server you have told it to send to. Distance or ownership has nothing to do. Nor has the smtp server got to connect or disconect after or before you receive mail from the pop server(s).
4. The mail received by ISP-1's SMTP server is marked as certified as ISP-1 was able to confirm that the sender was someone who they knew and who had dialed into the ISP-1 network. The message details from the message sender do not matter as they came from an authenticated source. If there is a problem with one of the messages sent then ISP-1 will be able to identify me as the sender and I could face legal action.
I'm sorry, but I do not understand a word of what you are saying. Please, study the subject in manuals and howtos available in the distro, then explain again. I already explained what you needed to know, but what you say doesn't make any sense. Or I'm thick headed today, sorry. Let me try again... when you send email by any method using any relay server you hired, because it belongs to your isp, that email can be traced back to you regardless of your from address, and regardless of the method you used to authenticate yourself to the isp or smtp server - provided everything is correctly configured at their end. This relay server will normally send all that email direct to the destination address, no intermediaries. The destination server can not do authentification, because the email is for him: he can not reject it, unless he thinks it is spam or virus or such. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFETAJgtTMYHG2NR9URAqKxAJ4hWtpcBmzvGQvl7w7DWAA0VM6vqwCcCp6p A8G0sZ+9Mcw5CaLFn23/XOU= =kaSp -----END PGP SIGNATURE-----
On Sunday, April 23, 2006 @ 5:40, Carlos Robinson wrote: The Thursday 2006-04-20 at 13:08 +0200, Hylton Conacher (ZR1HPC) wrote:
THANKS Carlos, my reply/understanding is in-line.
As it should always be.
So in essence, provided an individual/company uses the ISP of their domain holder(ISP-1), they can use the ISP SMTP servers. If an individual/company wants to obtain a domain at another ISP(ISP-2) and dial into ISP-1 to send mail from the IAP2 domain, it is not 'allowed' to cut down on spam?
It depends on what rules the smtp server you want to use as relay server imposes on you. They can allow you, or not. Their choice.
There is something I am missing however :( Something about the authentication :(
What hapens to folk who maintain their own SMTP servers(Postfix/Sendmail etc)? Are they still restricted in sending mail from another another domain(ISP-2) via a different ISP(ISP-1)?
If your provider is a good one they will not impede you from using their smtp as a relay server for all your email regardless of the from address you use.
Let me illustrate with an example on how I understand the SMTP process:
1. Assume that I had a two domains registered, each with a different ISP. ISP-1 www.global.co.za ISP-2 www.conacher.co.za
2. I have a single Postfix SMTP server for both domains, but I cannot afford to keep it online 24/7 and so I have a dialup account with ISP-1.
3. On first dialup to ISP-1 my SMTP server authenticates and retrieves its dynamic IP from ISP-1.
Nonononono. You get your IP much earlier that that, via ppp negotiation when the modem connects.
It first sends the outgoing email from both domains to the next closest SMTP server(ISP-1's SMTP server) and then receives email from POP mail stores at each domain. My SMTP server then disconects itself from ISP-1.
It sends email to the server you have told it to send to. Distance or ownership has nothing to do. Nor has the smtp server got to connect or disconect after or before you receive mail from the pop server(s).
4. The mail received by ISP-1's SMTP server is marked as certified as ISP-1 was able to confirm that the sender was someone who they knew and who had dialed into the ISP-1 network. The message details from the message sender do not matter as they came from an authenticated source. If there is a problem with one of the messages sent then ISP-1 will be able to identify me as the sender and I could face legal action.
I'm sorry, but I do not understand a word of what you are saying. Please, study the subject in manuals and howtos available in the distro, then explain again.
I already explained what you needed to know, but what you say doesn't make any sense. Or I'm thick headed today, sorry.
Let me try again... when you send email by any method using any relay server you hired, because it belongs to your isp, that email can be traced back to you regardless of your from address, and regardless of the method you used to authenticate yourself to the isp or smtp server - provided everything is correctly configured at their end.
This relay server will normally send all that email direct to the destination address, no intermediaries. The destination server can not do authentification, because the email is for him: he can not reject it, unless he thinks it is spam or virus or such.
- -- Cheers, Carlos Robinson
Hylton: The key here is that it's the SMTP server that you use that imposes the restriction. You can use any SMTP server that you have subscribed to without having any problem with your ISP. I am using a 3rd party Mail product and am not using my ISP's SMTP server. This should always be allowed. Now if I were to log into a different ISP and try to use my ISP's SMTP server, they might reject my mail. It depends on the policy of that ISP. I used to live in Alaska and had 2 ISP's at one point. One of them let me use it's SMTP server from the other, but not vice versa. I. e., one of the ISP's had a more restrictive policy. Maybe you understood this already, but I got the feeling maybe you didn't. Greg Wallace
Greg Wallace wrote:
On Sunday, April 23, 2006 @ 5:40, Carlos Robinson wrote: The Thursday 2006-04-20 at 13:08 +0200, Hylton Conacher (ZR1HPC) wrote:
<very BIG snip>
Hylton: The key here is that it's the SMTP server that you use that imposes the restriction. You can use any SMTP server that you have subscribed to without having any problem with your ISP. I am using a 3rd party Mail product and am not using my ISP's SMTP server. This should always be allowed. Now if I were to log into a different ISP and try to use my ISP's SMTP server, they might reject my mail. It depends on the policy of that ISP. I used to live in Alaska and had 2 ISP's at one point. One of them let me use it's SMTP server from the other, but not vice versa. I. e., one of the ISP's had a more restrictive policy. Maybe you understood this already, but I got the feeling maybe you didn't.
Tnx Greg, I hadn't before realized that ISP's can place restrictions on the SMTP servers as I figured it just transported the mail between nodes. I now know that this is not so and that my own ISP is a restrictive one. As I said to Carlos earlier, time to change ISP's
* Hylton Conacher (ZR1HPC) <hylton@global.co.za> [04-25-06 14:39]:
I hadn't before realized that ISP's can place restrictions on the SMTP servers as I figured it just transported the mail between nodes.
I now know that this is not so and that my own ISP is a restrictive one.
As I said to Carlos earlier, time to change ISP's
The *simple* choice would be to route mail with gmail account names via gmail's free smtp service. Your provider has *no* say in this transaction. (point: If I haven't lost track of your original intentions) -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
Carlos E. R. wrote:
The Thursday 2006-04-20 at 13:08 +0200, Hylton Conacher (ZR1HPC) wrote:
So in essence, provided an individual/company uses the ISP of their domain holder(ISP-1), they can use the ISP SMTP servers. If an individual/company wants to obtain a domain at another ISP(ISP-2) and dial into ISP-1 to send mail from the IAP2 domain, it is not 'allowed' to cut down on spam?
It depends on what rules the smtp server you want to use as relay server imposses on you. They can allow you, or not. Their choice.
Their choice has so far been to deny my use of the SMTP server for my domain mail.
There is something I am missing however :( Something about the authentication :(
What hapens to folk who maintain their own SMTP servers(Postfix/Sendmail etc)? Are they still restricted in sending mail from another another domain(ISP-2) via a different ISP(ISP-1)?
If your provider is a good one they will not impede you from using their smtp as a relay server for all your email regardless of the from address you use. From investigation my ISP SMTP server does not allow relays of mail from anoter domain other than the ones tey own.
Let me illustrate with an example on how I understand the SMTP process:
1. Assume that I had a two domains registered, each with a different ISP. ISP-1 www.global.co.za ISP-2 www.conacher.co.za
2. I have a single Postfix SMTP server for both domains, but I cannot afford to keep it online 24/7 and so I have a dialup account with ISP-1.
3. On first dialup to ISP-1 my SMTP server authenticates and retrieves its dynamic IP from ISP-1.
Nonononono. You get your IP much earlier that that, via ppp negotiation when the modem connects. As I said when I first connect ie dialup.
It sends email to the server you have told it to send to. Distance or ownership has nothing to do. Nor has the smtp server got to connect or disconect after or before you receive mail from the pop server(s). So basically the server I enter as the Mozilla SMTP server receives the mail from me and sends it to the destination or next relay before the destination, no questions asked?
4. The mail received by ISP-1's SMTP server is marked as certified as ISP-1 was able to confirm that the sender was someone who they knew and who had dialed into the ISP-1 network. The message details from the message sender do not matter as they came from an authenticated source. If there is a problem with one of the messages sent then ISP-1 will be able to identify me as the sender and I could face legal action.
I'm sorry, but I do not understand a word of what you are saying. Please, study the subject in manuals and howtos available in the distro, then explain again. I'll browse the manuals but in essence 4. was dealing with authentication ie if mail is received by any SMTP server, is authentication done to ensure the mail came from an email on the registered domain.
I already explained what you needed to know, but what you say doesn't make any sense. Or I'm thick headed today, sorry. I appreciate your assistance Carlos and I would rather be labelled the thick headed one in this discussion, as you are by no means, with the explanations given, the thick headed one. Perhaps I am not explaining it right or you are not understanding my explanations as I think you should. No fault of yours.
Let me try again... when you send email by any method using any relay server you hired, because it belongs to your isp, that email can be traced back to you regardless of your from address, and regardless of the method you used to authenticate yourself to the isp or smtp server - provided everything is correctly configured at their end.
This relay server will normally send all that email direct to the destination address, no intermediaries. The destination server can not do authentification, because the email is for him: he can not reject it, unless he thinks it is spam or virus or such. AAAAHHHH Right, my thick headedness has cleared considerably! :) I thought there were intermediaries as if a link to a country goes down then the packet would need to be routed to on another path via an intermediary host.
I thought the intermediary and destination server did authentication to cut back on SPAM. OK, what I have managed to so far partly confirm is that my ISP is currently doing authentication on email the SMTP server receives from the ISPs users and thus they are prohibiting me from sending email from my own domain that is not held/registered by them, eventhough I hold a dialup and different email account with them. Time to move ISP's
Hylton Conacher (ZR1HPC) wrote:
Let me try again... when you send email by any method using any relay server you hired, because it belongs to your isp, that email can be traced back to you regardless of your from address, and regardless of the method you used to authenticate yourself to the isp or smtp server - provided everything is correctly configured at their end.
This relay server will normally send all that email direct to the destination address, no intermediaries. The destination server can not do authentification, because the email is for him: he can not reject it, unless he thinks it is spam or virus or such. AAAAHHHH Right, my thick headedness has cleared considerably! :) I thought there were intermediaries as if a link to a country goes down then the packet would need to be routed to on another path via an intermediary host.
I thought the intermediary and destination server did authentication to cut back on SPAM.
OK, what I have managed to so far partly confirm is that my ISP is currently doing authentication on email the SMTP server receives from the ISPs users and thus they are prohibiting me from sending email from my own domain that is not held/registered by them, eventhough I hold a dialup and different email account with them.
If you don't know what kind of restriction have been placed on the mailserver of your provider it is normally the easiest way to simply ask the provider what restrictions have been set. Of course, the person you are getting on the other end of the line might not be much wiser than you (happened to me). The other method is to simply test it. Usually, when you try to send an email and the mailserver is refusing to accept the mail you get a reject code and error message. Normally this is enough to understand why the server refused the message. Postfix can of course use authentication when sending mails to the relayserver. It depends on the receiving relayhost if it is configured to only allow the sender address that you used to authenticate with to the relayserver. Most relayservers are configured to require authentication when you want the relayserver to accept a message and have it relayed to the internet. Again, the error message should appear either when sending in mozilla or in the log of your local mailserver when you try to send a mail to the relayserver. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic wrote:
Hylton Conacher (ZR1HPC) wrote:
<snip> Thanks for adding a comment Sandy.
If you don't know what kind of restriction have been placed on the mailserver of your provider it is normally the easiest way to simply ask the provider what restrictions have been set. Of course, the person you are getting on the other end of the line might not be much wiser than you (happened to me). And me, especially since most of the call centre folk are Windows junkies ie asking me what I use to scan for viruses on Linux and my favourite 'Go to Start.....'. I sometimes just for fun say I casn't see it and my 'Start' button has disappeared :)) Wicked I know but the staf need to know Windows is not the only OS they are having connect to their network.
I have phoned them on 5 different occassions to get two totally different answers to the same question about which SMTP server to use. When this happens I know I am smarter and decide to try and figure it out myself.
The other method is to simply test it. Usually, when you try to send an email and the mailserver is refusing to accept the mail you get a reject code and error message. Normally this is enough to understand why the server refused the message. Well after some testing, the reason the mail is not getting through is because the ISP do authentication to confirm the email sender is the same as the person dialed into their network.
Postfix can of course use authentication when sending mails to the relayserver. It depends on the receiving relayhost if it is configured to only allow the sender address that you used to authenticate with to the relayserver. Most relayservers are configured to require authentication when you want the relayserver to accept a message and have it relayed to the internet. Again, the error message should appear either when sending in mozilla or in the log of your local mailserver when you try to send a mail to the relayserver. That's just it, there was no error message but the messages I sent didn't get through and in some cases two copies were placed in my sent items.
I have decided to change ISP's but due to financial constraints can only do so in September/October.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-04-25 at 12:18 +0200, Hylton Conacher (ZR1HPC) wrote: ...
It sends email to the server you have told it to send to. Distance or ownership has nothing to do. Nor has the smtp server got to connect or disconect after or before you receive mail from the pop server(s). So basically the server I enter as the Mozilla SMTP server receives the mail from me and sends it to the destination or next relay before the destination, no questions asked?
The first SMTP sever may ask questions, of course. Any SMTP server in the chain, except the one of the destination address may ask for authentication of some sort; ie, your ISP SMTP server may ask for it, because it will _relay_ your mail to somebody else. Also, if to tell Mozilla to send the email you write on the gmail account through gmail smtp server (bypassing your ISP smtp server), this will also request some ID. It would be rare that the second server asked for ID, but it could happen: for instance, in a private network users send to a certain local SMTP server. This one sends to another one on their ISP, who request auth from the private server (but not from the user: that is impossible). The method used for authentication varies. An ISP can simply validate by the IP number you use. Or, it can also see that you retrieved email from them, say, three minutes ago from this IP (POP before SMTP). Or it can ask for a login/password pair. In other words: SMTP servers that relay email to some other smtp server should normally use some kind of authentications. Those servers of the destination address will not. Another clarification: The minimum is two smtp servers in the chain. One gets the email from you, the other one receives it for the addressee. Depending on the setup, there can be intermediaries on both sides. Each one normally adds a "Received" header to the email, and you can read them (try: it is instructive).
This relay server will normally send all that email direct to the destination address, no intermediaries. The destination server can not do authentification, because the email is for him: he can not reject it, unless he thinks it is spam or virus or such. AAAAHHHH Right, my thick headedness has cleared considerably! :) I thought there were intermediaries as if a link to a country goes down then the packet would need to be routed to on another path via an intermediary host.
No, intermediaries happens in complex setups for reasons different that distance. But there might be none at all.
I thought the intermediary and destination server did authentication to cut back on SPAM.
No, they do other kinds of tests, but they can not ask a login/password from you, they doesn't "see" you.
OK, what I have managed to so far partly confirm is that my ISP is currently doing authentication on email the SMTP server receives from the ISPs users and thus they are prohibiting me from sending email from my own domain that is not held/registered by them, eventhough I hold a dialup and different email account with them.
Right! :-)
Time to move ISP's
There are more than one way. That's not the only possibility. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFETrWltTMYHG2NR9URAlPSAJ4hINXFdmFfnSC32k0aIQNJpinyDQCdEErG +jOz6becEKt2eOmlZ7NgxvM= =ko4A -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Tuesday 2006-04-25 at 12:18 +0200, Hylton Conacher (ZR1HPC) wrote:
...
It sends email to the server you have told it to send to. Distance or ownership has nothing to do. Nor has the smtp server got to connect or disconect after or before you receive mail from the pop server(s).
So basically the server I enter as the Mozilla SMTP server receives the mail from me and sends it to the destination or next relay before the destination, no questions asked?
The first SMTP sever may ask questions, of course. Any SMTP server in the chain, except the one of the destination address may ask for authentication of some sort; ie, your ISP SMTP server may ask for it, because it will _relay_ your mail to somebody else......
OK, understood. What tyoe of authentication could a SMTP server say 3 down the line ask for? Would its request be answered by the second SMTP server or would SMTP-3 try and contact the original dialup server which may not be currently connected? Time to visit an inet cafe and Google SMTP authentication methods.
...........Also, if to tell Mozilla to send the email you write on the gmail account through gmail smtp server (bypassing your ISP smtp server), this will also request some ID. Well when I tried sending mail using the GMail SMTP it didn't seem to work, although tat could have been due to user education. As it didn't go through I figured that it probably needed an ID on me ie I needed to log on first or send from my GMail account. I cannot stay connected whilst I read + reply to SLE mesages.
Given that I like to/have to read my email offline is there a way to use teh GMail SMTP server to send email that does not originate from a GMail address? If someone has some info or a tutorial, I'd be most interested.
It would be rare that the second server asked for ID, but it could happen: for instance, in a private network users send to a certain local SMTP server. This one sends to another one on their ISP, who request auth from the private server (but not from the user: that is impossible). Right, so if I understand correctly, having my own local SMTP server might not alleiate the problems I am experiencing now as again the email FROM header is different to te dialup connection account, and they would have to be the same for the ISP SMTP server to accept it OR As the ISP SMTP server is receiving mail from another SMTP server(my local one) will it not authenticate each email sent on te above criteria but do it another way?
The method used for authentication varies. An ISP can simply validate by the IP number you use. Or, it can also see that you retrieved email from them, say, three minutes ago from this IP (POP before SMTP). Or it can ask for a login/password pair. Are these methods also used if the sender is a SMTP server or are different criteria used? ie see above just below OR.
In other words: SMTP servers that relay email to some other smtp server should normally use some kind of authentications. Those servers of the destination address will not. OK understood that any of the SMTP servers can request authentication, except the destination SMTP server.
Another clarification: The minimum is two smtp servers in the chain. One gets the email from you, the other one receives it for the addressee. Depending on the setup, there can be intermediaries on both sides. Each one normally adds a "Received" header to the email, and you can read them (try: it is instructive). mmm, I've seen email headers and understand this. What i didn't know was that there are normally only a maximum of 2 SMTP servers ie sender and receiver.
This relay server will normally send all that email direct to the destination address, no intermediaries. The destination server can not do authentification, because the email is for him: he can not reject it, unless he thinks it is spam or virus or such.
AAAAHHHH Right, my thick headedness has cleared considerably! :) I thought there were intermediaries as if a link to a country goes down then the packet would need to be routed to on another path via an intermediary host.
No, intermediaries happens in complex setups for reasons different that distance. But there might be none at all. OK
I thought the intermediary and destination server did authentication to cut back on SPAM.
No, they do other kinds of tests, but they can not ask a login/password from you, they doesn't "see" you. OK, so , assuming a mail has to take the long path to get to the email destination and therefore goes from local SMTP to ISP SMTP to intermediary SMTP to destination SMTP and that the intermediary SMTP needs authentication. However because it cannot see my local server, due to it having dropped its dialup connection or whatever, it does other tests to obtain authentication.
OK, what I have managed to so far partly confirm is that my ISP is currently doing authentication on email the SMTP server receives from the ISPs users and thus they are prohibiting me from sending email from my own domain that is not held/registered by them, eventhough I hold a dialup and different email account with them.
Right! :-) Can this type of authentication be got around or changed ie what other types could I request them to rather ask me for to authenticate?
Time to move ISP's
There are more than one way. That's not the only possibility. Well given what I need and what is being offered by them, and of course how they manage the network, and my knowledge and all, changing ISP's is the next easiest choice.
If you can see a way around the authentication the ISP is doing, I'd be very interested to know.
On Thursday, April 27, 2006 @ 9:33 AM, Hylton Conacher wrote:
Carlos E. R. wrote:
The Tuesday 2006-04-25 at 12:18 +0200, Hylton Conacher (ZR1HPC) wrote:
...
It sends email to the server you have told it to send to. Distance or ownership has nothing to do. Nor has the smtp server got to connect or disconect after or before you receive mail from the pop server(s).
So basically the server I enter as the Mozilla SMTP server receives the
from me and sends it to the destination or next relay before the destination, no questions asked?
The first SMTP sever may ask questions, of course. Any SMTP server in the
chain, except the one of the destination address may ask for authentication of some sort; ie, your ISP SMTP server may ask for it, because it will _relay_ your mail to somebody else...... OK, understood. What tyoe of authentication could a SMTP server say 3 down the line ask for? Would its request be answered by the second SMTP server or would SMTP-3 try and contact the original dialup server which may not be currently connected?
Time to visit an inet cafe and Google SMTP authentication methods.
...........Also, if to tell Mozilla to send the email you write on the gmail account through gmail smtp server (bypassing your ISP smtp server), this will also request some
ID. Well when I tried sending mail using the GMail SMTP it didn't seem to work, although tat could have been due to user education. As it didn't go through I figured that it probably needed an ID on me ie I needed to log on first or send from my GMail account. I cannot stay connected whilst I read + reply to SLE mesages.
Given that I like to/have to read my email offline is there a way to use teh GMail SMTP server to send email that does not originate from a GMail address? If someone has some info or a tutorial, I'd be most interested.
It would be rare that the second server asked for ID, but it could happen: for instance, in a private network users send to a certain local SMTP server. This one sends to another one on their ISP, who request auth from
the private server (but not from the user: that is impossible). Right, so if I understand correctly, having my own local SMTP server might not alleiate the problems I am experiencing now as again the email FROM header is different to te dialup connection account, and they would have to be the same for the ISP SMTP server to accept it OR As the ISP SMTP server is receiving mail from another SMTP server(my local one) will it not authenticate each email sent on te above criteria but do it another way?
The method used for authentication varies. An ISP can simply validate by the IP number you use. Or, it can also see that you retrieved email from them, say, three minutes ago from this IP (POP before SMTP). Or it can ask for a login/password pair. Are these methods also used if the sender is a SMTP server or are different criteria used? ie see above just below OR.
In other words: SMTP servers that relay email to some other smtp server should normally use some kind of authentications. Those servers of the destination address will not. OK understood that any of the SMTP servers can request authentication, except the destination SMTP server.
Another clarification: The minimum is two smtp servers in the chain. One gets the email from you, the other one receives it for the addressee. Depending on the setup, there can be intermediaries on both sides. Each one normally adds a "Received" header to the email, and you can read them
(try: it is instructive). mmm, I've seen email headers and understand this. What i didn't know was that there are normally only a maximum of 2 SMTP servers ie sender and receiver.
This relay server will normally send all that email direct to the destination address, no intermediaries. The destination server can not do authentification, because the email is for him: he can not reject it, unless he thinks it is spam or virus or such.
AAAAHHHH Right, my thick headedness has cleared considerably! :) I thought there were intermediaries as if a link to a country goes down then the packet would need to be routed to on another path via an intermediary host.
No, intermediaries happens in complex setups for reasons different that distance. But there might be none at all. OK
I thought the intermediary and destination server did authentication to cut back on SPAM.
No, they do other kinds of tests, but they can not ask a login/password from you, they doesn't "see" you. OK, so , assuming a mail has to take the long path to get to the email destination and therefore goes from local SMTP to ISP SMTP to intermediary SMTP to destination SMTP and that the intermediary SMTP needs authentication. However because it cannot see my local server, due to it having dropped its dialup connection or whatever, it does other tests to obtain authentication.
If you send mail to a 3rd party SMTP while logged into your local ISP, your local ISP SMTP server doesn't even get involved. Maybe I'm misreading your above paragraph, but it sounds like you might be thinking it does get involved.
OK, what I have managed to so far partly confirm is that my ISP is currently doing authentication on email the SMTP server receives from the ISPs users and thus they are prohibiting me from sending email from my own domain that is not held/registered by them, eventhough I hold a dialup and different email account with them.
Right! :-) Can this type of authentication be got around or changed ie what other types could I request them to rather ask me for to authenticate?
Time to move ISP's
There are more than one way. That's not the only possibility. Well given what I need and what is being offered by them, and of course how they manage the network, and my knowledge and all, changing ISP's is the next easiest choice.
If you can see a way around the authentication the ISP is doing, I'd be very interested to know.
Greg Wallace
Greg Wallace wrote:
On Thursday, April 27, 2006 @ 9:33 AM, Hylton Conacher wrote:
<snip>
OK, so , assuming a mail has to take the long path to get to the email destination and therefore goes from local SMTP to ISP SMTP to intermediary SMTP to destination SMTP and that the intermediary SMTP needs authentication. However because it cannot see my local server, due to it having dropped its dialup connection or whatever, it does other tests to obtain authentication.
If you send mail to a 3rd party SMTP while logged into your local ISP, your local ISP SMTP server doesn't even get involved. Maybe I'm misreading your above paragraph, but it sounds like you might be thinking it does get involved. Sorry Greg, a slight mis-read/misunderstanding on your/my side. As I understand an SMTP server must send its load to another SMTP server. To clarify let us assume there are only 3 SMTP servers in the world ie my local one, my ISP's one, the destination one.
Me-- |A|----------Broken link--------------|B| \ / \---------Link OK-------|C|--------/ Me=My Mozilla-mail on my local machine A= My local SMTP server B= Destination SMTP server C=My ISP SMTP server acting as relay between A and B Let us assume that A cannot see the destination B. It determines that the alternate path to B is via C. The destination (B) does not need to authenticate the messages it receives however C does. So while my local SMTP server is connected and sending mail to C, C does authentication and sees that the FROM header in some of the emails is not the same as the email address as the person logged onto the ISP. C therefore drops those messages into the forever ether. The messages whose FROM header is the same as the person dialed in are relayed to the destination server (B). Can the above happen to a local SMTP server (A) as it has been happening to Me when I sent email directly from my Mozilla Mail to C. If the FROM header in some of the emails is not the same as the email address as the person logged onto the ISP. C therefore drops those messages into the forever ether. The messages whose FROM header is the same as the person dialed in are relayed to the destination server (B). <snip> I hope the above better explains my concerns.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-04-29 at 13:19 +0200, Hylton Conacher (ZR1HPC) wrote:
understand an SMTP server must send its load to another SMTP server. To clarify let us assume there are only 3 SMTP servers in the world ie my local one, my ISP's one, the destination one.
Me-- |A|----------Broken link--------------|B| \ / \---------Link OK-------|C|--------/
[A] Mozilla ----- local----\---------------------- Destination [B] \ postfix \ / SMTP \ \ [C] / -------------------ISP ---------/ SMTP Those are the possibilities.
Let us assume that A cannot see the destination B. It determines that the alternate path to B is via C.
It's rather that you tell it to do it that way; it doesn't do it automatically. The route is decided looking at its configuration and the answers from the DNS.
The destination (B) does not need to authenticate the messages it receives
It doesn't because it is the SMTP server responsible to receive email for the domain in the "To" field. Ie, it is not a relay, but the final destination.
however C does. So while my local SMTP server is connected and sending mail to C, C does authentication and sees that the FROM header in some of the emails is not the same as the email address as the person logged onto the ISP. C therefore drops those messages into the forever ether. The messages whose FROM header is the same as the person dialed in are relayed to the destination server (B).
Well, that's because the person administering that crappy server has decided to do it that way, IMO. I know it happens. It should, however, never "drop" mail, but "reject" mail. That's very irresponsible on their part.
Can the above happen to a local SMTP server (A) as it has been happening to Me when I sent email directly from my Mozilla Mail to C. If the FROM header in some of the emails is not the same as the email address as the person logged onto the ISP. C therefore drops those messages into the forever ether. The messages whose FROM header is the same as the person dialed in are relayed to the destination server (B).
I prefer to send through (A) because that way I see the logs, and reading them I know what is happening. If I get a rejection, I know it, not a box popping up from mozilla telling me of a error in transmission. I get more control. However, you can tell (A) to send directly to (B). That's what I normally do. It works with SuSE lists, but it doesn't with some other recipients: they check that (A) is on a dynamic address and refuse talking. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEVJFitTMYHG2NR9URAt6aAJ0SL0h0y0upbe4WxyqrCHjun8ZtsQCeNrNw 8wo+FURX01WhlDlDX33E+pI= =ZSFF -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Saturday 2006-04-29 at 13:19 +0200, Hylton Conacher (ZR1HPC) wrote:
understand an SMTP server must send its load to another SMTP server. To clarify let us assume there are only 3 SMTP servers in the world ie my local one, my ISP's one, the destination one.
Me-- |A|----------Broken link--------------|B| \ / \---------Link OK-------|C|--------/
[A] Mozilla ----- local----\---------------------- Destination [B] \ postfix \ / SMTP \ \ [C] / -------------------ISP ---------/ SMTP
Those are the possibilities.
Thanks for the ASCII correction. :)
Let us assume that A cannot see the destination B. It determines that the alternate path to B is via C.
It's rather that you tell it to do it that way; it doesn't do it automatically. The route is decided looking at its configuration and the answers from the DNS. OK, Would this be more correct? I tell (A) to send directly to (C). If it cannot resolve (B) it should use (C) as a relay.
The destination (B) does not need to authenticate the messages it receives
It doesn't because it is the SMTP server responsible to receive email for the domain in the "To" field. Ie, it is not a relay, but the final destination. Understood, although I initially understood, albeit correctly, that the final receiving SMTP server would not do authentication.
however C does. So while my local SMTP server is connected and sending mail to C, C does authentication and sees that the FROM header in some of the emails is not the same as the email address as the person logged onto the ISP. C therefore drops those messages into the forever ether. The messages whose FROM header is the same as the person dialed in are relayed to the destination server (B).
Well, that's because the person administering that crappy server has decided to do it that way, IMO. I know it happens.
It should, however, never "drop" mail, but "reject" mail. That's very irresponsible on their part. Sorry, wrong explanation on my part. Courtesy of Sandy I understand that the ISP SMTP(C) server would authenticate with (A) but not in the way I had initially described. It would use username/password of its own ie the email FROM header and the username to authenitcate would be different. Therefore the mail would actually get thru. I hope I understand correctly Sandy.
I'll have to remember to REJECT mail and not DROP it when I setup Postfix on this side. <snip>
I prefer to send through (A) because that way I see the logs, and reading them I know what is happening. If I get a rejection, I know it, not a box popping up from mozilla telling me of a error in transmission. I get more control. I agree, although right now I am getting the thoughts in order so that I may strive to set up my own (A) server.
However, you can tell (A) to send directly to (B). That's what I normally do. It works with SuSE lists, but it doesn't with some other recipients: they check that (A) is on a dynamic address and refuse talking. OK, so how do I ensure all the mail gets thru? With the dialup dynamic IP, some people/lists will not receive email from me. To get around that could I state in my config that the mail must always be delivered to my ISP and therefore use the ISP mailserver on a permanent IP as a relay?
a message not getting thru is against the very nature of TCP/IP. How can I ensure te messages always get through, without having to put a read receipt on each?
On Saturday, April 29, 2006 @ 6:20 AM, Hylton Conacher wrote:
Greg Wallace wrote:
On Thursday, April 27, 2006 @ 9:33 AM, Hylton Conacher wrote:
<snip>
OK, so , assuming a mail has to take the long path to get to the email destination and therefore goes from local SMTP to ISP SMTP to intermediary SMTP to destination SMTP and that the intermediary SMTP needs authentication. However because it cannot see my local server, due to it having dropped its dialup connection or whatever, it does other tests to obtain authentication.
If you send mail to a 3rd party SMTP while logged into your local ISP, your local ISP SMTP server doesn't even get involved. Maybe I'm misreading your above paragraph, but it sounds like you might be thinking it does get involved. Sorry Greg, a slight mis-read/misunderstanding on your/my side. As I understand an SMTP server must send its load to another SMTP server. To clarify let us assume there are only 3 SMTP servers in the world ie my local one, my ISP's one, the destination one.
Me-- |A|----------Broken link--------------|B| \ / \---------Link OK-------|C|--------/
Me=My Mozilla-mail on my local machine A= My local SMTP server B= Destination SMTP server C=My ISP SMTP server acting as relay between A and B
Let us assume that A cannot see the destination B. It determines that the alternate path to B is via C.
The destination (B) does not need to authenticate the messages it receives however C does. So while my local SMTP server is connected and sending mail to C, C does authentication and sees that the FROM header in some of the emails is not the same as the email address as the person logged onto the ISP. C therefore drops those messages into the forever ether. The messages whose FROM header is the same as the person dialed in are relayed to the destination server (B).
Can the above happen to a local SMTP server (A) as it has been happening to Me when I sent email directly from my Mozilla Mail to C. If the FROM header in some of the emails is not the same as the email address as the person logged onto the ISP. C therefore drops those messages into the forever ether. The messages whose FROM header is the same as the person dialed in are relayed to the destination server (B).
<snip>
I hope the above better explains my concerns.
Hylton: In my case, I use a 3rd party SMTP server, not my ISP's. That being the case, the fist SMTP server to get involved with my email is this 3rd party SMTP. There is no SMTP server before that. From your description, it sounds like you have an SMTP server on your machine as well. If I use my ISP SMTP server, that would be the first SMTP server that I hit. So, I either use the 3rd party SMTP server or my ISP's SMTP server. There is no SMTP server involved in the transmission to that point. Now after it leaves that SMTP server and heads to the destination server, I take it that there can be relays in between involving additional SMTP servers, at least that's how I understand it. Greg Wallace
Greg Wallace wrote:
On Thursday, April 27, 2006 @ 9:33 AM, Hylton Conacher wrote:
<snip>
In my case, I use a 3rd party SMTP server, not my ISP's. That being the case, the fist SMTP server to get involved with my email is this 3rd party SMTP. There is no SMTP server before that. From your description, it sounds like you have an SMTP server on your machine as well. If I use my ISP SMTP server, that would be the first SMTP server that I hit. So, I either use the 3rd party SMTP server or my ISP's SMTP server. There is no SMTP server involved in the transmission to that point. Now after it leaves that SMTP server and heads to the destination server, I take it that there can be relays in between involving additional SMTP servers, at least that's how I understand it. I do not have a local SMTP serer yet...but watch this space :)
That explanation was better and also how I understand things. Tnx for clarifying.
Hylton Conacher (ZR1HPC) wrote:
Carlos E. R. wrote:
The first SMTP sever may ask questions, of course. Any SMTP server in the chain, except the one of the destination address may ask for authentication of some sort; ie, your ISP SMTP server may ask for it, because it will _relay_ your mail to somebody else......
OK, understood. What tyoe of authentication could a SMTP server say 3 down the line ask for? Would its request be answered by the second SMTP server or would SMTP-3 try and contact the original dialup server which may not be currently connected?
Authentication, when it is required, will alway happen between the server that currently has the mail and the server that is contacted to receive the mail. Let's just use an example how a mail will progress when you send it off at your company: Your mailclient is configured to send all mails to the mailserver of the department/company. Your mailclient uses your username/password to authenticate to the company mailserver. Now the company mailserver does not have the right to send the mail directly to the internet. Only the mailgateway is allowed by the firewall to send directly to the internet. So the company mailserver sends the mail to the mailgateway. In order to prevent other clients in the company from sending directly to the mailgateway, the mailgateway also is configured to require authentication to relay mails. So the company mailserver authenticates itself to the mailgateway using his own user/password or maybe a client certificate. This authentication has nothing to do with how you authenticate to the company mailserver. The mailgateway could be configured to send the mail either to the ISP mailserver or directly to the next mailserver that is responsible for the recipients domain. When it uses the ISP mailserver as relay it might have to authenticate again with an independent user/pass to authenticate itself (the mailgateway) to the ISP mailserver. How many hops the mail has to pass within the recipients internal network is another question. There could also be several mailservers involved which might ask for authentication. I admit this is going a bit overboard with the authentication but it could happen nevertheless.
Time to visit an inet cafe and Google SMTP authentication methods.
...........Also, if to tell Mozilla to send the email you write on the gmail account through gmail smtp server (bypassing your ISP smtp server), this will also request some ID.
It would be rare that the second server asked for ID, but it could happen: for instance, in a private network users send to a certain local SMTP server. This one sends to another one on their ISP, who request auth from the private server (but not from the user: that is impossible). Right, so if I understand correctly, having my own local SMTP server might not alleiate the problems I am experiencing now as again the email FROM header is different to te dialup connection account, and they would have to be the same for the ISP SMTP server to accept it OR As the ISP SMTP server is receiving mail from another SMTP server(my local one) will it not authenticate each email sent on te above criteria but do it another way?
I don't know what you are trying to say. (^-^) The easiest way to test it is to set up several mail accounts in your mailclient and configure each account to send with the same user/pass to your ISP mailserver. Are they all accepted or is the ISP mailserver refusing some sender addresses?
The method used for authentication varies. An ISP can simply validate by the IP number you use. Or, it can also see that you retrieved email from them, say, three minutes ago from this IP (POP before SMTP). Or it can ask for a login/password pair.
Are these methods also used if the sender is a SMTP server or are different criteria used? ie see above just below OR.
Which restrictions are used mostly depends on what kind of recipient address the email has. I'll give you a Postfix example: Your server has the following configuration: mydestination = example.org mynetworks = 192.168.1.0/24 smptd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, permit Now, a client in your internal network with the ip 192.168.1.15 connects to your server and wishes to send an email to user@otherdomain.org. Postfix examines the restrictions and evaluates one restriction check after another if a check is returning a value of either "OK, PERMIT" or "REJECT". The first check in smtpd_recipient_restriction is "permit_mynetworks". It checks, if the connecting client is in the same network as has been defined in mynetworks. In this case, the client is indeed within the network 192.168.1.0/24, so the check returns "OK" and the mail is accepted. No other checks need to be evaluated. Next, a client with the ip address 80.242.23.16 connects from the internet to your server and wants to send an email to unknown@somewhere-else.org. Postfix first checks again "permit_mynetworks". This time the check comes up empty because the client ip is NOT in mynetworks. So Postfix tries the next check: permit_sasl_authenticated. Well, the client did not authenticate, so this check also returns an empty result. The next check, "reject_unauth_destination" evaluates if the recipient address is in a domain that Postfix is responsible for, otherwise it returns "REJECT" as result. In this case, the domain somewhere-else.org is not in mydestination, so the check returns "REJECT" and the mail is rejected. What kind of restriction checks are configured for a mailserver is completely up to you and your requirements.
In other words: SMTP servers that relay email to some other smtp server should normally use some kind of authentications. Those servers of the destination address will not. OK understood that any of the SMTP servers can request authentication, except the destination SMTP server.
Another clarification: The minimum is two smtp servers in the chain. One gets the email from you, the other one receives it for the addressee. Depending on the setup, there can be intermediaries on both sides. Each one normally adds a "Received" header to the email, and you can read them (try: it is instructive).
mmm, I've seen email headers and understand this. What i didn't know was that there are normally only a maximum of 2 SMTP servers ie sender and receiver.
Normally there is a minimum of two servers. Though here's an example where only one server is involved: Your mailclient is sending to the isp mailserver, The recipient's maildomain is also hosted on that server, so the server directly delivers the mail to the mailbox of the recipient, end of story. (^-^) If the recipient's maildomain is not hosted on the server that you used to send your mail to, then the mail will have to be send at least to another server. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
On Thu, 2006-04-27 at 22:36 +0200, Sandy Drobic wrote:
Hylton Conacher (ZR1HPC) wrote:
Carlos E. R. wrote:
The first SMTP sever may ask questions, of course. Any SMTP server in the chain, except the one of the destination address may ask for authentication of some sort; ie, your ISP SMTP server may ask for it, because it will _relay_ your mail to somebody else......
OK, understood. What tyoe of authentication could a SMTP server say 3 down the line ask for? Would its request be answered by the second SMTP server or would SMTP-3 try and contact the original dialup server which may not be currently connected?
Authentication, when it is required, will alway happen between the server that currently has the mail and the server that is contacted to receive the mail.
There's still the question of verifying the integrity of the content to the final recipient. That can be done by encrypting the payload, or by signing it. That avoids the recipient having to trust some unknown chain of hosts in the transmission path. Cheers, Dave
Sandy Drobic wrote:
Hylton Conacher (ZR1HPC) wrote:
Carlos E. R. wrote:
The first SMTP sever may ask questions, of course. Any SMTP server in the chain, except the one of the destination address may ask for authentication of some sort; ie, your ISP SMTP server may ask for it, because it will _relay_ your mail to somebody else......
OK, understood. What tyoe of authentication could a SMTP server say 3 down the line ask for? Would its request be answered by the second SMTP server or would SMTP-3 try and contact the original dialup server which may not be currently connected?
Authentication, when it is required, will alway happen between the server that currently has the mail and the server that is contacted to receive the mail. Thanks
Let's just use an example how a mail will progress when you send it off at your company: OK, Goody :)
Your mailclient is configured to send all mails to the mailserver of the department/company. Your mailclient uses your username/password to authenticate to the company mailserver.
Now the company mailserver does not have the right to send the mail directly to the internet. Only the mailgateway is allowed by the firewall to send directly to the internet. So the company mailserver sends the mail to the mailgateway. In order to prevent other clients in the company from sending directly to the mailgateway, the mailgateway also is configured to require authentication to relay mails. So the company mailserver authenticates itself to the mailgateway using his own user/password or maybe a client certificate. This authentication has nothing to do with how you authenticate to the company mailserver.
The mailgateway could be configured to send the mail either to the ISP mailserver or directly to the next mailserver that is responsible for the recipients domain. When it uses the ISP mailserver as relay it might have to authenticate again with an independent user/pass to authenticate itself (the mailgateway) to the ISP mailserver.
How many hops the mail has to pass within the recipients internal network is another question. There could also be several mailservers involved which might ask for authentication.
I admit this is going a bit overboard with the authentication but it could happen nevertheless. Sandy, the above paragraphs were pivotal to my understanding. Free beer/fruit juice on the house for Sandy.
So eventhough my local SMTP server dials up to the internet with a certain username and password, that same username and password would not be used as authentication between my local SMTP server and the ISP's one, should it be used as a relay? <snip>
I don't know what you are trying to say. (^-^) Sorry me neiter :)
The easiest way to test it is to set up several mail accounts in your mailclient and configure each account to send with the same user/pass to your ISP mailserver. Sorry, I didn't see that I was able to specify the name and password the new SMTP server I had added. :()
Are these methods also used if the sender is a SMTP server or are different criteria used? ie see above just below OR.
Which restrictions are used mostly depends on what kind of recipient address the email has. I'll give you a Postfix example:
Your server has the following configuration:
mydestination = example.org mynetworks = 192.168.1.0/24 smptd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, permit
Now, a client in your internal network with the ip 192.168.1.15 connects to your server and wishes to send an email to user@otherdomain.org. Postfix examines the restrictions and evaluates one restriction check after another if a check is returning a value of either "OK, PERMIT" or "REJECT".
The first check in smtpd_recipient_restriction is "permit_mynetworks". It checks, if the connecting client is in the same network as has been defined in mynetworks. In this case, the client is indeed within the network 192.168.1.0/24, so the check returns "OK" and the mail is accepted. No other checks need to be evaluated.
Next, a client with the ip address 80.242.23.16 connects from the internet to your server and wants to send an email to unknown@somewhere-else.org.
Postfix first checks again "permit_mynetworks". This time the check comes up empty because the client ip is NOT in mynetworks. I thought it would have rejected after the mynetworks check as it did not match. It doesn't matter if it meets anything else, mynetworks says
So Postfix tries the next check: permit_sasl_authenticated. Well, the client did not authenticate, so this check also returns an empty result. The next check, "reject_unauth_destination" evaluates if the recipient address is in a domain that Postfix is responsible for, otherwise it returns "REJECT" as result. In this case, the domain somewhere-else.org is not in mydestination, so the check returns "REJECT" and the mail is rejected.
What kind of restriction checks are configured for a mailserver is completely up to you and your requirements. I fully understand your example although I cannot see in the example why
I've added a new entry for smtp.gmail.com and used my gmail username to authenticate. It didn't request a password so I assume that will come up when I send the message. the client must be in a certain IP range, finished the "reject_unauth_destination" variable needed to be checked.
mmm, I've seen email headers and understand this. What i didn't know was that there are normally only a maximum of 2 SMTP servers ie sender and receiver.
Normally there is a minimum of two servers. Though here's an example where only one server is involved:
Your mailclient is sending to the isp mailserver, The recipient's maildomain is also hosted on that server, so the server directly delivers the mail to the mailbox of the recipient, end of story. (^-^)
If the recipient's maildomain is not hosted on the server that you used to send your mail to, then the mail will have to be send at least to another server. Given the above explanation in tandem with what I have received from Carlos et al, this is all starting to make sense.
Thank you all
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-04-29 at 13:57 +0200, Hylton Conacher (ZR1HPC) wrote: ...
Sandy, the above paragraphs were pivotal to my understanding. Free beer/fruit juice on the house for Sandy.
I have saved that email ;-)
So eventhough my local SMTP server dials up to the internet with a certain username and password, that same username and password would not be used as authentication between my local SMTP server and the ISP's one, should it be used as a relay?
No, your postfix uses the file "/etc/postfix/sasl_passwd" to decide what login/passwd to use. It contains lines like this: mailhost.your.isp loginame:password it means that, when talking to smtp server at "mailhost.your.isp", it must use the login/pass pair to the right. ISPs normally use the same password for everything (login, pop3, smtp, ftp...) just to save work. Notice that if we had several users with accounts at that site, we would have problems... it is a server side configuration, not a users' configuration.
The easiest way to test it is to set up several mail accounts in your mailclient and configure each account to send with the same user/pass to your ISP mailserver. Sorry, I didn't see that I was able to specify the name and password the new SMTP server I had added. :()
Mozilla will ask for the login/pass with a dialog at the moment it connects and sees they are needed.
I've added a new entry for smtp.gmail.com and used my gmail username to authenticate. It didn't request a password so I assume that will come up when I send the message.
Right. The settings to use for gmail in mozilla are: Server name: smtp.gmail.com port: 587 [X] Use name and password User name: your_address@gmail.com Use secure connection: [ ] No [ ] TLS, if available [X] TLS [ ] SSL Notice that the port number is selected automatically when selecting TLS - I think, it has being months since I configured this. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEVJUltTMYHG2NR9URAvPzAJ9ABZZwFJV/E5TzKQZiMHY+1myK1wCfac4W EarhEyzEF09EQERAdxBY0o8= =0syH -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Saturday 2006-04-29 at 13:57 +0200, Hylton Conacher (ZR1HPC) wrote:
...
Sandy, the above paragraphs were pivotal to my understanding. Free beer/fruit juice on the house for Sandy.
I have saved that email ;-)
You're welcome. If it saves you the pain having to type it all again when you need it to explain it to someone else you are welcome to recycle it. (^-^)
So eventhough my local SMTP server dials up to the internet with a certain username and password, that same username and password would not be used as authentication between my local SMTP server and the ISP's one, should it be used as a relay?
No, your postfix uses the file "/etc/postfix/sasl_passwd" to decide what login/passwd to use. It contains lines like this:
mailhost.your.isp loginame:password
it means that, when talking to smtp server at "mailhost.your.isp", it must use the login/pass pair to the right. ISPs normally use the same password for everything (login, pop3, smtp, ftp...) just to save work.
Notice that if we had several users with accounts at that site, we would have problems... it is a server side configuration, not a users' configuration.
If you are using the snapshot version of Postfix (version 2.3) then you can use sender-dependent password authentication. http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps
The easiest way to test it is to set up several mail accounts in your mailclient and configure each account to send with the same user/pass to your ISP mailserver. Sorry, I didn't see that I was able to specify the name and password the new SMTP server I had added. :()
Mozilla will ask for the login/pass with a dialog at the moment it connects and sees they are needed.
I've added a new entry for smtp.gmail.com and used my gmail username to authenticate. It didn't request a password so I assume that will come up when I send the message.
Right.
The settings to use for gmail in mozilla are:
Server name: smtp.gmail.com port: 587
[X] Use name and password
User name: your_address@gmail.com
Use secure connection:
[ ] No [ ] TLS, if available [X] TLS [ ] SSL
Notice that the port number is selected automatically when selecting TLS - I think, it has being months since I configured this.
Port 587 is the submission port. It is mainly used for mail clients that need to authenticate before they can send mails. That port is normally configured to support TLS, use authentication and reject all clients that have not authenticated. Sometimes it is the only way to use a mailserver different from the ISP mailserver when the ISP has blocked port 25 to suppress zombie spams to force clients to use the ISP mailserver. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-04-30 at 19:30 +0200, Sandy Drobic wrote:
I have saved that email ;-)
You're welcome. If it saves you the pain having to type it all again when you need it to explain it to someone else you are welcome to recycle it. (^-^)
X-)
Notice that if we had several users with accounts at that site, we would have problems... it is a server side configuration, not a users' configuration.
If you are using the snapshot version of Postfix (version 2.3) then you can use sender-dependent password authentication.
http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps
Ahhhh! I want it! ;-) I'll have to check SuSE 10.1
Port 587 is the submission port. It is mainly used for mail clients that need to authenticate before they can send mails. That port is normally configured to support TLS, use authentication and reject all clients that have not authenticated. Sometimes it is the only way to use a mailserver different from the ISP mailserver when the ISP has blocked port 25 to suppress zombie spams to force clients to use the ISP mailserver.
Aha! Interesting. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEVqSztTMYHG2NR9URArY6AJ4sxJmKfw7hBvZPSyl84nRPFPsBhACdGKrA wWkDXs+NQiCD0VRI8wrS6M0= =vNYK -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Saturday 2006-04-29 at 13:57 +0200, Hylton Conacher (ZR1HPC) wrote:
...
Sandy, the above paragraphs were pivotal to my understanding. Free beer/fruit juice on the house for Sandy.
I have saved that email ;-)
I have a feeling it could be used against me :)
So eventhough my local SMTP server dials up to the internet with a certain username and password, that same username and password would not be used as authentication between my local SMTP server and the ISP's one, should it be used as a relay?
No, your postfix uses the file "/etc/postfix/sasl_passwd" to decide what login/passwd to use. It contains lines like this:
mailhost.your.isp loginame:password
it means that, when talking to smtp server at "mailhost.your.isp", it must use the login/pass pair to the right. ISPs normally use the same password for everything (login, pop3, smtp, ftp...) just to save work. So provided the sasl login/password are correct the receiving SMTP server doesn't care what the details are in the FROM header? (The reeing SMTP server would not do authentication if it is the destination SMTP server).
Notice that if we had several users with accounts at that site, we would have problems... it is a server side configuration, not a users' configuration.
I don't understand why it would be a problem. If the SMTP server os configured with a certain SASL username/password, surely it doesn't matter which user sends mail to server (A)? Server A will connect at predetermined times to send its waiting mail and each user will not be able to force A to send if it is not connected. Hylton Carlos Sandy Patrick | | | | ________________________________________________________ (A) OUR COMPANY SMTP SERVER ________________________________________________________ | ____________________ (B) Relay SMTP server ____________________ | ______________________________________________ (C) Destination SMTP server ______________________________________________
The easiest way to test it is to set up several mail accounts in your mailclient and configure each account to send with the same user/pass to your ISP mailserver.
Sorry, I didn't see that I was able to specify the name and password the new SMTP server I had added. :()
Mozilla will ask for the login/pass with a dialog at the moment it connects and sees they are needed. OK, that is what I thought.
I've added a new entry for smtp.gmail.com and used my gmail username to authenticate. It didn't request a password so I assume that will come up when I send the message.
Right. I'm an IDIOT!! I forgot about the port number.
Thanks for the gmail settings. I will make mine so.
Hylton Conacher (ZR1HPC) wrote:
Carlos E. R. wrote:
No, your postfix uses the file "/etc/postfix/sasl_passwd" to decide what login/passwd to use. It contains lines like this:
mailhost.your.isp loginame:password
it means that, when talking to smtp server at "mailhost.your.isp", it must use the login/pass pair to the right. ISPs normally use the same password for everything (login, pop3, smtp, ftp...) just to save work. So provided the sasl login/password are correct the receiving SMTP server doesn't care what the details are in the FROM header? (The reeing SMTP server would not do authentication if it is the destination SMTP server).
Notice that if we had several users with accounts at that site, we would have problems... it is a server side configuration, not a users' configuration.
I don't understand why it would be a problem. If the SMTP server os configured with a certain SASL username/password, surely it doesn't matter which user sends mail to server (A)? Server A will connect at predetermined times to send its waiting mail and each user will not be able to force A to send if it is not connected.
That depends on the configuration of the receiving server. If the server is configured to only accept mails where the sender address matches the account that your postfix uses to authenticate to the isp mailserver then mails with a different sender address will be rejected.
Hylton Carlos Sandy Patrick | | | | ________________________________________________________ (A) OUR COMPANY SMTP SERVER ________________________________________________________ | ____________________ (B) Relay SMTP server ____________________ | ______________________________________________ (C) Destination SMTP server ______________________________________________
That would be the usual configuration when you are on a dynamic ip. Usually I am sending directly (not via relayhost). When I get rejected I tell my server to route mails for that domain via my isp relayhost. That relayhost ist fortunately NOT configured to reject mails based on the sender address. That is why I can use it without any problems. Though sometimes I might just give up and NOT answer at all if someone expects me to jump through hoops just to help him. (^-°) Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-05-01 at 21:39 +0200, Sandy Drobic wrote: ...
That would be the usual configuration when you are on a dynamic ip. Usually I am sending directly (not via relayhost). When I get rejected I tell my server to route mails for that domain via my isp relayhost. That relayhost ist fortunately NOT configured to reject mails based on the sender address. That is why I can use it without any problems.
Though sometimes I might just give up and NOT answer at all if someone expects me to jump through hoops just to help him. (^-°)
You read my mind ;-) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEVqVutTMYHG2NR9URAiUNAJ9MuVUgsYGUnHeSqMgMoqfLtQ87bQCghSwv XPiUSUzkloeKNdbGYruCFo0= =QFAk -----END PGP SIGNATURE-----
Hylton Conacher (ZR1HPC) wrote:
I admit this is going a bit overboard with the authentication but it could happen nevertheless. Sandy, the above paragraphs were pivotal to my understanding. Free beer/fruit juice on the house for Sandy.
So eventhough my local SMTP server dials up to the internet with a certain username and password, that same username and password would not be used as authentication between my local SMTP server and the ISP's one, should it be used as a relay?
Your smtp server should not dial up to the internet. How the network is configured and in what way it connects to the internet is a task that the Operating System is should take care of, be that a permanent conenction, a semi-permanent connection via DSL/Cable or a dial-up connection that is opened by cron or on request by a dial-up daemon. Postfix merely tries to send a mail off. This might require an internet connection when the mail is destined for an external server. Now it is your task to decide how the system should react: - either defer all outgoing mails until you connect to the internet, then flush out all the mails in the queue. That would be appropriate for a dial-up connection. Postfix should not accept mails directly from the internet in that case. That should be done by the ISP that is hosting your mail domain. Your local server would use an external program like fetchmail to poll the mailserver of your ISP, download the mails and feed them to Postfix. - or you have a permanent connection to the internet. Then Postfix can send mails as soon as they are coming in from the clients. If you do not have a static ip address (your ip address doesn't change even if you shut down and reconnect to the internet) you should configure Postfix to send outgoing mails via the mailserver of your provider. The reason is that many mailservers, especially those of the big companies and ISPs are configured to reject mails coming from a non-static ip address. They have made the experience that the overwhelming majority of mails coming from dynamic ip addresses are spam.
<snip>
I don't know what you are trying to say. (^-^) Sorry me neiter :)
The easiest way to test it is to set up several mail accounts in your mailclient and configure each account to send with the same user/pass to your ISP mailserver. Sorry, I didn't see that I was able to specify the name and password the new SMTP server I had added. :()
I've added a new entry for smtp.gmail.com and used my gmail username to authenticate. It didn't request a password so I assume that will come up when I send the message.
Are you talking about Postfix or your Mailclient?
Are these methods also used if the sender is a SMTP server or are different criteria used? ie see above just below OR.
Which restrictions are used mostly depends on what kind of recipient address the email has. I'll give you a Postfix example:
Your server has the following configuration:
mydestination = example.org mynetworks = 192.168.1.0/24 smptd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, permit
Now, a client in your internal network with the ip 192.168.1.15 connects to your server and wishes to send an email to user@otherdomain.org. Postfix examines the restrictions and evaluates one restriction check after another if a check is returning a value of either "OK, PERMIT" or "REJECT".
The first check in smtpd_recipient_restriction is "permit_mynetworks". It checks, if the connecting client is in the same network as has been defined in mynetworks. In this case, the client is indeed within the network 192.168.1.0/24, so the check returns "OK" and the mail is accepted. No other checks need to be evaluated.
Next, a client with the ip address 80.242.23.16 connects from the internet to your server and wants to send an email to unknown@somewhere-else.org.
Postfix first checks again "permit_mynetworks". This time the check comes up empty because the client ip is NOT in mynetworks.
I thought it would have rejected after the mynetworks check as it did not match. It doesn't matter if it meets anything else, mynetworks says the client must be in a certain IP range, finished
The check permit_mynetworks" returns "OK" if the client ip address is in mynetworks. If not, the check simply returns a "DUNNO" which means Postfix should continue and evaluate the next check. The test does NOT say "All clients must be in mynetworks, otherwise the mail is rejected". That would mean that you can't accept mail from clients that you do not know. The correct interpretation of this check is: "If you are a member of my network I can trust you and accept any mail you want me to send to the world. If you do not belong to my network, I can't trust you implicitely. Though you might ask "permit_sasl_authenticated" if your credentials are sufficient to trust you.
So Postfix tries the next check: permit_sasl_authenticated. Well, the client did not authenticate, so this check also returns an empty result. The next check, "reject_unauth_destination" evaluates if the recipient address is in a domain that Postfix is responsible for, otherwise it returns "REJECT" as result. In this case, the domain somewhere-else.org is not in mydestination, so the check returns "REJECT" and the mail is rejected.
What kind of restriction checks are configured for a mailserver is completely up to you and your requirements.
I fully understand your example although I cannot see in the example why the "reject_unauth_destination" variable needed to be checked.
The check "reject_unauth_destination" is one of the most important checks when you configure Postfix. This check rejects all mails that Postfix can not deliver locally and would have to send out to the internet! "unauth_destination" in this case are all recipient addresses that Postfix itself is not responsible for. All other recipient addresses are rejected. The log then says "Relay access denied". In other words, this test separates the trusted clients that either belong to mynetworks or have authenticated and thus are allowed to relay mails through this server, or the untrusted clients that may only send mails that this server feels responsible for. All tests after that check only apply to external (or internal) untrusted clients. It is also the reason why that check should come immediately after the checks for the trusted clients in the order of restrictions. Frequently you encounter badly configured servers that trust clients when they claim "I have your ip address" or "I belong to your domain". The spam zombies try to find these servers and often try to impersonate such trusted clients. That is the reason why you should only trust clients that have proven their identity in a way you can trust. The ip address is practically impossible to fake during the course of such a smtp communication. You can trust that the ip address of the client is actually the ip address the client is really using. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic wrote:
Hylton Conacher (ZR1HPC) wrote:
I admit this is going a bit overboard with the authentication but it could happen nevertheless.
Sandy, the above paragraphs were pivotal to my understanding. Free beer/fruit juice on the house for Sandy.
So eventhough my local SMTP server dials up to the internet with a certain username and password, that same username and password would not be used as authentication between my local SMTP server and the ISP's one, should it be used as a relay?
Your smtp server should not dial up to the internet. How the network is configured and in what way it connects to the internet is a task that the Operating System is should take care of, be that a permanent conenction, a semi-permanent connection via DSL/Cable or a dial-up connection that is opened by cron or on request by a dial-up daemon. OK, it was used figurativly, but I see that I am going to need to get another box here to act as the dialup server+firewall+IPS.
Network planning mode ON :)
Postfix merely tries to send a mail off. This might require an internet connection when the mail is destined for an external server. Now it is your task to decide how the system should react:
- either defer all outgoing mails until you connect to the internet, then flush out all the mails in the queue. That would be appropriate for a dial-up connection. Postfix should not accept mails directly from the internet in that case. That should be done by the ISP that is hosting your mail domain. Your local server would use an external program like fetchmail to poll the mailserver of your ISP, download the mails and feed them to Postfix. This is the method I would use.
- or you have a permanent connection to the internet. Then Postfix can send mails as soon as they are coming in from the clients. If you do not have a static ip address (your ip address doesn't change even if you shut down and reconnect to the internet) you should configure Postfix to send outgoing mails via the mailserver of your provider. The reason is that many mailservers, especially those of the big companies and ISPs are configured to reject mails coming from a non-static ip address. They have made the experience that the overwhelming majority of mails coming from dynamic ip addresses are spam. Carlos said earlier that the SMTP server might not accept from a dynamic IP and I wondered if sending to the ISP mailserver would prevent bounved mails.
The easiest way to test it is to set up several mail accounts in your mailclient and configure each account to send with the same user/pass to your ISP mailserver.
Sorry, I didn't see that I was able to specify the name and password the new SMTP server I had added. :()
I've added a new entry for smtp.gmail.com and used my gmail username to authenticate. It didn't request a password so I assume that will come up when I send the message.
Are you talking about Postfix or your Mailclient? My Mozilla mailclient.
Are these methods also used if the sender is a SMTP server or are different criteria used? ie see above just below OR.
Which restrictions are used mostly depends on what kind of recipient address the email has. I'll give you a Postfix example:
Your server has the following configuration:
mydestination = example.org mynetworks = 192.168.1.0/24 smptd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, permit
Now, a client in your internal network with the ip 192.168.1.15 connects to your server and wishes to send an email to user@otherdomain.org. Postfix examines the restrictions and evaluates one restriction check after another if a check is returning a value of either "OK, PERMIT" or "REJECT".
The first check in smtpd_recipient_restriction is "permit_mynetworks". It checks, if the connecting client is in the same network as has been defined in mynetworks. In this case, the client is indeed within the network 192.168.1.0/24, so the check returns "OK" and the mail is accepted. No other checks need to be evaluated.
Next, a client with the ip address 80.242.23.16 connects from the internet to your server and wants to send an email to unknown@somewhere-else.org.
Postfix first checks again "permit_mynetworks". This time the check comes up empty because the client ip is NOT in mynetworks.
I thought it would have rejected after the mynetworks check as it did not match. It doesn't matter if it meets anything else, mynetworks says the client must be in a certain IP range, finished
The check permit_mynetworks" returns "OK" if the client ip address is in mynetworks. If not, the check simply returns a "DUNNO" which means Postfix should continue and evaluate the next check. The test does NOT say "All clients must be in mynetworks, otherwise the mail is rejected". That would mean that you can't accept mail from clients that you do not know.
The correct interpretation of this check is: "If you are a member of my network I can trust you and accept any mail you want me to send to the world. If you do not belong to my network, I can't trust you implicitely. Though you might ask "permit_sasl_authenticated" if your credentials are sufficient to trust you.
So Postfix tries the next check: permit_sasl_authenticated. Well, the client did not authenticate, so this check also returns an empty result. The next check, "reject_unauth_destination" evaluates if the recipient address is in a domain that Postfix is responsible for, otherwise it returns "REJECT" as result. In this case, the domain somewhere-else.org is not in mydestination, so the check returns "REJECT" and the mail is rejected.
What kind of restriction checks are configured for a mailserver is completely up to you and your requirements.
I fully understand your example although I cannot see in the example why the "reject_unauth_destination" variable needed to be checked.
The check "reject_unauth_destination" is one of the most important checks when you configure Postfix. This check rejects all mails that Postfix can not deliver locally and would have to send out to the internet! "unauth_destination" in this case are all recipient addresses that Postfix itself is not responsible for. All other recipient addresses are rejected. The log then says "Relay access denied".
In other words, this test separates the trusted clients that either belong to mynetworks or have authenticated and thus are allowed to relay mails through this server, or the untrusted clients that may only send mails that this server feels responsible for. There is a bit of confusion creeping in here when you say that the SMTP is not responsible for. An SMTP server is responsible only for sending email. If my SMTP server is the only SMTP relay server between the host and destination, that "reject_unauth_destination" is a little cruel as then the message will be rejected. Would it be rejected to the SMTP server that sent it to me and that SMTP server would have to find, via DNS, an alternate route to the destination?
All tests after that check only apply to external (or internal) untrusted clients.
It is also the reason why that check should come immediately after the checks for the trusted clients in the order of restrictions.
Frequently you encounter badly configured servers that trust clients when they claim "I have your ip address" or "I belong to your domain". The spam zombies try to find these servers and often try to impersonate such trusted clients. That is the reason why you should only trust clients that have proven their identity in a way you can trust. The ip address is practically impossible to fake during the course of such a smtp communication. You can trust that the ip address of the client is actually the ip address the client is really using. OK, I'll try and remember though Whew, the brain is spinning. I'm going to need a new brain when I actually start setting this Postfic server up :)
Thankfully I trust no-one, with very few exceptions.
Hylton Conacher (ZR1HPC) wrote:
Network planning mode ON :)
Postfix merely tries to send a mail off. This might require an internet connection when the mail is destined for an external server. Now it is your task to decide how the system should react:
- either defer all outgoing mails until you connect to the internet, then flush out all the mails in the queue. That would be appropriate for a dial-up connection. Postfix should not accept mails directly from the internet in that case. That should be done by the ISP that is hosting your mail domain. Your local server would use an external program like fetchmail to poll the mailserver of your ISP, download the mails and feed them to Postfix.
This is the method I would use.
Please take into account that this is a bit of a hack, that means a mailserver was never intended to only have a temporary connection. Though it should work without much problem. On the other hand, you won't get most of the advantages of a permanent mailserver. The restrictions that I have set on my mailserver allow me to post freely to all the mailing lists and yet stay free of spam. Those restrictions are only possible with a mailserver, that is directly receiving the mails.
The check "reject_unauth_destination" is one of the most important checks when you configure Postfix. This check rejects all mails that Postfix can not deliver locally and would have to send out to the internet! "unauth_destination" in this case are all recipient addresses that Postfix itself is not responsible for. All other recipient addresses are rejected. The log then says "Relay access denied".
In other words, this test separates the trusted clients that either belong to mynetworks or have authenticated and thus are allowed to relay mails through this server, or the untrusted clients that may only send mails that this server feels responsible for.
There is a bit of confusion creeping in here when you say that the SMTP is not responsible for. An SMTP server is responsible only for sending
That is not correct. A mailserver usually is responsible for sending AND receiving Mails. Postfix has several different classes of domains that he recognises as domains he (the local server) is hosting locally and therefore should accept mails for such a domain. For example, my mailserver is responsible for the domain "japantest.homelinux.com". When a client is sending a mail with a recipient address xxx@japantest.homelinux.com" to my server, my server is configured to accept the mail, provided there is no other reason to reject it. The client does not need to authenticate to my server.
email. If my SMTP server is the only SMTP relay server between the host and destination, that "reject_unauth_destination" is a little cruel as then the message will be rejected. Would it be rejected to the SMTP server that sent it to me and that SMTP server would have to find, via DNS, an alternate route to the destination?
An example to clear up the misunderstanding: A mailserver is contacting your local server and asks your server to accept a mail for xyz@dont-know.com. Your server is not configured to accept mails for that domain, so the mail is rejected and the contacting server still has the mail and is responsible for it. In this example there are two questions you might ask the contacting server: Question 1: Why would that idiot of a server ask MY server to accept the mail? Question 2: Why is my server even listening on the internet for idiots like that when I don't plan to receive mails directly? Let's have a look at Question 1: The way a mailserver tries to find a responsible server for a recipient address is to query the DNS for an entry that says: "This server is assigned to accept mails for that domain". The DNS knows a specific DNS entry for that kind of query, the MX entry. You can do that manually with tools like "dig" or "nslookup". # dig mx dont-know.com +short 10 mx0.gmx.net. 10 mx0.gmx.de. Well, look at that, that domain actually exists! This means that these two servers will accept mails for the domain dont-know.com. Okay, so why is that idiot trying MY server to deliver the mail?? All the more reason to reject such a mail. Sometimes you encounter an obvious misconfiguration like 1. DNS query says "server xxx is responsible for that domain" 2. Server xxx does not know he is responsible an rejects the mail. Often that is happening because the domain changed owner and the new owner didn't think about configuring a mailserver. When no MX entry is configured for a domain in DNS, the mailserver tries to find an ip address that is mapped to that domain (A entry in DNS). Often a webserver is using that ip address but it will not accept mails. Shit happens... If that happens the mail is not deliverable and will bounce after a certain time. Back to Question 2: When you configure your server to use fetchmail (or getmail or whatever other tool) to download the mails from your provider you don't need to have that server listening on the internet because your server will not receive mails directly, only via fetchmail or from your local little network.
All tests after that check only apply to external (or internal) untrusted clients.
It is also the reason why that check should come immediately after the checks for the trusted clients in the order of restrictions.
Frequently you encounter badly configured servers that trust clients when they claim "I have your ip address" or "I belong to your domain". The spam zombies try to find these servers and often try to impersonate such trusted clients. That is the reason why you should only trust clients that have proven their identity in a way you can trust. The ip address is practically impossible to fake during the course of such a smtp communication. You can trust that the ip address of the client is actually the ip address the client is really using.
OK, I'll try and remember though Whew, the brain is spinning. I'm going to need a new brain when I actually start setting this Postfic server up :)
Take it easy, even if some people claim that it is very simple to configure a mailserver, it is a completely different beast to have a real understanding how a mailserver should work.
Thankfully I trust no-one, with very few exceptions.
Spammers don't ask for your trust, they merely want to exploit your server. (^-^) Often they abuse a script on a webserver to send their spam. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
On Mon, 2006-04-10 at 17:01 +0200, Hylton Conacher (ZR1HPC) wrote:
If I receive list mail on the hylton@conacher address, I cannot reply to it from the conacher address bucause my ISP will not route the mail as they autheniticate the sender ie the sender hylton@conacher is not the email address of the connected member on their network and they therefore drop the mail into the ether.
Hylton, I see you posted from a global.co.za address - they are much cheaper than most saix reseller ISPs - if they give you this sort of crap, dump them and go somewhere else. They *should* authenticate you based on your network address. i.e. if you're inside your ISPs network, you should be able to send from any address you please. They're a big company and I'm sure they have many small businesses as clients who have their own domain. Failing that they should provide you with smtp authentication. But I still say, considering what we have available here, dump them and go somewhere else. I'd be happy to point you in the right direction. Hans
On Mon, 2006-04-10 at 17:01 +0200, Hylton Conacher (ZR1HPC) wrote:
If I receive list mail on the hylton@conacher address, I cannot reply to it from the conacher address bucause my ISP will not route the mail as they autheniticate the sender ie the sender hylton@conacher is not the email address of the connected member on their network and they therefore drop the mail into the ether.
Hylton, I see you posted from a global.co.za address - they are much cheaper than most saix reseller ISPs - if they give you this sort of crap, dump them and go somewhere else. That is definitely an option, changin ISP. A litle homework reveals that
Hans du Plooy wrote: the same ISP who I have my domain registered with is the cheaper and more business like ISP.
They *should* authenticate you based on your network address. i.e. if you're inside your ISPs network, you should be able to send from any address you please. 'Should' and 'can' seem to be mutually exclusive terms with this ISP :)
They're a big company and I'm sure they have many small businesses as clients who have their own domain. But probably the ISP holds the domain, not another ISP.
Failing that they should provide you with smtp authentication. You try and explain this to a previously disadvantaged. :) They say that provided I am dialed in I should be able to send email from any email address, and this is the exact opposite to what what I have heard from the currently disadvantaged members of the call centre.
But I still say, considering what we have available here, dump them and go somewhere else. I'd be happy to point you in the right direction. PM me on some pointers although I think I'll probably go with the same ISP the domain is registered with.
participants (13)
-
C. Brouerius van Nidek -
Carlos E. R. -
Carlos E. R. -
Christopher Taylor -
Clayton -
Daniel Bauer -
Dave Howorth -
Greg Wallace -
Hans du Plooy -
Hylton Conacher (ZR1HPC) -
James Knott -
Patrick Shanahan -
Sandy Drobic