Hi Andrzej, We're interfacing with Windows MAPI, and IMO such limits and other RFC details should be enforced by its low level code. MAPI is a very high level interface, almost similar to assembling a mail on the GUI (AFAIU). Moreover, MAPI supports more than just e-mail sending, see this page, which show an example for fax recipient: http://msdn.microsoft.com/en-us/library/dd296720(VS.85).aspx
It may also support internal mailing systems (f.e. MS Exchange) where RFC may not apply. Probably that's the reason why Windows MAPI documentation doesn't say anything specifically about limits the interface itself poses. It says that MAPI_E_TOO_MANY_RECIPIENTS (and friends) is returned in such case. See more here: http://msdn.microsoft.com/en-us/library/dd296721(VS.85).aspx Someone should try, but if MAPI is a good internet citizen it should return error for > 100 plain SMTP e-mail recipients. But not necessarily for number of file attachments. I can easily restore now any artificial limit if we don't trust MAPI to combat spam and conform with RFC. Anyhow I think this is not this _wrappers_ job, and removing any limit actually added value to it. Brdgs, Viktor On 2009 Dec 16, at 22:47, Andrzej P. Wozniak wrote: > From: <[email protected]> > Sent: Sunday, December 13, 2009 2:49 PM > Subject: [Harbour] SF.net SVN: harbour-project:[13234] trunk/harbour > >> Revision: 13234 >> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13234&view=rev >> Author: vszakats >> Date: 2009-12-13 13:49:14 +0000 (Sun, 13 Dec 2009) >> >> Log Message: >> ----------- >> 2009-12-13 14:46 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) >> * contrib/hbwin/mapi.c >> + Added support for unlimited number of recipients and >> attached files. Please test and review. > > Viktor, did you read RFC 5321 carefully, especially the section quoted > below? > > /---- > 4.5.3.1.8. Recipients Buffer > > The minimum total number of recipients that MUST be buffered is 100 > recipients. Rejection of messages (for excessive recipients) with > fewer than 100 RCPT commands is a violation of this specification. > The general principle that relaying SMTP server MUST NOT, and > delivery SMTP servers SHOULD NOT, perform validation tests on message > header fields suggests that messages SHOULD NOT be rejected based on > the total number of recipients shown in header fields. A server that > imposes a limit on the number of recipients MUST behave in an orderly > fashion, such as rejecting additional addresses over its limit rather > than silently discarding addresses previously accepted. A client > that needs to deliver a message containing over 100 RCPT commands > SHOULD be prepared to transmit in 100-recipient "chunks" if the > server declines to accept more than 100 recipients in a single > message. > \---- > > How do you manage 100-recipient chunks? To prevent spamming, many free > accounts have even non-standard restrictions, e.g. 20 emails per hour. > > -- > Regards from The Harbour Project mirror in Poland > Andrzej P. Wozniak > > > > ------ > Darmowe statystyki stron www > http://WEBstat.pl > > _______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > [email protected] > http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
