I've noticed that the following hosts are impersonated (in HELO greetings) significantly more often than any others: smtp.comunitel.net smtp.orange.es smtp.jazztel.es Anyone know why? And these are all in Spain, in particular. Do Spaniards lack imagination or what? A distant fourth would be: mail.sanmail.ru -Philip
--- On Fri, 6/1/12, Philip Prindeville <philipp_subx <at> redfish-solutions.com> wrote: > I've noticed that the following hosts are impersonated (in HELO > greetings) significantly more often than any others: > > smtp.comunitel.net > smtp.orange.es > smtp.jazztel.es > > Anyone know why? And these are all in Spain, in particular. > Do Spaniards lack imagination or what? A distant fourth would be: > > mail.sanmail.ru No idea here. However, as long as the "HELO" hostname is valid (and not your host's name or "localhost" unless the connection is actually from you), it is acceptable under the RFCs/standards. Multi-homed hosts can have mismatches because the name given is supposed to be the "primary" name while DNS will return the interface name (which need NOT match). Random thought: Both the SPF and MTX solutions to validate sending servers could be applied to the HELO name in some way, but I suggest scoring only -- no outright rejections at this time. See if a further trend develops.
On 6/1/12 1:53 PM, kd6lvw <at> yahoo.com wrote: > No idea here. However, as long as the "HELO" hostname is valid (and not your host's name or "localhost" unless the connection is actually from you), it is acceptable under the RFCs/standards. Multi-homed hosts can have mismatches because the name given is supposed to be the "primary" name while DNS will return the interface name (which need NOT match). > > Random thought: Both the SPF and MTX solutions to validate sending servers could be applied to the HELO name in some way, but I suggest scoring only -- no outright rejections at this time. See if a further trend develops. I've noticed that the impersonations inevitably come from DHCP address pools according to ZenBL. May 27 03:25:33 mail mimedefang.pl[32097]: helo: 89.234.77.188.dynamic.jazztel.es (188.77.234.89:50758) said "helo smtp.jazztel.es" May 27 03:25:34 mail mimedefang.pl[32097]: filter_helo rejected helo smtp.jazztel.es May 27 03:25:34 mail sendmail[1719]: q4R9PSpP001719: Milter: helo=smtp.jazztel.es, reject=554 5.7.1 This address is on ZenBL as 127.0.0.11 May 27 04:34:45 mail mimedefang.pl[32097]: helo: [212.231.249.48] (212.231.249.48:1887) said "helo mail.sanmail.ru" May 27 04:34:45 mail mimedefang.pl[32097]: filter_helo rejected helo mail.sanmail.ru May 27 04:34:45 mail sendmail[2037]: q4RAYdpX002037: Milter: helo=mail.sanmail.ru, reject=554 5.7.1 This address is on ZenBL as 127.0.0.4 May 27 04:42:03 mail mimedefang.pl[32097]: helo: 9.66.218.87.dynamic.jazztel.es (87.218.66.9:3248) said "helo smtp.jazztel.es" May 27 04:42:03 mail mimedefang.pl[32097]: filter_helo rejected helo smtp.jazztel.es May 27 04:42:03 mail sendmail[2055]: q4RAfsHJ002055: Milter: helo=smtp.jazztel.es, reject=554 5.7.1 This address is on ZenBL as 127.0.0.11 May 27 08:53:35 mail mimedefang.pl[2231]: helo: [85.52.167.76] (85.52.167.76:2689) said "helo smtp.orange.es" May 27 08:53:35 mail mimedefang.pl[2231]: filter_helo tempfailed helo smtp.orange.es May 27 08:53:35 mail sendmail[2914]: q4RErTkM002914: Milter: helo=smtp.orange.e, reject=451 4.3.0 No rDNS records found; try again when you've properly configured your DNS.(Continue reading)
--- On Fri, 6/1/12, Philip Prindeville <philipp_subx <at> redfish-solutions.com> wrote: > I've noticed that the impersonations inevitably come from > DHCP address pools according to ZenBL. Then your reason is not based on the HELO hostname they present but the fact that they are dynamic assignments. I suggest that your default for dynamic assignments should be to deny them. Leave the HELO name alone. I use a set of sendmail rules to check for dynamic assignment type hostnames -- but permit an access database check BEFORE the dynamic check so I may define exceptions. I check for certain strings in the dynamic name as well as an IPv4 address (forward or reversed; separated by dots or dashes). However, watch out for certain side-effects -- examples: "dsl" sometimes appears in non-dynamic hostnames like "dslextreme.com." "pool" is sometimes used in dynamic names, but more often refers to swimming-pool related domains and similar other uses.
On 2012-06-06 12:02 PM, David F. Skoll wrote: > Hi, > > After the LinkedIn password fiasco, I have deleted my LinkedIn > account. Because I was the owner of the MIMEDefang group, I had to > delete that too. I've been wondering what to do too... Between Facebook privacy and LinkedIn incompetence... Thankfully, LinkedIn uses a reasonably unique password unlike anywhere else I run on the web. But the incompetence.. ugh... I want to shout, "what is wrong with these companies" --- but I already know the answer. It's not pretty. In fact, it's pretty depressing. (sigh) -Ben -- -- Ben Kamen - O.D.T., S.P. ---------------------------------------------------------------------- eMail: ben <at> benjammin.net http://www.benjammin.net http://www.linkedin.com/in/benkamen Fortune says: Women professionals do tend to over-compensate.(Continue reading)
On Wed, 06 Jun 2012 12:18:10 -0500 Ben Kamen <bkamen <at> benjammin.net> wrote: > Thankfully, LinkedIn uses a reasonably unique password unlike > anywhere else I run on the web. I use randomly-generated passwords for all my web sites and they're all at least 16 characters long (unless a web site won't allow such long passwords). So even if my LinkedIn password had been compromised (it wasn't... I downloaded the list of hashes and checked) I'd be OK. But LinkedIn apparently stored pure SHA1 hashes of the passwords instead of salting them, something UNIX has been doing since the Mesozoic era. I have a Facebook account, but I don't use it except to check up on my kids every now and then. :) Regards, David.
Overall, On 6/6/2012 1:18 PM, Ben Kamen wrote: > On 2012-06-06 12:02 PM, David F. Skoll wrote: >> Hi, >> >> After the LinkedIn password fiasco, I have deleted my LinkedIn >> account. Because I was the owner of the MIMEDefang group, I had to >> delete that too. > > I've been wondering what to do too... > > Between Facebook privacy and LinkedIn incompetence... > > Thankfully, LinkedIn uses a reasonably unique password unlike anywhere > else I run on the web. > > But the incompetence.. ugh... > > I want to shout, "what is wrong with these companies" --- but I > already know the answer. > > It's not pretty. In fact, it's pretty depressing. My understanding is that at least LinkedIn stored the passwords in SHA-1 format. They need to add a salt to make things less susceptible to look-up tables but assuming you used a unique and strong password, your login is fairly safe. The bigger issue is that they usernames are email addresses. So I think we may see an uptick in spam from that portion of the exploit.(Continue reading)
On Wed, 06 Jun 2012 14:19:53 -0400 "Kevin A. McGrail" <KMcGrail <at> pccc.com> wrote: > However, I use dedicated, unique email addresses for the vast > majority of my accounts as I'm sure others on this list do. *shameless plug* Our commecial product, CanIt, has a "Locked Addresses" feature that lets you create random email addresses and lock them to a specific sending domain. My LinkedIn login was t99ef724coxc3omn <at> la.roaringpenguin.com, for example. > In short, yes, LinkedIn had a breach apparently. However, if you use > decent passwords that are unique as any security person will extoll, > the damage should be highly limited. Sure. But I found lately that most messages from LinkedIn were spam anyway, so it was no real loss to terminate my account. Regards, David.
On Wed, Jun 6, 2012 at 1:19 PM, Kevin A. McGrail <KMcGrail <at> pccc.com> wrote: >> > In short, yes, LinkedIn had a breach apparently. However, if you use decent > passwords that are unique as any security person will extoll, the damage > should be highly limited. What is your secret to remembering hundreds of unique passwords? Or forgetting the old ones as they change? -- -- Les Mikesell lesmikesell <at> gmail.com
RSS Feed48 | |
|---|---|
21 | |
119 | |
8 | |
23 | |
13 | |
10 | |
26 | |
42 | |
81 | |
13 | |
48 | |
43 | |
36 | |
22 | |
53 | |
41 | |
11 | |
59 | |
41 | |
43 | |
31 | |
12 | |
43 | |
11 | |
14 | |
7 | |
70 | |
11 | |
23 | |
15 | |
53 | |
24 | |
32 | |
78 | |
83 | |
46 | |
46 | |
65 | |
230 | |
92 | |
69 | |
144 | |
18 | |
46 | |
61 | |
64 | |
67 | |
75 | |
56 | |
39 | |
58 | |
25 | |
54 | |
86 | |
122 | |
48 | |
51 | |
52 | |
61 | |
76 | |
90 | |
50 | |
71 | |
95 | |
82 | |
90 | |
64 | |
117 | |
124 | |
228 | |
76 | |
300 | |
210 | |
211 | |
270 | |
307 | |
240 | |
282 | |
193 | |
129 | |
86 | |
138 | |
215 | |
204 | |
227 | |
238 | |
172 | |
512 | |
249 | |
184 | |
198 | |
398 | |
204 | |
210 | |
389 | |
372 | |
330 | |
342 | |
243 | |
171 | |
210 | |
419 | |
345 | |
569 | |
511 | |
468 | |
512 | |
483 | |
691 | |
964 | |
851 | |
321 | |
1 |
