Re: mysterious line in my script - what does it all mean?



On 12/19/2006 11:30 PM, l v wrote:

Well,
The RFC's for smtp details the smtp protocol which includes format of the headers.
The headers should terminate with CRLF.
Modules like Mail::Sender should adhere to the smtp protocol defined in the RFC's.

With those 3 points in mind, it would *seem* to me if I set Mail::Sender's 'from' = "me@xxxxxxxxxxx\nCC: spam_address@xxxxxxxxxxx", either Mail::Sender should either:
generate an error,
use the 'from' value in it's entirety as the 'from' header,
truncate after the first newline,
or everything past newline is ignored when creating the smtp commands.


I installed Mail::Sender just to test this.

No matter what, it's dangerous to not validate input. Getting Mail::Sender to spam unintended recipients is more difficult, but it is possible.

In the case of Maxwells' original program, the spammer's primary target would be sendmail. In the case of a program that uses Mail::Sender without validation, the spammer's primary target would be SMTP.

What I mean to say by this is that, in one case, the CGI parameter "s" is set to something that is likely to be (mis)interpreted by sendmail, and in the second case, "s" is set to something that is likely to be misinterpreted by a SMTP server.


My choice would be use the 'from' value in it's entirety as the 'from' header. IMO, sendmail should never be called via cgi which would also prevent 2000-byte binaries from causing sendmail to crash leaving shell's left open.

I also believe that if we are to get the upper leg on the spammers, we can not leave the responsibility in the hands of the programmer - as you state, programmers can be stupid FTTT.


Huh? All of the software we're talking about has been written by programmers: Perl, sendmail (or exim), Mail::Sender, and Maxwells' script were all written by programmers. The solution to spam /will/ involve programmers (as well as law enforcement).

Perhaps you might want to argue /which/ programmers will have the most responsibility. I'm not in a mood to be begin trying to think about that right now; a programmer is responsible for his or her program. And I have proven to myself that I can't simply trust Mail::Sender, because it allows some pretty interesting things to get down to the SMTP level.


--
paduille.4060.mumia.w@xxxxxxxxxxxxx
http://home.earthlink.net/~mumia.w.18.spam/

.



Relevant Pages

  • Re: Please help newbie with sendmail via SMTP?
    ... headers and message etc. ... I want to use sendmail to read this file and send the emails via my smtp mail server. ...
    (comp.mail.sendmail)
  • RE: No IP address logging on internal email.
    ... The headers you describe are SMTP ... the same server MAPI doesn't add anything to the SMTP header. ... "Send-As" permission is sending-as these users, so check mailbox rights. ...
    (microsoft.public.exchange2000.transport)
  • Re: Strange SPAM with no tracks...!?
    ... the destination domain generates a NDR for the recipient in your domain whose email address was spoofed in headers. ... If the destination domain did a SenderID check and you had SPF records published, it would have been easy to determine that the sending host is not authorized to send for your domain and this sort of thing can be avoided. ... For assistance, contact your system administrator. ... Searching for co.sutter.ca.us in the Exchange SMTP logs gives me no hits at all. ...
    (microsoft.public.exchange.admin)
  • Re: Has thought been given given to a cleaned up C? Possibly called C+.
    ... Standard Headers ... These are C's famous convoluted inside-out declarations. ... plague C programmers for ever and ever Amen." ... format once as an automatic format specifier) ...
    (comp.lang.c)
  • Re: Server.sendmail with no "to_addrs" parameter.
    ... solely in the CC and/or BCC fields - both of which are possible through ... headers - rfc2822 has the minimum number listed as 0 ... can't get mail delivered via SMTP without a RCPT TO command at SMTP ...
    (comp.lang.python)