Anonymous e-mails

[keithj]

:confused: Anyone got any idea on which is the best anonymous e-mail software, I have tried a couple such as MAKMO and now using SYMPA, but always get problems especiaaly on the ISP's. Its good in disguise mode though and hard to trace.:eek:

[Ezekiel]

:confused: Anyone got any idea on which is the best anonymous e-mail software, I have tried a couple such as MAKMO and now using SYMPA, but always get problems especiaaly on the ISP's. Its good in disguise mode though and hard to trace.:eek:

Sending anonymous emails only requires a basic knowledge of how smtp works, and can be done through telnet or you could make your own anonymous emailer like I have. To send through telnet, here's the commands you would give:

telnet gmail-smtp-in.l.google.com 25
helo
mail from: <fakeemail@**********>
rcpt to: <whotosendto@**********>
data:

what you want to say

.

quit

And you replace the gmail-smtp-in.l.google.com with whatever smtp server you are using, replace all the emails with the ones you want, etc. Remember the . at the end.

[SyntaXmasteR]

telnet gmail-smtp-in.l.google.com 25
helo
mail from: <fakeemail@**********>
rcpt to: <whotosendto@**********>
data:

Two things i wanted to slip in:
*. After the "data" command the : is not nessesary
2. After you type data and hit enter it will say "ok, send it; end with ." You should now type Subject:YOURSUBJECTLINE
If you dont have a subject some spam filters will JUNK you.
Example:


telnet gmail-smtp-in.l.google.com 25
helo
mail from: <fakeemail@**********>
rcpt to: <whotosendto@**********>
data
subject:Test Email!!

[Ezekiel]

Two things i wanted to slip in:
*. After the "data" command the : is not nessesary
2. After you type data and hit enter it will say "ok, send it; end with ." You should now type Subject:YOURSUBJECTLINE
If you dont have a subject some spam filters will JUNK you.
Example:

Yeah, lol, I was typing quickly, I should probably edit it to remove the :. Also something else people might be interested in, another thing you can put in after the data command is X-Originating-IP: [**2.*68.*.*], replacing the ip with whatever you want to spoof the ip to. You can see the real ip from other items included in the headers, but creating a fake X-Originating-IP is enough to trick most users. And there are many more things you can put after sending the data command, but before the actual message, like X-Mailer and many others I can't think of right now. EDIT: A quick google for email headers list found me a list of common headers, headers like date can be useful to make a user think the email was sent at a specific time:

List of Common Headers

* Apparently-To: Messages with many recipients sometimes have a long list of headers of the form "Apparently-To: rth@bieberdorf.edu" (one line per recipient). These headers are unusual in legitimate mail; they are normally a sign of a mailing list, and in recent times mailing lists have generally used software sophisticated enough not to generate a giant pile of headers.

* Bcc: (stands for "Blind Carbon Copy") If you see this header on incoming mail, something is wrong. It's used like **: (see below), but does not appear in the headers. The idea is to be able to send copies of email to persons who might not want to receive replies or to appear in the headers. Blind carbon copies are popular with spammers, since it confuses many inexperienced users to get email that doesn't appear to be addressed to them.

* **: (stands for "Carbon Copy", which is meaningful if you remember typewriters) This header is sort of an extension of "To:"; it specifies additional recipients. The difference between "To:" and "**:" is essentially connotative; some mailers also deal with them differently in generating replies.

* Comments: This is a nonstandard, free-form header field. It's most commonly seen in the form "Comments: Authenticated sender is <rth@bieberdorf.edu>". A header like this is added by some mailers (notably the popular freeware program Pegasus) to identify the sender; however, it is often added by hand (with false information) by spammers as well. Treat with caution.

* Content-Transfer-Encoding: This header relates to MIME, a standard way of enclosing non-text content in email. It has no direct relevance to the delivery of mail, but it affects how MIME-compliant mail programs interpret the content of the message.

* Content-Type: Another MIME header, telling MIME-compliant mail programs what type of content to expect in the message.

* Date: This header does exactly what you'd expect: It specifies a date, normally the date the message was composed and sent. If this header is omitted by the sender's computer, it might conceivably be added by a mail server or even by some other machine along the route. It shouldn't be treated as gospel truth; forgeries aside, there are an awful lot of computers in the world with their clocks set wrong.

