Email, consisting itself of headers and body, is wrapped for transmission by SMTP in an envelope. The envelope specifies what system is transmitting the mail, who the mail is from, and who it is to.
The transmitting system is supposed to identify itself at the beginning of an SMTP session with a HELO command. This has to some extent fallen into disrepute as a result of the dominant software supplier ignoring previously accepted standards. However, as those systems are more frequently compromised and used as spam sources, rejecting out-of-specification HELO names can be used in some situation to reduce spam. There is also some software (we are not certain whether it’s a custom spam-blaster package, or a virus) which deliberately uses a HELO name of the destination IP address. This is not only out-of-spec but abusive in that it attempts to confuse human readers of mail logfiles; we reserve the right to reject mail from all such sources.
The envelope sender is given by a SMTPMAIL FROM: command. Normally the receiving MTA will copy this address into a Reply-To:header and a user’s mail client (MUA) will use that when a “reply” function is used. The envelope sender may or may not match any From: header or Sender: header. Since it is fully under the control of the sending system it is normally faked by spammers, to misdirect any complaints. They both just invent names and/or domains and use “known valid” ones. The latter presents a secondary problem of spam: the person whos name has been used in this way is inundated with complaints, automated bounces, complaints to his system admins and his upstreams, and sometimes even personal abuse – despite being perfectly innocent. Targetted indirect attacks of this type have become known as joe-jobs.
The mail destination(s) are given by a sequence of SMTPRCPT TO: commands. The receiving MTA can accept or reject each of these individually, and interpret them as it wishes. There is not necessarily any correspondence btween this list and the destination addresses in the mail headers; in particular, mail Bcc’d will have destination names in the envelope which are not in the headers.
Because these SMTP commands are passed before the data carrying the message, it is cheaper to reject spam based on envelope information than on message information. Likewise, the IP address of the sending system is available early and cheaply, and can be compared with both locally-stored lists and remote DNSBLs.
SMTP Envelope
Email, consisting itself of headers and body, is wrapped for transmission by SMTP in an envelope. The envelope specifies what system is transmitting the mail, who the mail is from, and who it is to.
The transmitting system is supposed to identify itself at the beginning of an SMTP session with a HELO command. This has to some extent fallen into disrepute as a result of the dominant software supplier ignoring previously accepted standards. However, as those systems are more frequently compromised and used as spam sources, rejecting out-of-specification HELO names can be used in some situation to reduce spam. There is also some software (we are not certain whether it’s a custom spam-blaster package, or a virus) which deliberately uses a HELO name of the destination IP address. This is not only out-of-spec but abusive in that it attempts to confuse human readers of mail logfiles; we reserve the right to reject mail from all such sources.
The envelope sender is given by a SMTP MAIL FROM: command. Normally the receiving MTA will copy this address into a Reply-To: header and a user’s mail client (MUA) will use that when a “reply” function is used. The envelope sender may or may not match any From: header or Sender: header. Since it is fully under the control of the sending system it is normally faked by spammers, to misdirect any complaints. They both just invent names and/or domains and use “known valid” ones. The latter presents a secondary problem of spam: the person whos name has been used in this way is inundated with complaints, automated bounces, complaints to his system admins and his upstreams, and sometimes even personal abuse – despite being perfectly innocent. Targetted indirect attacks of this type have become known as joe-jobs.
The mail destination(s) are given by a sequence of SMTP RCPT TO: commands. The receiving MTA can accept or reject each of these individually, and interpret them as it wishes. There is not necessarily any correspondence btween this list and the destination addresses in the mail headers; in particular, mail Bcc’d will have destination names in the envelope which are not in the headers.
Because these SMTP commands are passed before the data carrying the message, it is cheaper to reject spam based on envelope information than on message information. Likewise, the IP address of the sending system is available early and cheaply, and can be compared with both locally-stored lists and remote DNSBLs.