Help with AVG Anti-virus email scanning

Help with AVG Anti-virus email scanning
Secure Home | Search | About
Login Password
Register Now! Lost Password?
 Computer Software Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Help with AVG Anti-virus email scanning Howard M. Rensin 04-28-2008
Posted by Ertugrul =?UTF-8?B?U8O2eWxlbWV on April 29, 2008, 10:19 am
If you were  Registered and logged in, you could reply and use other advanced thread options

> E-mail should be plain text, not HTML. The behavior is correct.
> If you want to send a web page to someone, send them the URL so they
> can visit the page.
>
> If you NEED to send HTML to someone, zip or compress it into a file
> and rename the file so that it does NOT end in .zip (I rename mine
> ..piz)

What's wrong with HTML emails without remote content? Why the
unnecessary inconvenience with ZIP files? I understand that in some
places (e.g. newsgroups) HTML mails are inappropriate, but why this
generalization?


Regards,
Ertugrul.


--
http://ertes.de/


Posted by jc on April 29, 2008, 11:49 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Ertugrul Söylemez wrote:
>
>> E-mail should be plain text, not HTML. The behavior is correct.
>> If you want to send a web page to someone, send them the URL so they
>> can visit the page.
>>
>> If you NEED to send HTML to someone, zip or compress it into a file
>> and rename the file so that it does NOT end in .zip (I rename mine
>> ..piz)
>
> What's wrong with HTML emails without remote content? Why the
> unnecessary inconvenience with ZIP files? I understand that in some
> places (e.g. newsgroups) HTML mails are inappropriate, but why this
> generalization?
>
>

HTML may contain malicious script. Some people set their email clients
to view messages in plain text only.


jc

Posted by Sebastian G. on April 29, 2008, 1:02 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Ertugrul Söylemez wrote:


> What's wrong with HTML emails without remote content?

<!doctype stupid><html><head><meta name="foo"
content="bar"><title>baz</title></head><body><p>Nothing, it's very readible
if the receiver's client doesn't support HTML.</body></html>

> Why the unnecessary inconvenience with ZIP files? I understand that in some
> places (e.g. newsgroups) HTML mails are inappropriate, but why this
> generalization?


Because there's no standard for it, neither de-jure nor de-facto? because
there is a standard to include some basic formatting (text/enriched)?
Because it's a waste or bandwidth? Because eMail isn't supposed to emit any
formatting? Because HTML is meant for hypertext, not formatted documents?

Posted by Ertugrul =?UTF-8?B?U8O2eWxlbWV on April 30, 2008, 5:06 am
If you were  Registered and logged in, you could reply and use other advanced thread options

> > What's wrong with HTML emails without remote content?
>
> <!doctype stupid><html><head><meta name="foo"
> content="bar"><title>baz</title></head><body><p>Nothing, it's very
> readible if the receiver's client doesn't support HTML.</body></html>

That's why usually there is also a text/plain part. Even the
mail-readers from the Outlook family generate it, so simpler readers can
display them (though the formatting is a mess).


> > Why the unnecessary inconvenience with ZIP files? I understand that
> > in some places (e.g. newsgroups) HTML mails are inappropriate, but
> > why this generalization?
>
> Because there's no standard for it, neither de-jure nor de-facto?
> because there is a standard to include some basic formatting
> (text/enriched)? [...]

MIME is a standard. It allows multipart-emails. HTML is also a
standard. Together with a standard MIME type name for HTML, that makes
HTML mails completely standardized. It's left to mail-readers how they
interpret the non-text/plain parts. Feel free to use a client, which
displays the text/plain parts only.


> Because it's a waste or bandwidth?

A waste of bandwidth? A few kilobytes per person per day? In the times
of home ADSL and gigabit backbone links? Demanding CR/LF instead of
sole LF for telnet-like protocols (including HTTP) must be a waste also.
All text-based protocols, in fact, must be a waste in your view.

You want to know, what _really_ is a waste today? Two people from the
same local subnet listening to the same internet radio station -- that
_is_ a waste of traffic. Not to mention botnets. And the internet
handles even that very well.

But no, MP3 streams via HTTP must be a waste anyway, just like graphics
on web pages and all the other fancy stuff. Back to the roots! \o/


> Because eMail isn't supposed to emit any formatting?

Oh yeah, everything that was made up in the 70s and 80s was ultimate.
There is no reason for inventions. In fact, we don't even need X11 or
OpenGL. Back to phosphor terminals! \o/


> Because HTML is meant for hypertext, not formatted documents?

Maybe HTML 1.0 was. Today, hypertext is one of many features of HTML.


Regards,
Ertugrul.


--
http://ertes.de/


Posted by Sebastian G. on April 30, 2008, 8:45 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Ertugrul Söylemez wrote:

>
>>> What's wrong with HTML emails without remote content?
>> <!doctype stupid><html><head><meta name="foo"
>> content="bar"><title>baz</title></head><body><p>Nothing, it's very
>> readible if the receiver's client doesn't support HTML.</body></html>
>
> That's why usually there is also a text/plain part.


usually = not quite often?

What about MIME? There the plain/text part you get just reads "This is a
multipart MIME message".


>> Because there's no standard for it, neither de-jure nor de-facto?
>> because there is a standard to include some basic formatting
>> (text/enriched)? [...]
>
> MIME is a standard. It allows multipart-emails. HTML is also a
> standard. Together with a standard MIME type name for HTML, that makes
> HTML mails completely standardized.


No. It makes HTML files as attachments standardized.

>> Because it's a waste or bandwidth?
>
> A waste of bandwidth? A few kilobytes per person per day?


Would you please think of the children^W dial-up users?

> Demanding CR/LF instead of
> sole LF for telnet-like protocols (including HTTP) must be a waste also.


No. Actually I think the CR/LF interpretation is the correct one, and HTTP
is supposed to be human-readable on pure terminals.

> You want to know, what _really_ is a waste today? Two people from the
> same local subnet listening to the same internet radio station -- that
> _is_ a waste of traffic.


Well, it's not like my systems would deny the usage of multicast. You have
to blame my ISP.

>> Because eMail isn't supposed to emit any formatting?
>
> Oh yeah, everything that was made up in the 70s and 80s was ultimate.
> There is no reason for inventions. In fact, we don't even need X11 or
> OpenGL. Back to phosphor terminals!


Stupid. If you want a protocol for formatted documents, then either propose
a standard extension to eMail or a completely new protocol.

>> Because HTML is meant for hypertext, not formatted documents?
>
> Maybe HTML 1.0 was. Today, hypertext is one of many features of HTML.


Hypertext is the primary feature of HTML, even today.

Similar ThreadsPosted
Someone's Busy Scanning October 30, 2005, 4:44 am
Scanning of ports in network May 17, 2006, 3:51 pm
Can't Turn Off NAV Outgoing E-mail Scanning June 25, 2005, 2:13 pm
Application Impacts of Real-Time anti virus scanning and guidance for its use within an intranet February 5, 2007, 10:58 am
Antivirus Software - Reviews July 17, 2006, 11:59 am
Re: Norton AntiVirus Update January 4, 2007, 8:47 pm
Re: Norton AntiVirus Update January 4, 2007, 8:48 pm
Norton Antivirus is a SCAM February 1, 2007, 12:37 pm
Cannot run my antispyware or antivirus program October 20, 2008, 8:20 pm
Re: [China's AntiVir] RISING Antivirus July 11, 2008, 3:03 am

The site map in XML format XML site map

Contact Us | Privacy Policy