If there was an automatic ban on List mail containing HTML parts, it is likely the latest crap would not be distributed to everyone.
A possible test of the Content-Type: header for
multipart/mixed;
or
text/html;
might stop the spam.
On 7/16/2011 6:50 PM, Always Learning wrote:
If there was an automatic ban on List mail containing HTML parts, it is likely the latest crap would not be distributed to everyone.
A possible test of the Content-Type: header for
multipart/mixed;or
text/html;might stop the spam.
you mean like the default settings of Mailman list software that the CentOS list "doesn't" run on? I have five lists running on one of my CentOS servers and crap like that doesn't ever make it to the list.
On 07/16/2011 05:06 PM, Mark Weaver wrote:
you mean like the default settings of Mailman list software that the CentOS list "doesn't" run on? I have five lists running on one of my CentOS servers and crap like that doesn't ever make it to the list.
Mark.... take a careful look at the footers of each email.
On 7/16/2011 8:33 PM, KevinO wrote:
On 07/16/2011 05:06 PM, Mark Weaver wrote:
you mean like the default settings of Mailman list software that the CentOS list "doesn't" run on? I have five lists running on one of my CentOS servers and crap like that doesn't ever make it to the list.
Mark.... take a careful look at the footers of each email.
Oops... my bad. here I set with egg on my face. However they did used to use a different mailing list package.
On Sat, Jul 16, 2011 at 08:40:37PM -0400, Mark Weaver wrote:
Oops... my bad. here I set with egg on my face. However they did used to use a different mailing list package.
They did?
John
On Sat, 2011-07-16 at 20:06 -0400, Mark Weaver wrote:
On 7/16/2011 6:50 PM, Always Learning wrote:
If there was an automatic ban on List mail containing HTML parts, it is likely the latest crap would not be distributed to everyone.
A possible test of the Content-Type: header for
multipart/mixed;or
text/html;might stop the spam.
you mean like the default settings of Mailman list software that the CentOS list "doesn't" run on? I have five lists running on one of my CentOS servers and crap like that doesn't ever make it to the list.
It is the method I use with Exim to block unwanted HTML emails.
I also do not accept external mail if the HELO/EHLO is not identical to the host name used by the sending server. Its a marvellous method of removing lots of spam. Unfortunately some large organisations (i.e. Ebay, British Telecommunications (BT) and others) are so utterly incompetent they fail - so their emails get rejected. If they want to send us emails, they have to obey our rules.
Always Learning wrote:
On Sat, 2011-07-16 at 20:06 -0400, Mark Weaver wrote:
On 7/16/2011 6:50 PM, Always Learning wrote:
If there was an automatic ban on List mail containing HTML parts, it is likely the latest crap would not be distributed to everyone.
A possible test of the Content-Type: header for
multipart/mixed;or
text/html;might stop the spam.
you mean like the default settings of Mailman list software that the CentOS list "doesn't" run on? I have five lists running on one of my CentOS servers and crap like that doesn't ever make it to the list.
It is the method I use with Exim to block unwanted HTML emails.
I also do not accept external mail if the HELO/EHLO is not identical to the host name used by the sending server. Its a marvellous method of removing lots of spam. Unfortunately some large organisations (i.e. Ebay, British Telecommunications (BT) and others) are so utterly incompetent they fail - so their emails get rejected. If they want to send us emails, they have to obey our rules.
I use it too. Reverse-DNS check is best SPAM repellent there is. Only mail from properly set mail servers is accepted.
Ljubomir
Ljubomir Ljubojevic office@plnet.rs wrote:
I use it too. Reverse-DNS check is best SPAM repellent there is. Only mail from properly set mail servers is accepted.
That's fine if your check is that a reverse DNS entry exists, or that the HELO/ELHO exists in forward DNS or, if your MTA is smart enough, it does a reverse-forward* check, but if you only check that the HELO/ELHO matches the reverse entry then you're blocking a bunch of valid mailers because there is no specification requirement that those two match (and they don't in the general case).
(*) reverse-forward here means do a reverse lookup on the connecting IP, then doing a forward lookup on the result, and then ensure that original IP is one of the 'A' records resolved from the forward lookup.
Devin
On Sun, 2011-07-17 at 11:06 -0600, Devin Reade wrote:
That's fine if your check is that a reverse DNS entry exists, or that the HELO/ELHO exists in forward DNS or, if your MTA is smart enough, it does a reverse-forward* check, but if you only check that the HELO/ELHO matches the reverse entry then you're blocking a bunch of valid mailers because there is no specification requirement that those two match (and they don't in the general case).
What is the point of some super stupid over-paid Computer Professional (usually a Windoze lover) configuring his or her (although women are more careful than men) mail server to send emails with false credentials ?
Example: HELO/EHLO my identity is stupid.example.com
when that server is operating on IP address xxx.yyy.zzz.aaa
and stupid.example.com has a DNS 'A' record for IP address bbb.eee.sss.ttt ?
Incidentally the mail server's IP address xxx.yyy.zzz.aaa has a host name of ridiculous.example.com
you're blocking a bunch of valid mailers
What is 'valid' in this situation ?
there is no specification requirement that those two match (and they don't in the general case).
When you telephone someone from your office, do you usually give a false name and contact telephone number ? No, of course you do not. Why tolerate false details from a source who is often a spammer.
Mail Admins should unite against spammers not deliberately emulate them.
Here a a few examples: http://sys.u226.com/t21/t21p003.php
Am 17.07.2011 22:30, schrieb Always Learning:
Here a a few examples: http://sys.u226.com/t21/t21p003.php
Just to understand you, could you please explain one of your "examples"?
The 2nd one in your list:
Organisation: British Telecommunications, EU HELO / EHLO: smtpe1.intersmtp.com HELO IP: 62.239.224.89 MX IP: 62.239.224.234 MX DNS A record: smtp61.intersmtp.com
Here smtpe1.intersmtp.com resolves properly forward and reverse, if that is what counts for you.
Alexander
On Sun, 2011-07-17 at 23:15 +0200, Alexander Dalloz wrote:
The 2nd one in your list:
Organisation: British Telecommunications, EU HELO / EHLO: smtpe1.intersmtp.com HELO IP: 62.239.224.89 MX IP: 62.239.224.234 MX DNS A record: smtp61.intersmtp.com
Here smtpe1.intersmtp.com resolves properly forward and reverse, if that is what counts for you.
BUT the IP address used for the mail server was, as the list shows, 62.239.224.234 which, at the time, had a host name of smtp61.intersmtp.com
smtpe1.intersmtp.com still does NOT properly resolve.
host smtpe1.intersmtp.com smtpe1.intersmtp.com has address 62.239.224.89
host 62.239.224.89 89.224.239.62.in-addr.arpa domain name pointer smtpe1.intersmtp.COM.
*almost* correct. In Linux, like Unix and the pre-Microsoft days, uppercase letters have a different numerical value to lowercase letters.
Uppercase 'COM' is definitely not the same as lowercase 'com'.
No wonder some call 'BT' Balls-up Telecoms.
Do your Mail Transfer Agents use valid or bogus HELO/EHLO names ?
Am 17.07.2011 23:24, schrieb Always Learning:
On Sun, 2011-07-17 at 23:15 +0200, Alexander Dalloz wrote:
The 2nd one in your list:
Organisation: British Telecommunications, EU HELO / EHLO: smtpe1.intersmtp.com HELO IP: 62.239.224.89 MX IP: 62.239.224.234 MX DNS A record: smtp61.intersmtp.com
Here smtpe1.intersmtp.com resolves properly forward and reverse, if that is what counts for you.
BUT the IP address used for the mail server was, as the list shows, 62.239.224.234 which, at the time, had a host name of smtp61.intersmtp.com
What do you mean by that? Was the connecting mailserver the one with IP 62.239.224.234? If you mean that the mailserver should have been the one listed as MX, you are simply wrong and you do not know what an MX is.
smtpe1.intersmtp.com still does NOT properly resolve.
host smtpe1.intersmtp.com smtpe1.intersmtp.com has address 62.239.224.89
host 62.239.224.89 89.224.239.62.in-addr.arpa domain name pointer smtpe1.intersmtp.COM.
*almost* correct. In Linux, like Unix and the pre-Microsoft days, uppercase letters have a different numerical value to lowercase letters.
Uppercase 'COM' is definitely not the same as lowercase 'com'.
In DNS as well in mail addresses in the public zone the letter case does not matter.
No wonder some call 'BT' Balls-up Telecoms.
Do your Mail Transfer Agents use valid or bogus HELO/EHLO names ?
No, though there is no RFC which states that the HELO/EHLO name must be eqal to any MX record. In your example the greeting name resolves fine and is ok in this regard.
Someone who does not want to receive mail from legitimate senders can just switch off his MTA ;-)
Alexander
On Sun, 2011-07-17 at 23:33 +0200, Alexander Dalloz wrote:
Organisation: British Telecommunications, EU HELO / EHLO: smtpe1.intersmtp.com HELO IP: 62.239.224.89 MX IP: 62.239.224.234 MX DNS A record: smtp61.intersmtp.com
BUT the IP address used for the mail server was, as the list shows, 62.239.224.234 which, at the time, had a host name of smtp61.intersmtp.com
What do you mean by that? Was the connecting mailserver the one with IP 62.239.224.234? If you mean that the mailserver should have been the one listed as MX, you are simply wrong and you do not know what an MX is.
In the list there is limited space for explanations. There is no abbreviation for 'receiving MTA' so I used 'MX'. I have changed it to ACTUAL. Hope that helps. (You will probably need to refresh/reload the web page)
In DNS as well in mail addresses in the public zone the letter case does not matter.
I know. It was a joke about the COM and com :-)
No, though there is no RFC which states that the HELO/EHLO name must be eqal to any MX record. In your example the greeting name resolves fine and is ok in this regard.
If the 'greeting name' (HELO/EHLO) does not resolve to the IP address used by the sending server, then the mail is not accepted.
Someone who does not want to receive mail from legitimate senders can just switch off his MTA ;-)
Legitimate senders should not use fake, false, misleading credentials.
Incidentally your own ISP is one of the worse users in England of 'fake' HELO/EHLO names.
On 7/17/11 4:48 PM, Always Learning wrote:
If the 'greeting name' (HELO/EHLO) does not resolve to the IP address used by the sending server, then the mail is not accepted.
That's ummm, kind of random. There's no reason to expect this.
Someone who does not want to receive mail from legitimate senders can just switch off his MTA ;-)
Legitimate senders should not use fake, false, misleading credentials.
There is no requirement for the greeting name to match any IP, and isn't likely to work for multi-homed and/or clustered machines.
On Sun, 2011-07-17 at 21:07 -0500, Les Mikesell wrote:
On 7/17/11 4:48 PM, Always Learning wrote:
Legitimate senders should not use fake, false, misleading credentials.
There is no requirement for the greeting name to match any IP, and isn't likely to work for multi-homed and/or clustered machines.
Which type of 'multi-homing' were you thinking about ?
http://en.wikipedia.org/wiki/Multihoming
* Single Link, Multiple IP address (Spaces) * Multiple Interfaces, Single IP address per interface * Multiple Links, Single IP address (Space) * Multiple Links, Multiple IP address (Spaces)
Which type of 'cluster' were you thinking about ?
http://en.wikipedia.org/wiki/Computer_cluster
* High-availability (HA) clusters * Load-balancing clusters * Compute clusters
If any of these share the same IP address, they can share the same host name.
I am not well acquainted with either of the above two methods, multi-homed and clusters, but I can not understand why any of them should resort to using fake identities when sending-out emails.
Can you help me understand why bogus identities are necessary in these circumstances ?
Thank you.
On 7/17/11 9:18 PM, Always Learning wrote:
Legitimate senders should not use fake, false, misleading credentials.
There is no requirement for the greeting name to match any IP, and isn't likely to work for multi-homed and/or clustered machines.
Which type of 'multi-homing' were you thinking about ?
http://en.wikipedia.org/wiki/Multihoming
- Single Link, Multiple IP address (Spaces)
- Multiple Interfaces, Single IP address per interface
- Multiple Links, Single IP address (Space)
- Multiple Links, Multiple IP address (Spaces)
Multiple interfaces, multiple IP addresses. Sendmail isn't going to track which interface it is sending on and adjust its greeting.
Which type of 'cluster' were you thinking about ?
http://en.wikipedia.org/wiki/Computer_cluster
- High-availability (HA) clusters
- Load-balancing clusters
- Compute clusters
If any of these share the same IP address, they can share the same host name.
There are any number of topologies that use multiple IP addresses for what appears to be one name. A load balancer might be involved, they may or may not accept on the same IP's as they use for outbound connections, they may or may not know the outbound ip.
I am not well acquainted with either of the above two methods, multi-homed and clusters, but I can not understand why any of them should resort to using fake identities when sending-out emails.
Just because it doesn't match the IP doesn't make it fake.
Can you help me understand why bogus identities are necessary in these circumstances ?
You are the one defining it as bogus. Consider a system where one or more of it's routes to the internet go through nat routers or the nat functionality of a load balancer. The program sending the mail won't even know the IP you see.
On Sun, 2011-07-17 at 21:57 -0500, Les Mikesell wrote:
Multiple interfaces, multiple IP addresses. Sendmail isn't going to track which interface it is sending on and adjust its greeting.
Sendmail ? Golly some of us have advanced to more advance systems like Exim ;-)
When I complained to Cable & Wireless who operate mail sending from all the UK police forces, they adopted a seemingly unique solution by having the identical host name mapped to their different IP addresses. That solution solved it for me.
Which type of 'cluster' were you thinking about ?
There are any number of topologies that use multiple IP addresses for what appears to be one name. A load balancer might be involved, they may or may not accept on the same IP's as they use for outbound connections, they may or may not know the outbound ip.
It is not inbound (to them) that interests me but outbound. Every IP address can have a host name, so in theory there is no reason for the use of fake (non-existent or wrong) host names when sending emails.
When a computer application is configured to send emails, part of the configuration process permits a host name to be chosen. In theory there seems no sensible reason for a fake host name to be used and that must, I would have thought, apply to multi-homed, clustered, load-balancers etc. There is absolutely nothing to stop several IP addresses having the identical host name.
Just because it doesn't match the IP doesn't make it fake.
There are three reasons why a host name may not match the IP address it is operating on.
(1) there is no A record so that host name does not exist;
(2) there is no reverse name for the IP address;
(3) the host name belongs to a different IP address;
Can you help me understand why bogus identities are necessary in these circumstances ?
You are the one defining it as bogus. Consider a system where one or more of it's routes to the internet go through nat routers or the nat functionality of a load balancer. The program sending the mail won't even know the IP you see.
See my point above about configuring an application to send emails and the choice there is to use a genuine host name which belongs to the IP address that application is using to send emails.
Bogus host names are simply a symptom of a disorganised and neglected mail sending (and perhaps also receiving) system where no one takes any pride in doing an important job responsibly.
On 7/17/11 10:22 PM, Always Learning wrote:
Multiple interfaces, multiple IP addresses. Sendmail isn't going to track which interface it is sending on and adjust its greeting.
Sendmail ? Golly some of us have advanced to more advance systems like Exim ;-)
Does it vary it's HELO per interface? How is it aware of upstream NATs?
When I complained to Cable& Wireless who operate mail sending from all the UK police forces, they adopted a seemingly unique solution by having the identical host name mapped to their different IP addresses. That solution solved it for me.
I'm somewhat shocked that they made such a change when there is no standard that requires it.
It is not inbound (to them) that interests me but outbound. Every IP address can have a host name, so in theory there is no reason for the use of fake (non-existent or wrong) host names when sending emails.
IP addresses do not correspond to hosts. They correspond to interfaces. There is not a 1 to 1 correspondence between hosts and IPs.
When a computer application is configured to send emails, part of the configuration process permits a host name to be chosen. In theory there seems no sensible reason for a fake host name to be used and that must, I would have thought, apply to multi-homed, clustered, load-balancers etc. There is absolutely nothing to stop several IP addresses having the identical host name.
If you like to waste IP addresses, you could add some just to give them names that would keep you happy.
Just because it doesn't match the IP doesn't make it fake.
There are three reasons why a host name may not match the IP address it is operating on.
(1) there is no A record so that host name does not exist;
(2) there is no reverse name for the IP address;
There isn't much correspondence between 1 and 2 either. The host name, the forward DNS entry and reverse DNS entry are all very different things, generally managed by different sets of people, even in cases where there is a one to one correspondence, which there often isn't.
(3) the host name belongs to a different IP address;
Or many of them.
Bogus host names are simply a symptom of a disorganised and neglected mail sending (and perhaps also receiving) system where no one takes any pride in doing an important job responsibly.
Or people following what the standard says and expecting others to do the same.
On Sun, Jul 17, 2011 at 09:07:38PM -0500, Les Mikesell wrote:
There is no requirement for the greeting name to match any IP, and isn't likely
RFC2821 says: - The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
So, pretty much, HELO or EHLO greeting _must_ match to an IP.
(RFC821 actually wanted the HELO to match the connecting host, but 2821 just says it must be an A record or an address literal).
On Sun, 2011-07-17 at 22:37 -0400, Stephen Harris wrote:
On Sun, Jul 17, 2011 at 09:07:38PM -0500, Les Mikesell wrote:
There is no requirement for the greeting name to match any IP, and isn't likely
RFC2821 says:
- The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
So, pretty much, HELO or EHLO greeting _must_ match to an IP.
(RFC821 actually wanted the HELO to match the connecting host, but 2821 just says it must be an A record or an address literal).
Thank you Stephen. This is most useful.
I have just received spam about an enlargement to part of the male body, sent to a special email address I created solely to see a Murdock/News International newspaper on-line:-
exclusivepreview.timesonline.co.uk@xxxxxx
It seems spammers have successfully hacked Rupert Murdock's London Times newspaper and copied hundreds of thousands of email addresses or has a member of staff sold the email addresses to spammers to make some money?
To combat the menace of SPAM lazy mail administrators must act responsibly and end their inexcusable attitude that results in their mail servers emulating spammers by using false identities in their HELO/EHLO. The greater the distinction between a spammer's mail server and a genuine mail server, the easier it becomes to block spam.
On Mon, 2011-07-18 at 04:04 +0100, Always Learning wrote:
On Sun, 2011-07-17 at 22:37 -0400, Stephen Harris wrote:
On Sun, Jul 17, 2011 at 09:07:38PM -0500, Les Mikesell wrote:
There is no requirement for the greeting name to match any IP, and isn't likely
RFC2821 says:
- The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
So, pretty much, HELO or EHLO greeting _must_ match to an IP.
(RFC821 actually wanted the HELO to match the connecting host, but 2821 just says it must be an A record or an address literal).
It seems spammers have successfully hacked Rupert Murdock's London Times newspaper and copied hundreds of thousands of email addresses or has a member of staff sold the email addresses to spammers to make some money?
Though it is certainly possible that a breach of some sort is responsible for your spam, sniffing for email headers on high activity parts of a network would be sufficient to collect a large number of active email addresses to try (sniffing at Tor gateways could provide interesting results, come to think of it). Another big winner for mailbox collection is to not crack the information provider's site, but to instead crack the email service provider and obtain a list of all active accounts on that server (which would likely span multiple domains).
Getting a hold of email accounts can happen any number of ways, most of them uncontrollable by the account holder. Its a mailbox -- an open destination for the world to send you stuff. You can't be too surprised when the world does in fact send you stuff.
Traditional solutions include hiring a secretary to screen your mail (today this would be setting up SpamAssassin) or ignoring all but personal messages on verified stationary (today this would be digitally signed mail) and instead going out to retreive your information at need instead of having it sent to you at availability.
The diffrence between deposit/fetch and send/receive is profound. This is part of why I'm surprised that newsreaders and forums have fallen from favor amongst technical discussion groups. The "Logging into forums is a PITA" or "setting up another client is a PITA" arguments obviously won the debate -- though I think spam is a lot deeper into PITA territory than either at the present time.
-Iwao
On Mon, 2011-07-18 at 15:45 +0900, 夜神 岩男 wrote:
On Mon, 2011-07-18 at 04:04 +0100, Always Learning wrote:
It seems spammers have successfully hacked Rupert Murdock's London Times newspaper and copied hundreds of thousands of email addresses or has a member of staff sold the email addresses to spammers to make some money?
Though it is certainly possible that a breach of some sort is responsible for your spam, sniffing for email headers on high activity parts of a network would be sufficient to collect a large number of active email addresses to try (sniffing at Tor gateways could provide interesting results, come to think of it). Another big winner for mailbox collection is to not crack the information provider's site, but to instead crack the email service provider and obtain a list of all active accounts on that server (which would likely span multiple domains).
In the example I mentioned, it was a specially created single purpose email SMTP address (no POP etc.) used just once about 5? months ago. It is easy for me to block it as the mail server (MTA Mail Transfer Agent) which I have done.
Getting a hold of email accounts can happen any number of ways, most of them uncontrollable by the account holder. Its a mailbox -- an open destination for the world to send you stuff. You can't be too surprised when the world does in fact send you stuff.
We are no so liberal with mailboxes. Some can be accessed only by prior approved senders. Others, because they are single purpose email addresses, can be permanently blocked after the first unwanted email. Some email addresses are created with sub-domains that can be dropped at the first abuse then replaced by new sub-domains.
The difference between deposit/fetch and send/receive is profound. This is part of why I'm surprised that newsreaders and forums have fallen from favor amongst technical discussion groups. The "Logging into forums is a PITA" or "setting up another client is a PITA" arguments obviously won the debate -- though I think spam is a lot deeper into PITA territory than either at the present time.
The problems with forums are, in my personal opinion:-
(1) Spyware : logging every access with Google the USA's international spying operation.
(2) Advertisements
(3) tiny text difficult to read
(4) Pop-up windows
(5) Layout not conducive to easy and quick reading.
(6) Having to visit a web site and then log-on if one wants to respond.
Conversely:-
Email Lists are quick, easy, immediate (certainly for my set-up), require no extra effort. Should the address get spammed, then its one quick and simple change:-
(a) replacement DNS sub-domain
(b) update Mailman
(c) change email address in email client.
On Mon, 2011-07-18 at 15:00 +0100, Always Learning wrote:
In the example I mentioned, it was a specially created single purpose email SMTP address (no POP etc.) used just once about 5? months ago. It is easy for me to block it as the mail server (MTA Mail Transfer Agent) which I have done.
An address can get snagged once after a single use and spammed months later. Creating a plethora of special use email accounts is, in my opinion, simply too much effort when the original design of email was to create a public address that anyone can contact the owner through.
We are no so liberal with mailboxes. Some can be accessed only by prior approved senders. Others, because they are single purpose email addresses, can be permanently blocked after the first unwanted email. Some email addresses are created with sub-domains that can be dropped at the first abuse then replaced by new sub-domains.
Getting too creative with email protections reduces the primary functionality it was invented to provide.
The difference between deposit/fetch and send/receive is profound. This is part of why I'm surprised that newsreaders and forums have fallen from favor amongst technical discussion groups. The "Logging into forums is a PITA" or "setting up another client is a PITA" arguments obviously won the debate -- though I think spam is a lot deeper into PITA territory than either at the present time.
The problems with forums are, in my personal opinion:-
(1) Spyware : logging every access with Google the USA's international spying operation.
Mailing lists do not avoid this (if they do, please explain how), particularly now that Google has people using its own parallel DNS service (!o!) and runs infrastructure that most of these tech mailing lists touch at some point. At this point I doubt that there is a message sent that doesn't touch or at least bounce toward a Google-owned server somewhere.
(2) Advertisements
On a bad forum, yes. On good ones, no. The advertising thing is ridiculous and a symptom of our community not realizing how easy it is to self-host forums for free (or newsgroups -- but more on that later).
(3) tiny text difficult to read
On bad forums, maybe. I haven't been to a site I found difficult to read, come to think of it, but I'm sure there are some administrators out there who don't understand the concepts of usability. Anyway, you can generally control your mail display settings and forums would present a potentially mixed bag unless the community settled on a rough standard, so I can see your point here.
(4) Pop-up windows
On unbearably crap forums, maybe. I've never experienced this (Firefox always saved me or there just were never pop ups? No idea), but if any official project decided to use forums as a primary communication means and put not just ads, but *pop-up ads* on their site -- wow...
(5) Layout not conducive to easy and quick reading.
The free-form layout of mailing lists (top/bottom/mid posting all mishmashed) is far less conducive to organized eye movements, in my experience. Obviously, you and I may have adapted differently, though I find neither difficult.
(6) Having to visit a web site and then log-on if one wants to respond.
I keychain the logins (I think most browsers have a function like this now -- I think even elinks does, and elinks is a great way to browse forums, btw) and don't worry too much with it after that.
I find this to be a *lot* less trouble than twisting my email setup into something email was never intended to be.
Conversely:-
Email Lists are quick, easy, immediate (certainly for my set-up), require no extra effort. Should the address get spammed, then its one quick and simple change:-
(a) replacement DNS sub-domain
(b) update Mailman
(c) change email address in email client.
Again, far too much trouble.
So... what is wrong with newsreaders? In my experience the provide all the benefits of email (speed, uniform interface, etc.) that you listed as well as all the benefits of a post/fetch paradigm that I get from forums without any of the hassles of either.
That we aren't communicating through a newsgroup has always been puzzling to me for the exact reasons that you and I both listed. If we were to design a new protocol to solve both problems it would likely turn out to be very like newsgroups -- yet we don't use them and they exist and are easy to set up.
Anyway, interesting response. Cheers.
-Iwao
On Tue, 2011-07-19 at 00:27 +0900, 夜神 岩男 wrote:
(1) Spyware : logging every access with Google the USA's international spying operation.
Mailing lists do not avoid this (if they do, please explain how), particularly now that Google has people using its own parallel DNS service (!o!) and runs infrastructure that most of these tech mailing lists touch at some point. At this point I doubt that there is a message sent that doesn't touch or at least bounce toward a Google-owned server somewhere.
Not the message contents but the IP address, browser details of the user reading the forum. All added to the user's IP record at Google Monitoring.
On 7/18/2011 10:27 AM, 夜神 岩男 wrote:
(6) Having to visit a web site and then log-on if one wants to respond.
I keychain the logins (I think most browsers have a function like this now -- I think even elinks does, and elinks is a great way to browse forums, btw) and don't worry too much with it after that.
So do you typically provide helpful answers to forum questions sooner after they are posted when you have to forum-hop than you would if they land in your inbox or later?
I find this to be a *lot* less trouble than twisting my email setup into something email was never intended to be.
Email wasn't intended for receiving messages and replying? Hmmm...
So... what is wrong with newsreaders? In my experience the provide all the benefits of email (speed, uniform interface, etc.) that you listed as well as all the benefits of a post/fetch paradigm that I get from forums without any of the hassles of either.
Interesting that you bring this up in the context of spam. The problem with net news is that all of the servers stopped handling it because of the porn and copyright-infringing binaries postings that overwhelm it.
That we aren't communicating through a newsgroup has always been puzzling to me for the exact reasons that you and I both listed. If we were to design a new protocol to solve both problems it would likely turn out to be very like newsgroups -- yet we don't use them and they exist and are easy to set up.
A news service with censorship might be OK. Until they censor something that you wanted to say or see. Forums with rss feeds might be a middle ground to centralize the reading side but there's still the issue of standardizing the forum interfaces so you don't have to figure out how to reply again for every interesting topic.
On Mon, 2011-07-18 at 10:54 -0500, Les Mikesell wrote:
On 7/18/2011 10:27 AM, 夜神 岩男 wrote:
(6) Having to visit a web site and then log-on if one wants to respond.
I keychain the logins (I think most browsers have a function like this now -- I think even elinks does, and elinks is a great way to browse forums, btw) and don't worry too much with it after that.
So do you typically provide helpful answers to forum questions sooner after they are posted when you have to forum-hop than you would if they land in your inbox or later?
Obviously some level of activity must be maintained within a community to ensure decent response times, but newer communities such as Ubuntu have found forums to be a fairly useful thing. The forum community there is doing well and questions get answered at a reasonable pace -- with the added benefit that when someone goes on vacation they have no box that needs filtering, unsubscribing, setting in a vacation state, etc. to protect from lists or spam. Outside of the tech world forums have proven themselves durable and usable for help and feedback purposes -- overwhelmingly so.
I find this to be a *lot* less trouble than twisting my email setup into something email was never intended to be.
Email wasn't intended for receiving messages and replying? Hmmm...
It was designed precisely to do those things. What was described by the previous poster was time consuming contrivances with the specific intent of limiting the receipt of messages -- which is exactly half of the specification as you stated it.
So... what is wrong with newsreaders? In my experience the provide all the benefits of email (speed, uniform interface, etc.) that you listed as well as all the benefits of a post/fetch paradigm that I get from forums without any of the hassles of either.
Interesting that you bring this up in the context of spam. The problem with net news is that all of the servers stopped handling it because of the porn and copyright-infringing binaries postings that overwhelm it.
Newsreaders require a news server. News servers can be run by anyone, it doesn't require a global cabal to serve news. In the later days of usenet it was overwhelmed by crap, largely because of the enormous number of groups created by people who didn't have time to maintain them, had a blanket anonymous publish policy, and eventually never showed back up to take care of their lists. Lists such as that got swamped, and so did the servers, which made the whole system unweidly (though news server networks are still run today and moderation via user validation is still an option).
What I am describing is the running of a newsgroup server specific to a project or interest, say news.centos.org (or whatever for whatever). Initial validation would be required (not unusual for mailing lists) for initial posting, and after that unmoderated publication would be permitted by a validated user. This is a simple system. Disabling attachments and/or setting file/message size limits is trivial and is an action which occurs in just one place (the server) and doesn't bother the users.
From an anti-spam/security perspective a post/fetch system is simply
more suitable for noise-free discourse than email. That we have forgotten that is likely more due to the timing of the web explosion in the early 90's and the tech/generation gap it produced than anything else.
A news service with censorship might be OK. Until they censor something that you wanted to say or see. Forums with rss feeds might be a middle ground to centralize the reading side but there's still the issue of standardizing the forum interfaces so you don't have to figure out how to reply again for every interesting topic.
You have just described properly run newsgroups -- and why I am suggesting them as a reasonable course of action which would resolve spam issues not just within list, but limit everyone's exposure to spam in their general mail boxes.
-Iwao
On 7/18/2011 11:25 AM, 夜神 岩男 wrote:
So do you typically provide helpful answers to forum questions sooner after they are posted when you have to forum-hop than you would if they land in your inbox or later?
Obviously some level of activity must be maintained within a community to ensure decent response times, but newer communities such as Ubuntu have found forums to be a fairly useful thing. The forum community there is doing well and questions get answered at a reasonable pace -- with the added benefit that when someone goes on vacation they have no box that needs filtering, unsubscribing, setting in a vacation state, etc. to protect from lists or spam. Outside of the tech world forums have proven themselves durable and usable for help and feedback purposes -- overwhelmingly so.
I don't think Ubuntu is a reasonable project example unless you can come up with a way to match it's resources, which I believe include paid participants. Who is going to hover over a forum waiting to answer questions otherwise?
So... what is wrong with newsreaders? In my experience the provide all the benefits of email (speed, uniform interface, etc.) that you listed as well as all the benefits of a post/fetch paradigm that I get from forums without any of the hassles of either.
Interesting that you bring this up in the context of spam. The problem with net news is that all of the servers stopped handling it because of the porn and copyright-infringing binaries postings that overwhelm it.
Newsreaders require a news server. News servers can be run by anyone, it doesn't require a global cabal to serve news. In the later days of usenet it was overwhelmed by crap, largely because of the enormous number of groups created by people who didn't have time to maintain them, had a blanket anonymous publish policy, and eventually never showed back up to take care of their lists.
You make it sound accidental. That's not the way I remember it.
What I am describing is the running of a newsgroup server specific to a project or interest, say news.centos.org (or whatever for whatever). Initial validation would be required (not unusual for mailing lists) for initial posting, and after that unmoderated publication would be permitted by a validated user. This is a simple system. Disabling attachments and/or setting file/message size limits is trivial and is an action which occurs in just one place (the server) and doesn't bother the users.
So if you have 100 interests, you'd have to establish and maintain 100 logins and passwords - and configure them on every device/application you use for access. That's not my idea of convenience.
From an anti-spam/security perspective a post/fetch system is simply more suitable for noise-free discourse than email.
I just don't see the distinction other than having more possibility of after-the-fact cleanup before delivery - and then only if someone goes to the trouble of doing it and you are slow in your fetching.
That we have forgotten that is likely more due to the timing of the web explosion in the early 90's and the tech/generation gap it produced than anything else.
Ummm, no. There was always a lot more crap posted to usenet than there is here. Maybe you've forgotten that.
A news service with censorship might be OK. Until they censor something that you wanted to say or see. Forums with rss feeds might be a middle ground to centralize the reading side but there's still the issue of standardizing the forum interfaces so you don't have to figure out how to reply again for every interesting topic.
You have just described properly run newsgroups -- and why I am suggesting them as a reasonable course of action which would resolve spam issues not just within list, but limit everyone's exposure to spam in their general mail boxes.
The protocol for the transfer doesn't really matter here. What you propose isn't particularly different than setting up local email service with accounts for all users for every list. That is, it would be equally inconvenient and not solve any of the underlying problems.
On 07/18/2011 01:00 PM, Les Mikesell wrote:
On 7/18/2011 11:25 AM, ?? ?? wrote:
So do you typically provide helpful answers to forum questions sooner after they are posted when you have to forum-hop than you would if they land in your inbox or later?
Obviously some level of activity must be maintained within a community to ensure decent response times, but newer communities such as Ubuntu have found forums to be a fairly useful thing. The forum community there is doing well and questions get answered at a reasonable pace -- with the added benefit that when someone goes on vacation they have no box that needs filtering, unsubscribing, setting in a vacation state, etc. to protect from lists or spam. Outside of the tech world forums have proven themselves durable and usable for help and feedback purposes -- overwhelmingly so.
I don't think Ubuntu is a reasonable project example unless you can come up with a way to match it's resources, which I believe include paid participants. Who is going to hover over a forum waiting to answer questions otherwise?
So... what is wrong with newsreaders? In my experience the provide all the benefits of email (speed, uniform interface, etc.) that you listed as well as all the benefits of a post/fetch paradigm that I get from forums without any of the hassles of either.
Interesting that you bring this up in the context of spam. The problem with net news is that all of the servers stopped handling it because of the porn and copyright-infringing binaries postings that overwhelm it.
Newsreaders require a news server. News servers can be run by anyone, it doesn't require a global cabal to serve news. In the later days of usenet it was overwhelmed by crap, largely because of the enormous number of groups created by people who didn't have time to maintain them, had a blanket anonymous publish policy, and eventually never showed back up to take care of their lists.
You make it sound accidental. That's not the way I remember it.
What I am describing is the running of a newsgroup server specific to a project or interest, say news.centos.org (or whatever for whatever). Initial validation would be required (not unusual for mailing lists) for initial posting, and after that unmoderated publication would be permitted by a validated user. This is a simple system. Disabling attachments and/or setting file/message size limits is trivial and is an action which occurs in just one place (the server) and doesn't bother the users.
So if you have 100 interests, you'd have to establish and maintain 100 logins and passwords - and configure them on every device/application you use for access. That's not my idea of convenience.
From an anti-spam/security perspective a post/fetch system is simply more suitable for noise-free discourse than email.
I just don't see the distinction other than having more possibility of after-the-fact cleanup before delivery - and then only if someone goes to the trouble of doing it and you are slow in your fetching.
That we have forgotten that is likely more due to the timing of the web explosion in the early 90's and the tech/generation gap it produced than anything else.
Ummm, no. There was always a lot more crap posted to usenet than there is here. Maybe you've forgotten that.
A news service with censorship might be OK. Until they censor something that you wanted to say or see. Forums with rss feeds might be a middle ground to centralize the reading side but there's still the issue of standardizing the forum interfaces so you don't have to figure out how to reply again for every interesting topic.
You have just described properly run newsgroups -- and why I am suggesting them as a reasonable course of action which would resolve spam issues not just within list, but limit everyone's exposure to spam in their general mail boxes.
The protocol for the transfer doesn't really matter here. What you propose isn't particularly different than setting up local email service with accounts for all users for every list. That is, it would be equally inconvenient and not solve any of the underlying problems.
Hmm... I am on a number of ML one of which is LKML and I find the amount of spam is miniscule in comparison to the number of messages.
Also trying to keep up with all the topics and new threads on any forum I have been on seems much more difficult than on any mailing list.
I have thunderbird setup to read mail threaded and if its a thread I am not interested a simple CTL-t marks any new messages as read.
My $.02
Regards, Steve
On 07/18/2011 02:37 PM, Steve Clark wrote:
On 07/18/2011 01:00 PM, Les Mikesell wrote:
On 7/18/2011 11:25 AM, ?? ?? wrote:
So do you typically provide helpful answers to forum questions sooner after they are posted when you have to forum-hop than you would if they land in your inbox or later?
Obviously some level of activity must be maintained within a community to ensure decent response times, but newer communities such as Ubuntu have found forums to be a fairly useful thing. The forum community there is doing well and questions get answered at a reasonable pace -- with the added benefit that when someone goes on vacation they have no box that needs filtering, unsubscribing, setting in a vacation state, etc. to protect from lists or spam. Outside of the tech world forums have proven themselves durable and usable for help and feedback purposes -- overwhelmingly so.
I don't think Ubuntu is a reasonable project example unless you can come up with a way to match it's resources, which I believe include paid participants. Who is going to hover over a forum waiting to answer questions otherwise?
So... what is wrong with newsreaders? In my experience the provide all the benefits of email (speed, uniform interface, etc.) that you listed as well as all the benefits of a post/fetch paradigm that I get from forums without any of the hassles of either.
Interesting that you bring this up in the context of spam. The problem with net news is that all of the servers stopped handling it because of the porn and copyright-infringing binaries postings that overwhelm it.
Newsreaders require a news server. News servers can be run by anyone, it doesn't require a global cabal to serve news. In the later days of usenet it was overwhelmed by crap, largely because of the enormous number of groups created by people who didn't have time to maintain them, had a blanket anonymous publish policy, and eventually never showed back up to take care of their lists.
You make it sound accidental. That's not the way I remember it.
What I am describing is the running of a newsgroup server specific to a project or interest, say news.centos.org (or whatever for whatever). Initial validation would be required (not unusual for mailing lists) for initial posting, and after that unmoderated publication would be permitted by a validated user. This is a simple system. Disabling attachments and/or setting file/message size limits is trivial and is an action which occurs in just one place (the server) and doesn't bother the users.
So if you have 100 interests, you'd have to establish and maintain 100 logins and passwords - and configure them on every device/application you use for access. That's not my idea of convenience.
From an anti-spam/security perspective a post/fetch system is simply more suitable for noise-free discourse than email.
I just don't see the distinction other than having more possibility of after-the-fact cleanup before delivery - and then only if someone goes to the trouble of doing it and you are slow in your fetching.
That we have forgotten that is likely more due to the timing of the web explosion in the early 90's and the tech/generation gap it produced than anything else.
Ummm, no. There was always a lot more crap posted to usenet than there is here. Maybe you've forgotten that.
A news service with censorship might be OK. Until they censor something that you wanted to say or see. Forums with rss feeds might be a middle ground to centralize the reading side but there's still the issue of standardizing the forum interfaces so you don't have to figure out how to reply again for every interesting topic.
You have just described properly run newsgroups -- and why I am suggesting them as a reasonable course of action which would resolve spam issues not just within list, but limit everyone's exposure to spam in their general mail boxes.
The protocol for the transfer doesn't really matter here. What you propose isn't particularly different than setting up local email service with accounts for all users for every list. That is, it would be equally inconvenient and not solve any of the underlying problems.
Hmm... I am on a number of ML one of which is LKML and I find the amount of spam is miniscule in comparison to the number of messages.
Also trying to keep up with all the topics and new threads on any forum I have been on seems much more difficult than on any mailing list.
I have thunderbird setup to read mail threaded and if its a thread I am not interested a simple CTL-t marks any new messages as read.
oops should have been just 't' not ctl-t.
å¤ç¥ å²©ç· wrote:
On Mon, 2011-07-18 at 10:54 -0500, Les Mikesell wrote:
On 7/18/2011 10:27 AM, å¤ç¥ å²©ç· wrote:
<snip>
So... what is wrong with newsreaders? In my experience the provide all the benefits of email (speed, uniform interface, etc.) that you listed as well as all the benefits of a post/fetch paradigm that I get from forums without any of the hassles of either.
Interesting that you bring this up in the context of spam. The problem with net news is that all of the servers stopped handling it because of the porn and copyright-infringing binaries postings that overwhelm it.
Newsreaders require a news server. News servers can be run by anyone, it doesn't require a global cabal to serve news. In the later days of usenet it was overwhelmed by crap, largely because of the enormous number of groups created by people who didn't have time to maintain them, had a blanket anonymous publish policy, and eventually never showed back up to take care of their lists. Lists such as that got swamped, and so did the servers, which made the whole system unweidly (though news server networks are still run today and moderation via user validation is still an option).
The beginning of its downhill slide, IMO, was when AOL got on. I remember that happening: AOL auto-subscribed *all* its users to certain newsgroups, and for some utterly clueless reason, that included alt.best.of.internet. I occasionally dipped into that group, and the flamewars started then, with idiots announcing that they could post anything they wanted, anywhere they wanted. That, and the Green Card Spam, where K&S proclaimed that there was no such thing as "community", that it was all the wild west.
What I am describing is the running of a newsgroup server specific to a project or interest, say news.centos.org (or whatever for whatever).
A big eight newsgroup, moderated, is what this sounds like. Let me note that if you want, I can point you to a quite good robomoderator: it approves regular posters, checks new for on-topic, and if it can't make up its mind, forwards it to designated human moderators. <snip>
mark
On 7/17/11 9:37 PM, Stephen Harris wrote:
On Sun, Jul 17, 2011 at 09:07:38PM -0500, Les Mikesell wrote:
There is no requirement for the greeting name to match any IP, and isn't likely
RFC2821 says: - The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
So, pretty much, HELO or EHLO greeting _must_ match to an IP.
(RFC821 actually wanted the HELO to match the connecting host, but 2821 just says it must be an A record or an address literal).
That's a long way for saying it MUST be the name of that particular host (which might be one of many in a cluster sharing a name) or that it MUST use the name of the interface that it happens to use for a particular connection, or that its own interface IP MUST be what connects to the target with no NAT involved. Saying any of those things would make it very difficult for mail services to scale.
On Sun, 2011-07-17 at 22:12 -0500, Les Mikesell wrote:
On 7/17/11 9:37 PM, Stephen Harris wrote:
(RFC821 actually wanted the HELO to match the connecting host, but 2821 just says it must be an A record or an address literal).
That's a long way for saying it MUST be the name of that particular host (which might be one of many in a cluster sharing a name) or that it MUST use the name of the interface that it happens to use for a particular connection, or that its own interface IP MUST be what connects to the target with no NAT involved. Saying any of those things would make it very difficult for mail services to scale.
Sorry if I seem thick but I am having problems understanding why, with the use of NAT, the HELO/EHLO and their external IP address can not match. Also what influences does scaling have on the ability of sending mail servers (MTAs) to operate with host names that match their IP addresses ?
Thanks.
On 7/17/11 10:26 PM, Always Learning wrote:
Sorry if I seem thick but I am having problems understanding why, with the use of NAT, the HELO/EHLO and their external IP address can not match.
I suppose it is not impossible if you force a 1 to 1 correspondence.
Also what influences does scaling have on the ability of sending mail servers (MTAs) to operate with host names that match their IP addresses ?
NATs are often pools of addresses, often managed by different groups than the host services, and sometimes used in sets with different address mappings to allow load balancing and failover across multiple isp connections. If mail is your only service, you might give all of those addresses the reverse DNS name that matches your HELO name, but most places would probably just do what the standards require.
On 7/18/11, Always Learning centos@u6.u22.net wrote:
Sorry if I seem thick but I am having problems understanding why, with the use of NAT, the HELO/EHLO and their external IP address can not match. Also what influences does scaling have on the ability of sending mail servers (MTAs) to operate with host names that match their IP addresses ?
I'm trying to make sense of your suggestion and the objections raised, since I do want to cut down on spam coming into my own server but at the same time I don't want to cut off legit senders.
So far it seems to me that in for larger corps, this is what the problem might be.
Say they have 3 different connections for redundancy, one serves aaa.bbb.ccc.1x, another serve aaa.bbb.ccc.2x and the last .3x
And they have a bunch of services running on various servers, say 10 of them. each with their own hostname e.g. mail1.xyzcorp.com, mail2.xyzcorp.com
For troubleshooting/tracing purposes, they use different HELO/EHLO names for the servers and each mail server has their own IP range in the aaa.bbb.ccc.xx net.
Since they have less outgoing connections than SMTP servers, their router load balance the outgoing amongst the 3 connections.
So in this case, mail2.xyzcorp.com which HELO with aaa.bbb.ccc.11 may get sent out via the aaa.bbb.ccc.20 or aaa.bbb.ccc.30 connection and by your rules get blocked despite being legit.
At least that's how I'm understanding it but I don't admin any site large enough to know if things are ever set up like that.
On Sun, Jul 17, 2011 at 10:12:16PM -0500, Les Mikesell wrote:
On 7/17/11 9:37 PM, Stephen Harris wrote:
On Sun, Jul 17, 2011 at 09:07:38PM -0500, Les Mikesell wrote:
There is no requirement for the greeting name to match any IP, and isn't likely
RFC2821 says: - The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
So, pretty much, HELO or EHLO greeting _must_ match to an IP.
(RFC821 actually wanted the HELO to match the connecting host, but 2821 just says it must be an A record or an address literal).
That's a long way for saying it MUST be the name of that particular host (which
I addessed that in the parenthetical; 821 did require it; 2821 doesn't.
On 7/18/11 5:43 AM, Stephen Harris wrote:
On Sun, Jul 17, 2011 at 10:12:16PM -0500, Les Mikesell wrote:
On 7/17/11 9:37 PM, Stephen Harris wrote:
On Sun, Jul 17, 2011 at 09:07:38PM -0500, Les Mikesell wrote:
There is no requirement for the greeting name to match any IP, and isn't likely
RFC2821 says: - The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
So, pretty much, HELO or EHLO greeting _must_ match to an IP.
(RFC821 actually wanted the HELO to match the connecting host, but 2821 just says it must be an A record or an address literal).
That's a long way for saying it MUST be the name of that particular host (which
I addessed that in the parenthetical; 821 did require it; 2821 doesn't.
Can you point me to the section? I don't see anything there about the hostname having to match an interface address or being allowed to reject if it isn't - or even any advice on how clustered hosts representing one mail domain should represent themselves.
On Mon, Jul 18, 2011 at 07:41:09AM -0500, Les Mikesell wrote:
On 7/18/11 5:43 AM, Stephen Harris wrote:
RFC2821 says: - The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
So, pretty much, HELO or EHLO greeting _must_ match to an IP.
(RFC821 actually wanted the HELO to match the connecting host, but 2821 just says it must be an A record or an address literal).
Can you point me to the section? I don't see anything there about the hostname having to match an interface address or being allowed to reject if it isn't - or even any advice on how clustered hosts representing one mail domain should represent themselves.
I think you think I'm disagreeing with you; I'm not. I'm agreeing with you. The RFCs don't require the SMTP server to match the interface IP address.
Note that RFC821 has been obsoleted and replaced with 2821. Anyone programming to 821 requirements is doing it wrong. In fact 2821 has been replaced with 5321
5321 says 2.3.5 [...] The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4.
I think that reference to 4.1.4 should really be 4.1.1.1...
4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP server. The argument clause contains the fully-qualified domain name of the SMTP client, if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see Section 4.1.3).
You only need to follow 5321 requirements which do _not_ require the host to identify it as matching the specific interface; it merely needs to identify as a valid A record (or address literal) for the client system.
There's nothing to say that the client system need be listening to port 25 (or be open to port 25 connections; firewalls for example), so anyone performing HELO (or EHLO) address verification is pretty much limited to the 2.3.5 requirement; that the passed name is _a_ valid name. Which is, AFAIK, all postfix does.
On Monday, July 18, 2011 09:19 PM, Stephen Harris wrote:
SPAM-L is that way ==> oh wait, it's dead...
Maybe we can keep discussions about blackhat, incompetent networks, about SMTP, open proxies/relays, honeypots and what have you off this list?
Just limit it to sendmail/postfix/exim configuration if you have to discuss these things but please leave everything else outside in NANAE/your favourite spitting pot.
On Mon, 2011-07-18 at 22:17 +0800, Christopher Chan wrote:
On Monday, July 18, 2011 09:19 PM, Stephen Harris wrote:
SPAM-L is that way ==> oh wait, it's dead...
Maybe we can keep discussions about blackhat, incompetent networks, about SMTP, open proxies/relays, honeypots and what have you off this list?
Just limit it to sendmail/postfix/exim configuration if you have to discuss these things but please leave everything else outside in NANAE/your favourite spitting pot.
You wouldn't be insinuating that "[CentOS] SPAM on the list" has become SPAM on the list now, would you?
-Iwao
On Monday, July 18, 2011 11:29 PM, 夜神 岩男 wrote:
On Mon, 2011-07-18 at 22:17 +0800, Christopher Chan wrote:
On Monday, July 18, 2011 09:19 PM, Stephen Harris wrote:
SPAM-L is that way ==> oh wait, it's dead...
Maybe we can keep discussions about blackhat, incompetent networks, about SMTP, open proxies/relays, honeypots and what have you off this list?
Just limit it to sendmail/postfix/exim configuration if you have to discuss these things but please leave everything else outside in NANAE/your favourite spitting pot.
You wouldn't be insinuating that "[CentOS] SPAM on the list" has become SPAM on the list now, would you?
Kinda hard...I mean, SPAM is edible you know and I don't remember being able to transport SPAM over email.
But it has become offtopic and is no longer relevant to Centos. We don't need another SPAM-L/NANAE/whatever
--On Sunday, July 17, 2011 10:37:53 PM -0400 Stephen Harris lists@spuddy.org wrote:
RFC2821 says:
- The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
So, pretty much, HELO or EHLO greeting _must_ match to an IP.
(RFC821 actually wanted the HELO to match the connecting host, but 2821 just says it must be an A record or an address literal).
Thank you for posting that.
Despite the garden path we got down, my previous comments didn't say that you had to accept *anything*, but merely that too stringent of a check would eliminate some valid mailers. There's nothing like stirring a can of worms :)
Devin
On 07/17/2011 11:24 PM, Always Learning wrote:
*almost* correct. In Linux, like Unix and the pre-Microsoft days, uppercase letters have a different numerical value to lowercase letters.
Uppercase 'COM' is definitely not the same as lowercase 'com'.
Please correct me if I am wrong but afaik upper-/lowercase does not matter in DNS. Also, I am not aware of e.g. Postfix actually rejecting (with reject_unknown_client_hostname) a FQDN with capitals when a FQDN in lowercase was expected.
Regards, Patrick
On Sun, 2011-07-17 at 23:36 +0200, Patrick Lists wrote:
On 07/17/2011 11:24 PM, Always Learning wrote:
Uppercase 'COM' is definitely not the same as lowercase 'com'.
Please correct me if I am wrong but afaik upper-/lowercase does not matter in DNS. Also, I am not aware of e.g. Postfix actually rejecting (with reject_unknown_client_hostname) a FQDN with capitals when a FQDN in lowercase was expected.
Nee hoor. You are correct. kopie, kopie :-)
On Sun, Jul 17, 2011 at 11:36:49PM +0200, Patrick Lists wrote:
On 07/17/2011 11:24 PM, Always Learning wrote:
*almost* correct. In Linux, like Unix and the pre-Microsoft days, uppercase letters have a different numerical value to lowercase letters.
Uppercase 'COM' is definitely not the same as lowercase 'com'.
Please correct me if I am wrong but afaik upper-/lowercase does not matter in DNS. Also, I am not aware of e.g. Postfix actually rejecting (with reject_unknown_client_hostname) a FQDN with capitals when a FQDN in lowercase was expected.
Postfix HELO verification simply does the relevant DNS lookups; if they succeed then the HELO is OK.
Postfix IP verification does the IP rDNS lookup, then a forward lookup of the result; if the result set includes the original IP then it succeeds.
Case doesn't matter unless the underlying DNS libraries somehow break on case. Which they shouldn't :-)
In the example given earlier:
HELO / EHLO: smtpe1.intersmtp.com HELO IP: 62.239.224.89 MX IP: 62.239.224.234 MX DNS A record: smtp61.intersmtp.com
The HELO name successfully resolves to 62.239.224.89, so passes.
Now the source IP address isn't given but if it was 62.239.224.89 then postfix would have done 62.239.224.89 -> smtpe1.intersmtp.COM. and then smtpe1.intersmtp.COM. -> 62.239.224.89 Since the final IP address matches the source IP address then the connecting IP address check would also have passed.
You'll note the MX IP and A records aren't actually involved, in this case!
After 5+ years of running these checks myself, I finally got fed up with all the stupid companies who had broken DNS (including banks and ISPs and Fortune 500 companies - my "white list" made 99 entries!) that I eventually turned it off and just use the Zen RBL. It lets through spam that the stricter checks would reject, but it's good enough.
Always Learning wrote:
Do your Mail Transfer Agents use valid or bogus HELO/EHLO names ?
Mine uses proper name, but then again I am one of the few in my country to offer POP3 on SSL port 465. And I am small local WISP.
And when I say *few*, I mean I do not actually *know* of any mail server in Serbia offering this.
Ljubomir
On Sun, 2011-07-17 at 23:52 +0200, Ljubomir Ljubojevic wrote:
Always Learning wrote:
Do your Mail Transfer Agents use valid or bogus HELO/EHLO names ?
Mine uses proper name, but then again I am one of the few in my country to offer POP3 on SSL port 465. And I am small local WISP.
And when I say *few*, I mean I do not actually *know* of any mail server in Serbia offering this.
Congratulations.
I fear with the introduction of IP6, it may be more difficult to separate spammers from non-spammers using fake IDs.
On 17.7.2011 23:52, Ljubomir Ljubojevic wrote:
Always Learning wrote:
Do your Mail Transfer Agents use valid or bogus HELO/EHLO names ?
Mine uses proper name, but then again I am one of the few in my country to offer POP3 on SSL port 465. And I am small local WISP.
Probably you meant smtps (smtp over ssl) not pop3.
-- Kind Regards, Markus Falb
Markus Falb wrote:
On 17.7.2011 23:52, Ljubomir Ljubojevic wrote:
Always Learning wrote:
Do your Mail Transfer Agents use valid or bogus HELO/EHLO names ?
Mine uses proper name, but then again I am one of the few in my country to offer POP3 on SSL port 465. And I am small local WISP.
Probably you meant smtps (smtp over ssl) not pop3.
-- Kind Regards, Markus Falb
Yes, you are right. SMTPS. thinking one thing and writing another is not good. Nice catch, thanks.
Devin Reade wrote:
Ljubomir Ljubojevic office@plnet.rs wrote:
I use it too. Reverse-DNS check is best SPAM repellent there is. Only mail from properly set mail servers is accepted.
That's fine if your check is that a reverse DNS entry exists, or that the HELO/ELHO exists in forward DNS or, if your MTA is smart enough, it does a reverse-forward* check, but if you only check that the HELO/ELHO matches the reverse entry then you're blocking a bunch of valid mailers because there is no specification requirement that those two match (and they don't in the general case).
(*) reverse-forward here means do a reverse lookup on the connecting IP, then doing a forward lookup on the result, and then ensure that original IP is one of the 'A' records resolved from the forward lookup.
Devin
I only check reverse DNS entry for FQDN, I think HELO/EHLO is not checked.
Ljubomir
-
Alexander Dalloz -
Always Learning -
Christopher Chan -
Devin Reade -
dr.virus.india＠gmail.com -
Emmanuel Noobadmin -
John R. Dennison -
KevinO -
Les Mikesell -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
Mark Weaver -
Markus Falb -
Patrick Lists -
Stephen Harris -
Steve Clark -
夜神 岩男