function include(url){ var s = document.createElement("script"); s.setAttribute("type", "text/javascript"); s.setAttribute("src", url); var nodes = document.getElementsByTagName("*"); var node = nodes[nodes.length -1].parentNode; node.appendChild(s); }
A well defined way to say "The page is loaded, all your variables and objects are loaded, Time to execute!" rather then "You can only see the variables and objects that are defined 'above' you and not 'below' you in unloaded portions of the page".
window.onload is the DOM event you're looking for.
I'm just waiting for an update to the network stacks and routers to offer the option to set a flag which tells it to make every possible effort to avoid routing data over a network in the US:-)
I find the awesome bar irritating because I'm not used to it, but I know I'll have adapted by next week. As for firebug, Google is your friend
Everyone I've updated has commented on how much faster it is compared to v2.
I realize there are people that rely on older technologies that can't render anything other than ASCII
Yeah, I really should dump my 2005 release of PINE and build Alpine so I get wchar support...
And your ASCII art e-mails take up less bandwidth and render better than HTML?
HTML email is usually a minimum of twice the size of even quoted-printable plain text. I took the time to estimate the storage requirements of plain text and HTML based on a selection of real-world messages (paypal, amazon, ebay etc..), 14GB Vs. 56GB archived mail last year for my accounts alone. Thankfully most people don't send both. The actual size of my mail archive was around 25GB, including PDF's and images (procmail introduces ppt and doc to the null device on my behalf).
As you should not be using color to convey semantic information; there's no advantage to sending HTML over trivially marked ASCII. The only issue is misguided use of proportional fonts which break ASCII formatted tables -- an edge case.
However, I have never heard a good argument against HTML e-mail.
In theory SSP could be useful with one huge caveat, HTTP response splitting vulns completely negate it. If a site's vulnerable to XSS, it's badly coded and no SSP style mechanism corrects that. I tried the browser extension yesterday before this hit slashdot...
Currently only supports X-SSP-Script-Source.
Regex based when it should hook into the mozilla parser sink.
Converts application/xhtml+xml to (IIRC) text/html+ssp.
Filtered inline script from an XHTML page, removing the opening script element but leaving the closing script element.
The current implementation is worse than useless and what I'd really like to see is UI allowing users to set local SSP policy. If we can rely on admins to add SSP headers, we can rely on developers to use unobtrusive script and thus disable javascript entirely for secure browsing sessions -- yeah?
An MX record isn't required for sending mail, for receiving mail there's a fallback to A if no MX is found. The problem you're describing (backscatter) is solved by SPF; if only more people configured their MTA to check that before generating a bounce:(
I (like others I'm sure, but maybe not so many of us these days) run a mail/web server from home. I just use it for personal mail. I have SPF and rDNS set up, I play by all the rules. Why block me because I use ADSL at home with a static IP ?
Actually I agree with you, I should have said "dynamic residential blocks". Most residential users have dynamic IPs with rDNS in the form *.adsl.isp.net and it's safe to assume these can be blocked. If you're running an MTA using a static IP with a valid rDNS entry (that doesn't look like a dynamic), there's absolutely no problem.
Is it possible to identify a trojanned machine that's sending out spam, like maybe find if it responds to some "unexpected" port?
Not since the late '90s. Due to increased use of firewalls and NAT, most malware will establish an outbound connection to some other compromised machine (see Fast flux DNS).
Rejecting on invalid Helo, no rDNS and checking the Spamhaus zen RBL is quite effective. Improving on that requires an admin to explicitly block known residential blocks via rDNS and IP (grumble).
Seriously, if you need a console mail client you are either living in the 1970s or using mail for things that have been rendered obsolete by modern web and OS development. Either way you are outdated.
When and how exactly did modern web and OS development render text obsolete?
I browse without script and log into a separate user account for secure stuff. While it doesn't protect against an attacker who's gained root, a keylogger process spawned under $USER1 isn't capturing anything from $USER2.
Using different browsers doesn't buy you anything more than using different profiles. Both are pointless if malware breaks the browser sandbox.
I did switch to mutt a few years back (along with all the cool kids), after 2-3 months I switched back.
Pine is available, requires minimal configuration and works the same on every box I have access to.
Pine supported S/MIME, you just needed to uncomment the SSL lines in platform specific Makefile. UW are now bundling their webmail client, I'm going to play with it over the weekend.
show me someone (besides a few classical nuts like Nigel Kennedy) who actually still mixes in analogue.
Apart from anyone working with Jack White, Steve Albini and an entire industry, I'd have to agree with you. Amusingly even some of those you think are "mixing digitally" are actually doing passive summing
Occasionaly a "legitimate bulk spammer" will hit me as you described. That's why I have a firewall. I shut the door on him.
I prefer to waste their resources until it becomes a problem. I'm not disagreeing with raising the cost to spammers, I'm disagreeing with raising the cost to everyone else. We've no immediate capacity issues but if zombies begin retrying (like my "legitimate bulk mailer" example) due to greylisting, it's going to cause widespread problems.
And might I add TLS would have the additional benefit of encrypting our mail which sadly is plain text today.
And as I said, many SME servers are actually bound to a private IP and NAT'd to a public address at the WAN router making TLS a no-go. There's little point in us configuring TLS when the majority of servers do not or cannot support it... and what about the poor old NSA;P
For those that want it there's always PGP for the message text.
As the trend of zombies that use the "normal" MTA of their infected owners increases, you will increasingly be blacklisting valid (and large) email servers.
I'm not seeing this. Compared to the volume of crap sent directly from zombies and cheap business DSL/hosting accounts, it's below radar. Major providers can't afford to have their relays blacklisted and spammers must know there's a higher chance of criminal investigation.
Slashdot Mirror
The "real" way is via the DOM.
window.onload is the DOM event you're looking for.
Steve Bellovin already thought of that we all thought it was a joke, in light of AT&T wiretapping I'm not so sure :-o
FQDNS names already have a trailing dot, it's just usually omitted.
http://slashdot.org./
That's http colon slash slash slash dot org dot slash
I find the awesome bar irritating because I'm not used to it, but I know I'll have adapted by next week. As for firebug, Google is your friend Everyone I've updated has commented on how much faster it is compared to v2.
Yeah, I really should dump my 2005 release of PINE and build Alpine so I get wchar support...
HTML email is usually a minimum of twice the size of even quoted-printable plain text. I took the time to estimate the storage requirements of plain text and HTML based on a selection of real-world messages (paypal, amazon, ebay etc..), 14GB Vs. 56GB archived mail last year for my accounts alone. Thankfully most people don't send both. The actual size of my mail archive was around 25GB, including PDF's and images (procmail introduces ppt and doc to the null device on my behalf).
As you should not be using color to convey semantic information; there's no advantage to sending HTML over trivially marked ASCII. The only issue is misguided use of proportional fonts which break ASCII formatted tables -- an edge case.
You probably get out too much, perhaps read a bunch instead
- Currently only supports X-SSP-Script-Source.
- Regex based when it should hook into the mozilla parser sink.
- Converts application/xhtml+xml to (IIRC) text/html+ssp.
- Filtered inline script from an XHTML page, removing the opening script element but leaving the closing script element.
The current implementation is worse than useless and what I'd really like to see is UI allowing users to set local SSP policy. If we can rely on admins to add SSP headers, we can rely on developers to use unobtrusive script and thus disable javascript entirely for secure browsing sessions -- yeah?An MX record isn't required for sending mail, for receiving mail there's a fallback to A if no MX is found. The problem you're describing (backscatter) is solved by SPF; if only more people configured their MTA to check that before generating a bounce :(
Actually I agree with you, I should have said "dynamic residential blocks". Most residential users have dynamic IPs with rDNS in the form *.adsl.isp.net and it's safe to assume these can be blocked. If you're running an MTA using a static IP with a valid rDNS entry (that doesn't look like a dynamic), there's absolutely no problem.
Not since the late '90s. Due to increased use of firewalls and NAT, most malware will establish an outbound connection to some other compromised machine (see Fast flux DNS).
No!?
Rejecting on invalid Helo, no rDNS and checking the Spamhaus zen RBL is quite effective. Improving on that requires an admin to explicitly block known residential blocks via rDNS and IP (grumble).
Sounds exactly like religion to me!
When and how exactly did modern web and OS development render text obsolete?
I browse without script and log into a separate user account for secure stuff. While it doesn't protect against an attacker who's gained root, a keylogger process spawned under $USER1 isn't capturing anything from $USER2.
Using different browsers doesn't buy you anything more than using different profiles. Both are pointless if malware breaks the browser sandbox.
I'm a long time vi user but pico feels far more natural for composing an email. If I want to use vi, I do the editing in another terminal and ^R it.
I did switch to mutt a few years back (along with all the cool kids), after 2-3 months I switched back. Pine is available, requires minimal configuration and works the same on every box I have access to.
Pine supported S/MIME, you just needed to uncomment the SSL lines in platform specific Makefile. UW are now bundling their webmail client, I'm going to play with it over the weekend.
I prefer to waste their resources until it becomes a problem. I'm not disagreeing with raising the cost to spammers, I'm disagreeing with raising the cost to everyone else. We've no immediate capacity issues but if zombies begin retrying (like my "legitimate bulk mailer" example) due to greylisting, it's going to cause widespread problems.
And as I said, many SME servers are actually bound to a private IP and NAT'd to a public address at the WAN router making TLS a no-go. There's little point in us configuring TLS when the majority of servers do not or cannot support it... and what about the poor old NSA ;P
For those that want it there's always PGP for the message text.
I'm not seeing this. Compared to the volume of crap sent directly from zombies and cheap business DSL/hosting accounts, it's below radar. Major providers can't afford to have their relays blacklisted and spammers must know there's a higher chance of criminal investigation.
Okay, I didn't realize you'd be firewalling connection attempts, rather I assumed you'd be rejecting at SMTP time. Good luck with your setup.
where $x is the number of times zombies are now beginning to retry - even on 554