Re: SMTP Smuggling

Hanno Böck writes:

> Courier does neither. However, courier accepts single <cr> or <lf>
> characters, which is invalid SMTP, but it converts them in all cases I
> have tested into something that does not cause a vulnerability as far
> as I can tell.
>
> It would probably be better if courier would reject such single
> characters and answer with an error, as valid SMTP does not allow them.
> (These characters always must come as a <cr><lf> pair.)

Well, I would say that SMTP allows it: pedantically, SMTP requires the  
embedded newlines to be preserved, and unchanged, when passing the message  
to the next SMTP host. Yes, Courier doesn't do that, so it cannot be used to  
deliver a message from one Windows system to another Windows system and  
fully preserve embedded newlines; but I'm not very much concerned about it.  
Courier's behavior is indicative of the era it came from. Back then it was  
considered a good thing to be liberal in what you get, and conservative in  
what you dish out. Courier is receiving a message with just LFs rather than  
CRLF? Don't raise a stink about it, gladly accept it, and fix this when  
passing it along, don't be a clutz, yourself.

Not that I believe that the current state of affairs is due to rudeness.  
More like incompetence: you will not make the mistake that makes it possible  
to "smuggle" mail,

> Furthermore, I have observed some unexpected behavior when injecting
> invalid end of data signals with null bytes, but I haven't looked into
> this further. (Courier would open a connection and send an rset, which
> my debugging receiving SMTP poc server did not support, and at that
> point I haven't analyzed further.)

Courier sends RSET before sending the next pipelined message (2nd message on  
the same outbound connection), and periodically to keep a pipelined  
connection alive.

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCZacT4AAKCRCKYPgoojZS
4nZoAPsHL8UzgQOt10s2h01kUj1Kn1/uV+G7k3I92qohbzbe3QEApK8gPJ2PELx/
TByqLSxxW1QNJtG6qBw6fLI/M1GDAg0=
=Bua7
-----END PGP SIGNATURE-----