* Errors-To: Specifies an address for mailer-generated errors, like "no such user" bounce messages, to go to (instead of the sender's address). This is not a particularly common header, as the sender usually wants to receive any errors at the sending address, which is what most (essentially all) mail server software does by default.

* From (without colon) This is the "envelope From" discussed above.

* From: (with colon) This is the "message From:" discussed above.

* Message-Id: (also Message-id: or Message-ID:) The Message-Id is a more-or-less unique identifier assigned to each message, usually by the first mailserver it encounters. Conventionally, it is of the form "gibberish@bieberdorf.edu", where the "gibberish" part could be absolutely anything and the second part is the name of the machine that assigned the ID. Sometimes, but not often, the "gibberish" includes the sender's username. Any email in which the message ID is malformed (e.g., an empty string or no @ sign), or in which the site in the message ID isn't the real site of origin, is probably a forgery.

* In-Reply-To: A Usenet header that occasionally appears in mail, the In-Reply-To: header gives the message ID of some previous message which is being replied to. It is unusual for this header to appear except in email directly related to Usenet; spammers have been known to use it, probably in an attempt to evade filtration programs.

* Mime-Version: (also MIME-Version:) Yet another MIME header, this one just specifying the version of the MIME protocol that was used by the sender. Like the other MIME headers, this one is usually eminently ignorable; most modern mail programs will do the right thing with it.

* Newsgroups: This header only appears in email that is connected with Usenet---either email copies of Usenet postings, or email replies to postings. In the first case, it specifies the newsgroup(s) to which the message was posted; in the second, it specifies the newsgroup(s) in which the message being replied to was posted. The semantics of this header are the subject of a low-intensity holy war, which effectively assures that both sets of semantics will be used indiscriminately for the foreseeable future.

* Organization: A completely free-form header that normally contains the name of the organization through which the sender of the message has net access. The sender can generally control this header, and silly entries like "Royal Society for Putting Things on Top of Other Things" are commonplace.

* Priority: An essentially free-form header that assigns a priority to the mail. Most software ignores it. It is often used by spammers, usually in the form "Priority: urgent" (or something similar), in an attempt to get their messages read.

* Received: Discussed in detail above.

* References: The References: header is rare in email except for copies of Usenet postings. Its use on Usenet is to identify the "upstream" posts to which a message is a response; when it appears in email, it's usually just a copy of a Usenet header. It may also appear in email responses to Usenet postings, giving the message ID of the post being responded to as well as the references from that post.

* Reply-To: Specifies an address for replies to go to. Though this header has many legitimate uses (perhaps your software mangles your From: address and you want replies to go to a correct address), it is also widely used by spammers to deflect criticism. Occasionally a naive spammer will actually solicit responses by email and use the Reply-To: header to collect them, but more often the Reply-To: address in junk email is either invalid or an innocent victim.

* Sender: This header is unusual in email (X-Sender: is usually used instead), but appears occasionally, especially in copies of Usenet posts. It should identify the sender; in the case of Usenet posts, it is a more reliable identifier than the From: line.

* Subject: A completely free-form field specified by the sender, intended, of course, to describe the subject of the message.

* To: The "message To: "described above. Note that the To: header need not contain the recipient's address!

* X-headers is the generic term for headers starting with a capital X and a hyphen. The convention is that X-headers are nonstandard and provided for information only, and that, conversely, any nonstandard informative header should be given a name starting with "X-". This convention is frequently violated.

* X-Confirm-Reading-To: This header requests an automated confirmation notice when the message is received or read. It is typically ignored; presumably some software acts on it.

* X-Distribution: In response to problems with spammers using his software, the author of Pegasus Mail added this header. Any message sent with Pegasus to a sufficiently large number of recipients has a header added that says "X-Distribution: bulk". It is explicitly intended as something for recipients to filter against.

* X-Errors-To: Like Errors-To:, this header specifies an address for errors to be sent to. It is probably less widely obeyed.

* X-Mailer: (also X-mailer:) A freeform header field intended for the mail software used by the sender to identify itself (as advertising or whatever). Since much junk email is sent with mailers invented for the purpose, this field can provide much useful fodder for filters.

* X-PMFLAGS: This is a header added by Pegasus Mail; its semantics are nonobvious. It appears in any message sent with Pegasus, so it doesn't obviously convey any information to the recipient that isn't covered by the X-Mailer: header.

* X-Priority: Another priority field, used notably by Eudora to assign a priority (which appears as a graphical notation on the message).

* X-Sender: The usual email analogue to the Sender: header in Usenet news, this header purportedly identifies the sender with greater reliability than the From: header. In fact, it is nearly as easy to forge, and should therefore be viewed with the same sort of suspicion as the From: header.

* X-UIDL: This is a unique identifier used by the POP protocol for retrieving mail from a server. It is normally added between the recipient's mail server and the recipient's actual mail software; if mail arrives at the mail server with an X-UIDL: header, it is probably junk (there's no conceivable use for such a header, but for some unknown reason many spammers add one).

[SyntaXmasteR]

Great Post Mike

[Ezekiel]

Jeez mike did you write that all your self?? Anyways if you use a web proxy like hidemyass.com then make a new hotmail or something while using the proxy and send the emails and everything while using the proxy you should be pretty fine.

No, I wrote the first part, but copied the list from a random page about email headers. Using a proxy is good, but isn't the whole point of this to spoof the email headers and change who it is from? Because an email address usually reveals just as much as an ip address, all they have got to do is somehow get you to email back while not using a proxy and they have your ip.