ashampoo / pctools

Beside that these are no firewalls, many people seem to use them.

About this crappy software products, or the people who are so stupid to actually use them.

Which is no firewall either. And no competent people either.

At any rate, why is your From: mail address invalid?

Il 28/09/2007, su comp.security.firewalls "Re: ashampoo / pctools", Sebastian G. ha detto :

".invalid" is only to avoid a little of spam.

I have two accounts that I post with, have to 20+ years on Usenet, while I almost always post using a nym and munged email address because of the spam concern, my other identity uses a full email address. In all that time I've never seen spam from using that email address in Usenet. Don't get me wrong, and I'm not about to stop using a munged address, but I don't see where Usenet is being farmed for email addresses as a norm.

.invalid is an RFC violation. Beside that, since your posting contains the valid address in the Reply-To: header, your measure is absolutely useless.

If you want to avoid spam, use a spam filter.

If you want to avoid spam by not communication at all, use a mail address from a free mail provider and configure to delete every incoming mail. The validity of the mail box is only required to avoid bounces, no one ever demands you to actually read any mail that is being sent there.

No. And repeating that will not make it more true.

Sebastian, I know that people are not agreeing on this point. So please don't argue this way, or we'll have senseless and useless discussions again and again.

Yours, VB.

See RFC 2606.

If you don't want email, especially spam, the best solution is to use a valid, but nonresolvable TLD like .invalid.

Maybe you missed the context: Specifying a mail address in the From: header with the domain .invalid is an RFC violation, since the RFC (both Email and Usenet) requires you to provide a valid mailbox (whereas a valid mailbox is defined as a mailbox that can receive mail). Of course .invalid by itself is perfectly valid (as a pseudo-TLD).

And that's the point people don't agree.

Yours, VB.

Maybe this was written a bit misleading, but we're rather talking about RFC

1036 and RFC 2822. You are required to provide a valid mailbox in the From header, thus something that can receive mail. A .invalid address surely won't.

Again, please see above. Let's say I forward such a posting wthout encpasulation, and the receive then wants to reply to it. He won't see the Reply-To: header, only the address in the From: header. He replies, and then receives an error because the .invalid mailbox is not valid. And who caused it? The guy who put the invalid address there in first place!

No, the best and only valid solution is to provide a valid mailbox that you never read (and, for avoiding bounces due to filling up, regularly deletes all incoming mail).

While using .invalid or .void or .lan does not currently resolve to ANY TLD, it's actually a good idea because the mail systems won't be impacted, the spam won't spread, the users that have some clue know to look for the real address in the sig, and it's been used for enough years that anyone aware of Usenet knows about it.

There are exceptions everything - if the Usenet providers thought this was a problem they would not allow postings without valid information.

I see also address like snipped-for-privacy@vene.ws Is valid to insert NoSpam ?

or a temporary email in From field ? with the right email in ReplyTo:

Il 29/09/2007, su comp.security.firewalls "Re: ashampoo / pctools", Sebastian G. ha detto :

sorry ... what is TLD ?

Top Level Domain

cu

59cobalt

No, once more you're disseminating nonsense. There are methods of communication that don't require any reply per email like the participation in a Usenet discussion. You yourself already mentioned that there's no need to agree in being contacted individually. That's why it's not only legitimate but reasonable to avoid a working reply address instead of inducing unnecessary traffic to a dummy mailbox that merely eliminates it anyway. And the only correct way to do so is to use one of the official standard patterns for invalid domain names. That's unequivocal and avoids system load.

RFC 2606 states

|There is a need for top level domain (TLD) names that can be used for |creating names which, without fear of conflicts with current or |future actual TLD names in the global DNS, can be used for private |testing of existing DNS related code, examples in documentation, DNS |related experimentation, invalid DNS names, or other similar uses.

and

|".invalid" is intended for use in online construction of domain |names that are sure to be invalid and which it is obvious at a |glance are invalid.

which clearly describes the intended purpose of the ".invalid" TLD.

Your disguised rubbish bin fools honest Usenet contributors that may be interested in contacting you per mail. Do you feel well misleading them and wasting their valuable time?

Rudy

Why should I waste disk-space and bandwidth just so some idiot can collect 0.04 pfennig for a "valid" address that can be sold to spammers. Thanks to address harvesters, trying to respond to a Usenet posting by mail is useless today. While RFC0977 (and it's replacement RFC3977) are standards, RFC1036 is not, as shown by the index listing.

0977 Network News Transfer Protocol. B. Kantor, P. Lapsley. February 1986. (Format: TXT=55062 bytes) (Obsoleted by RFC3977) (Status: PROPOSED STANDARD) 1036 Standard for interchange of USENET messages. M.R. Horton, R. Adams. December 1987. (Format: TXT=46891 bytes) (Obsoletes RFC0850) (Status: UNKNOWN) 3977 Network News Transfer Protocol (NNTP). C. Feather. October 2006. (Format: TXT=247440 bytes) (Obsoletes RFC0977) (Updates RFC2980) (Status: PROPOSED STANDARD)

Sebastian may want to read RFC2026, and discover the meaning of that term "Status". Not all RFCs are standards. In fact:

[compton ~]$zcat rfcs/rfc-index.txt.09.28.07.gz | sed 's/^$/\\%/' | tr -d '\\n' | tr '%' '\\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued' | sed 's/.*Status: //' | tr -d '\\)' | sort | uniq -c | column 144 BEST CURRENT PRACTICE 1538 INFORMATIONAL 134 DRAFT STANDARD 1605 PROPOSED STANDARD 285 EXPERIMENTAL 87 STANDARD 206 HISTORIC 909 UNKNOWN [compton ~]$

There are nearly 1600 more documents working through the draft stage, and as such are "a work in progress" and otherwise meaningless, but they show where things are headed. The ones the Sebastian should be looking at are in the Usenet Article Standard Update (usefor) section:

"Netnews Article Format", Charles Lindsey, 9-Jan-07,

"Netnews Architecture and Protocols", Russ Allbery, Charles Lindsey, 3-Jul-07,

Read the second one - where there is this wonderful statement as the third paragraph in the section "3.3. Duties of a Posting Agent":

Contrary to [RFC2822], which implies that the mailbox or mailboxes in the From header field should be that of the poster or posters, a poster who does not, for whatever reason, wish to use his own mailbox MAY use any mailbox ending in the top level domain ".invalid" [RFC2606].

Actually, it was included in ``Address Munging FAQ: "Spam-Blocking" Your Email Address''

the late 1990s.

and we wouldn't have eleventy zillion clueless web-users posting from places like groups.google.com or anomynizers. Imagine that.

Old guy

He should be able to see the address he is replying to - no matter whether it came from the original From: field or the original Reply-To: field - when he is composing the reply.

Oh, boo hoo! Cry me a river! At least that way he knows he'll never get a reply vs his reply languishing in some mailbox that will - by design - never be checked.

I use the TLD .invalid in Usenet postings because I don't want casual replies via email. My desire not to receive replies via email trumps this hypothetical guy's desire to reply to me via email, RFCs notwithstanding. Who caused that attitude? The damn spammers who scrape addresses from Usenet postings and then send spam to them.

I choose not to subject myself to that. And I will not subject some freemail provider to that just so I can have a valid address that I never check. To insist otherwise is absolutely ludicrous, RFCs notwithstanding.

That's a waste of resources.

Trust me, there's lots of it about. Either that or they dump all yours on me. Sigh.

Chris